UNIVERSITÀ DEGLI STUDI DI TORINO
Facoltà di Economia
Corso di Laurea in Economia e Commercio
Tesi di Laurea in Economia Matematica
Simulazione ad agenti
e sistemi complessi.
Applicazione al caso BasicNet
Relatore:
Prof. Pietro TERNA
Correlatore:
Prof. Sergio MARGARITA
Candidato:
Roberto CROSETTO
ANNO ACCADEMICO 2003-2004
Desidero ringraziare il prof. Pietro Terna, mio relatore, e la dr.ssa Paola
Bruschi, sempre pronta a rispondere ad ogni mio dubbio.
Un particolare ringraziamento va ai miei genitori e ad Adriana.
Indice
Introduzione 1
1 Complessità e simulazione 5
1.1 La complessità . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 I sistemi complessi . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Un modello per la realtà: il formicaio . . . . . . . . . . . . . . 10
1.3.1 Le formiche . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.2 Applicazioni alla realtà . . . . . . . . . . . . . . . . . . 12
1.4 Complessità e ordine spontaneo . . . . . . . . . . . . . . . . . 14
1.5 La vita artificiale . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.5.1 Genotipo e fenotipo . . . . . . . . . . . . . . . . . . . . 17
1.5.2 Gli algoritmi genetici . . . . . . . . . . . . . . . . . . . 18
1.6 La simulazione e le scienze sociali . . . . . . . . . . . . . . . . 19
1.7 Lo sviluppo di una simulazione . . . . . . . . . . . . . . . . . 22
1.8 I vantaggi della simulazione . . . . . . . . . . . . . . . . . . . 25
1.9 I problemi della simulazione . . . . . . . . . . . . . . . . . . . 26
1.10 L’interpretazione dei modelli . . . . . . . . . . . . . . . . . . . 27
1.11 Gli agenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2 Gli strumenti per la simulazione 32
2.1 Swarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1.1 Sviluppo di una simulazione . . . . . . . . . . . . . . . 34
I
INDICE II
2.1.2 Caratteristiche principali . . . . . . . . . . . . . . . . . 36
2.1.3 Le ‘‘sonde’’ . . . . . . . . . . . . . . . . . . . . . . . . 38
2.1.4 Le librerie di Swarm . . . . . . . . . . . . . . . . . . . 39
2.2 NetLogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.2.1 Caratteristiche principali . . . . . . . . . . . . . . . . . 41
2.2.2 Obiettivi futuri . . . . . . . . . . . . . . . . . . . . . . 42
2.3 RePast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.3.1 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.3.2 Caratteristiche della simulazione . . . . . . . . . . . . . 44
2.3.3 Le librerie . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.3.4 Progetti futuri . . . . . . . . . . . . . . . . . . . . . . . 46
3 Impresa, imprenditore e conoscenza 47
3.1 La teoria neoclassica . . . . . . . . . . . . . . . . . . . . . . . 48
3.2 La Scuola Austriaca . . . . . . . . . . . . . . . . . . . . . . . 50
3.2.1 L’attività imprenditoriale . . . . . . . . . . . . . . . . 53
3.2.2 La competizione . . . . . . . . . . . . . . . . . . . . . . 55
3.3 L’imprenditore di Kirzner . . . . . . . . . . . . . . . . . . . . 55
3.4 Simon e la razionalità limitata . . . . . . . . . . . . . . . . . . 57
3.4.1 La razionalità procedurale . . . . . . . . . . . . . . . . 59
3.4.2 Il processo di scelta . . . . . . . . . . . . . . . . . . . . 60
4 jES: java Enterprise Simulator 61
4.1 Introduzione all’uso del simulatore . . . . . . . . . . . . . . . . 62
4.2 Lo schema ERA . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.3 Applicazioni a casi aziendali . . . . . . . . . . . . . . . . . . . 65
4.4 Il primo formalismo: le cose da fare . . . . . . . . . . . . . . . 66
4.4.1 Le ricette . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4.2 I layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
INDICE III
4.4.3 I batch . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.4.4 I procurement . . . . . . . . . . . . . . . . . . . . . . . 68
4.4.5 Il processo OR . . . . . . . . . . . . . . . . . . . . . . 69
4.5 Il secondo formalismo: chi fa cosa . . . . . . . . . . . . . . . . 70
4.5.1 Le unità produttive . . . . . . . . . . . . . . . . . . . . 70
4.5.2 Le endUnit . . . . . . . . . . . . . . . . . . . . . . . . 71
4.5.3 La scelta delle unità . . . . . . . . . . . . . . . . . . . 72
4.5.4 La trasmissione delle informazioni . . . . . . . . . . . . 72
4.6 Il terzo formalismo: quando fare cosa . . . . . . . . . . . . . . 73
4.7 Le capacità computazionali . . . . . . . . . . . . . . . . . . . . 74
4.7.1 Un semplice esempio . . . . . . . . . . . . . . . . . . . 76
4.7.2 La matrice orMemoryMatrix . . . . . . . . . . . . . . . 77
4.7.3 Le ricette che lanciano ricette . . . . . . . . . . . . . . 77
4.8 Le capacità contabili . . . . . . . . . . . . . . . . . . . . . . . 79
4.8.1 I costi . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.8.2 I ricavi . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.8.3 L’utile . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.9 Lanciare una simulazione . . . . . . . . . . . . . . . . . . . . . 81
4.9.1 I grafici di una simulazione . . . . . . . . . . . . . . . . 82
5 L’azienda reale: BasicNet 86
5.1 La storia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.2 Il business system . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3 La struttura del Gruppo . . . . . . . . . . . . . . . . . . . . . 92
5.4 Le divisioni dot.com . . . . . . . . . . . . . . . . . . . . . . . 94
5.5 Il ciclo di produzione . . . . . . . . . . . . . . . . . . . . . . . 96
5.6 Le attività di promozione . . . . . . . . . . . . . . . . . . . . . 97
INDICE IV
6 L’azienda virtuale: Basic_jES 99
6.1 Prima analisi e possibili sviluppi . . . . . . . . . . . . . . . . . 99
6.2 Novità nell’azienda . . . . . . . . . . . . . . . . . . . . . . . . 101
6.3 Le modifiche al modello precedente . . . . . . . . . . . . . . . 102
6.4 Analisi del calendario . . . . . . . . . . . . . . . . . . . . . . . 104
6.4.1 La time-table di BasicNet . . . . . . . . . . . . . . . . 104
6.4.2 Il calendario di Basic_jES . . . . . . . . . . . . . . . . 108
6.5 Le ricette produttive . . . . . . . . . . . . . . . . . . . . . . . 109
6.6 Le memoryMatrixes . . . . . . . . . . . . . . . . . . . . . . . . 110
6.7 Le modifiche al codice . . . . . . . . . . . . . . . . . . . . . . 111
6.8 Analisi di diversi business system . . . . . . . . . . . . . . . . 115
6.9 Caso 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.9.1 Le unità produttive . . . . . . . . . . . . . . . . . . . . 116
6.9.2 Le nuove ricette . . . . . . . . . . . . . . . . . . . . . . 120
6.9.3 Il calendario . . . . . . . . . . . . . . . . . . . . . . . . 121
6.9.4 Le modifiche al codice . . . . . . . . . . . . . . . . . . 122
6.9.5 I parametri della simulazione . . . . . . . . . . . . . . 126
6.10 Caso 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6.10.1 Le modifiche al modello . . . . . . . . . . . . . . . . . 129
6.10.2 I costi delle unità produttive . . . . . . . . . . . . . . . 132
6.10.3 I ricavi aziendali . . . . . . . . . . . . . . . . . . . . . 134
6.10.4 Le modifiche al codice . . . . . . . . . . . . . . . . . . 136
6.10.5 I parametri della simulazione . . . . . . . . . . . . . . 138
6.11 Caso 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6.11.1 Le modifiche al modello . . . . . . . . . . . . . . . . . 140
6.11.2 Le modifiche al codice . . . . . . . . . . . . . . . . . . 141
6.11.3 I parametri della simulazione . . . . . . . . . . . . . . 141
6.12 Risultati della simulazione . . . . . . . . . . . . . . . . . . . . 142
INDICE V
6.13 Considerazioni sui risultati . . . . . . . . . . . . . . . . . . . . 148
6.14 Focus sui licenziatari . . . . . . . . . . . . . . . . . . . . . . . 150
6.14.1 Licenziatari con tempo 1 . . . . . . . . . . . . . . . . . 150
6.14.2 Licenziatari con tempo 0 . . . . . . . . . . . . . . . . . 153
6.15 Approfondimento di BasicSamples . . . . . . . . . . . . . . . . 154
6.16 Analisi finale . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
6.16.1 Caso 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
6.16.2 Caso 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
6.16.3 Caso 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Appendice 165
Bibliografia 202
Elenco delle tabelle
4.1 Esempio di ricetta produttiva . . . . . . . . . . . . . . . . . . 66
4.2 Sequential batch . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3 Stand alone batch e indicazione dell’endUnit . . . . . . . . . . 68
4.4 Procurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.5 Processo or . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.6 recipeData/orderSequence.xls . . . . . . . . . . . . . . . . . . . 74
4.7 Uso di passi computazionali . . . . . . . . . . . . . . . . . . . 75
4.8 Ricette che lanciano ricette . . . . . . . . . . . . . . . . . . . . 79
6.1 Successione delle fasi per una collezione . . . . . . . . . . . . . 107
6.2 Suddivisione delle royalties . . . . . . . . . . . . . . . . . . . . 117
6.3 Costi fissi delle divisioni dot.com (in euro) . . . . . . . . . . . 120
6.4 Articoli creati ed effettivamente prodotti per ogni collezione . 146
6.5 File log/grossSales . . . . . . . . . . . . . . . . . . . . . . . . 158
VI
Elenco delle figure
2.1 Logo di SWARM . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2 Struttura di una simulazione . . . . . . . . . . . . . . . . . . . 36
2.3 Esempi di sonde . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4 Logo di NetLogo . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.5 Logo di RePast . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1 Interazioni tra ordini e unità . . . . . . . . . . . . . . . . . . . 63
4.2 Lo schema ERA . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3 File unitData/unitBasicData.txt . . . . . . . . . . . . . . . . . 71
4.4 File unitData/memoryMatrixes.txt . . . . . . . . . . . . . . . 75
4.5 Grafico dell’andamento delle liste d’attesa . . . . . . . . . . . 83
4.6 Andamento dell’utile durante la simulazione . . . . . . . . . . 83
4.7 Rapporto totaltimetotallenght
. . . . . . . . . . . . . . . . . . . . . . . . 84
4.8 Liste d’attesa delle unità dell’impresa virtuale . . . . . . . . . 84
4.9 Livello delle endUnit . . . . . . . . . . . . . . . . . . . . . . . 85
5.1 Rappresentazione del business system di BasicNet . . . . . . . 91
5.2 La struttura del Gruppo . . . . . . . . . . . . . . . . . . . . . 92
6.1 Costi variabili e fissi di BasicNet . . . . . . . . . . . . . . . . . 119
6.2 Ricette 900 e 950 . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.3 Ricetta 800 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
VII
ELENCO DELLE FIGURE VIII
6.4 Ricetta 900 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
6.5 Ricetta 302 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
6.6 Primo esperimento. Tempodiesecuzione
Tempoprevistodallericette. . . . . . . . . . . . 145
6.7 Primo esperimento. Tempi d’attesa degli ordini . . . . . . . . 145
6.8 Secondo esperimento. Tempodiesecuzione
Tempoprevistodallericette. . . . . . . . . . . 148
6.9 Secondo esperimento. Tempi d’attesa degli ordini . . . . . . . 149
6.10 Terzo esperimento. Tempodiesecuzione
Tempoprevistodallericette. . . . . . . . . . . . . 150
6.11 Quarto esperimento. Tempodiesecuzione
Tempoprevistodallericette. . . . . . . . . . . . 151
6.12 Sesto esperimento. Tempodiesecuzione
Tempoprevistodallericette. . . . . . . . . . . . . 152
6.13 Licenziatari con tempo 0. Tempodiesecuzione
Tempoprevistodallericette. . . . . . . . . . 153
6.14 Approfondimento di Basicsamples. Tempodiesecuzione
Tempoprevistodallericette. . . . 156
6.15 Andamento di costi, ricavi e profitti totali (Caso 1) . . . . . . 159
6.16 Andamento di costi, ricavi e profitti giornalieri (Caso 1) . . . . 159
6.17 Andamento di costi, ricavi e profitti totali (Caso 2) . . . . . . 161
6.18 Andamento di costi, ricavi e profitti giornalieri (Caso 2) . . . . 161
6.19 Andamento di costi, ricavi e profitti totali (Caso 3) . . . . . . 162
6.20 Andamento di costi, ricavi e profitti giornalieri (Caso 3) . . . . 162
Introduzione
La simulazione ad agenti è uno strumento di grande utilità per lo studio dei
sistemi complessi legati agli esseri viventi. Con questa metodologia è possibile
creare un mondo virtuale all’interno del computer basato su agenti autonomi
che interagiscono tra loro e osservare i fenomeni emergenti, che spesso si
rivelano di una complessità straordinaria. Un sistema si dice complesso se
non è possibile analizzarlo scomponendolo nelle parti che lo costituiscono,
ma è necessario studiarlo nel suo insieme; un esempio è l’azienda, oggetto di
studio di questo lavoro.
In questa tesi si applica il metodo della simulazione al contesto di un’im-
presa reale, con l’obiettivo di ricreare tutte le sue componenti e di osservare
il loro funzionamento all’interno del computer. Il modello di simulazione è
stato costruito utilizzando jES, piattaforma utile per la simulazione di im-
presa sviluppata dal professor Pietro Terna, e l’azienda oggetto di studio è la
torinese BasicNet S.p.A., che opera nel settore dell’abbigliamento alla moda.
BasicNet ha un particolare modello di business secondo il quale non parte-
cipa direttamente al processo produttivo, in quanto la produzione è delegata
ad imprese esterne, chiamate Sourcing Centers o Trading Company, e gli ar-
ticoli sono venduti direttamente da queste ultime ai licenziatari, che hanno
il compito di commercializzare i prodotti presso il pubblico. Il ruolo princi-
pale di BasicNet consiste nella gestione del network, nella finanza strategica
e nell’attività di merketing e la principale fonte di ricavo è costituita dalle
1
INTRODUZIONE 2
royalties pagate dai licenziatari, pari al 10% dei loro acquisti, per i servizi
loro offerti.
La costruzione di questo modello è iniziata in Lamieri (2002) e Merlo
(2003a) e questa tesi ne rappresenta la continuazione, con l’obiettivo finale
di un raffronto tra tre possibili modelli organizzativi, illustrati qui di seguito,
che BasicNet potrebbe adottare.
Nel primo caso si rappresenta la BasicNet reale nel modo il più possibile
vicino alla realtà. Grazie alla disponibilità della dottoressa Paola Bruschi,
direttore generale dei sistemi informativi di BasicNet, è stata possibile la
realizzazione di un’azienda virtuale con una struttura, un calendario delle
attività e una configurazione dei costi e dei ricavi simili alla BasicNet reale.
Nel secondo caso si presenta un possibile modello organizzativo che Ba-
sicNet potrebbe adottare, cioè un’azienda di tipo tradizionale che produce
e vende direttamente i propri articoli. La differenza con il caso preceden-
te è rappresentata da una diversa struttura dei costi, perché la produzione
avviene internamente, e una differente origine dei ricavi, che sono calcolati
applicando un margine di ricarico ai costi sostenuti dall’azienda.
Infine, si presenta una BasicNet ancora differente, che fa produrre in
outsourcing i propri prodotti e li vende ai licenziatari. Questo modello orga-
nizzativo è una ‘‘miscela” dei precedenti, perché la produzione è delegata ad
altri, come per la BasicNet reale, e la vendita è effettuata direttamente, come
nel caso precedente; perciò i costi totali non comprendono quelli relativi alla
produzione e i ricavi sono calcolati in base ad un mark-up.
Occorre ricordare che lo studio qui affrontato non ha l’obiettivo di fornire
risultati assoluti su quale potrebbe essere la miglior struttura organizzativa,
ma offre soltanto un’indicazione generale per le scelte aziendali che, per essere
utilizzata nella realtà, dovrebbe essere affiancata da altri tipi di valutazione.
Il motivo principale è che con la simulazione ad agenti non è possibile ‘‘cat-
INTRODUZIONE 3
turare” e rappresentare tutti gli elementi di incertezza del mondo reale.
La tesi è composta di sei capitoli che, partendo dai concetti generali,
aiutano a comprendere le ragioni dell’utilizzo della simulazione ad agenti e
come costruire modelli di simulazione.
Nel primo capitolo si presenta una trattazione sulla teoria della comples-
sità e sui modi con cui è possibile studiare i comportamenti individuali e
globali all’interno dei sistemi. In seguito si descrive la simulazione ad agenti
e il suo ruolo nello studio dei fenomeni complessi.
Nel secondo capitolo si effettua una breve presentazione di alcuni stru-
menti che possono essere usati per realizzare una simulazione ad agenti. In
particolare sono presentati Swarm, un protocollo di programmazione con
il quale è possibile creare modelli di simulazione utilizzabili per lo studio
di fenomeni complessi di ogni genere, NetLogo e RePast, altri ambienti di
simulazione.
Nel terzo capitolo è presentata una rassegna della letteratura economica
a riguardo dell’impresa, riservando una particolare attenzione al modo in cui
è considerata la figura dell’imprenditore. Secondo la teoria neoclassica l’im-
prenditore è un semplice amministratore delle risorse interne e non ha alcuna
funzione creativa, compito che al contrario è evidenziato dagli esponenti del-
la Scuola Austriaca, che lo immaginano come lo scopritore delle occasioni
di profitto presenti nel mercato. L’impostazione Austriaca è poi ripresa da
Israel M. Kirzner ed integrata con spunti di originalità. Infine, si presenta
la visione di Herbert A. Simon, che ha rivoluzionato la figura dell’impren-
ditore introducendo i principi della razionalità limitata e della decisione più
soddisfacente anziché della migliore.
Nel quarto capitolo si descrive il modello jES (java Enterprise Simula-
tor), basato su Swarm, con il quale è possibile effettuare delle simulazioni
INTRODUZIONE 4
di impresa. Con questa piattaforma è possibile creare delle imprese virtuali
all’interno del computer per osservare i fenomeni complessi che si creano nelle
realtà aziendali. jES inoltre può essere usato per scopi teorici per lo studio
della nascita e dell’evoluzione delle imprese.
In seguito, nel capitolo cinque, si descrive l’azienda oggetto di studio di
questa tesi, la BasicNet S.p.A., proprietaria di alcuni marchi di abbigliamento
come Kappa, Robe di Kappa, Jesus Jeans, K-Way e Superga.
Infine, nell’ultimo capitolo si descrivono le modifiche e le novità portate al
modello di BasicNet creato con jES in Lamieri (2002) e Merlo (2003a); le mo-
difiche hanno avuto l’obiettivo di rendere il più possibile simile all’azienda
reale quella creata all’interno del computer. Inoltre sono illustrate la co-
struzione degli altri modelli di azienda descritti precedentemente e un’analisi
finale dei costi e dei ricavi in cui si confrontano i diversi modelli organizzativi.
Capitolo 1
Complessità e simulazione
1.1 La complessità
La complessità è un concetto che deriva principalmente dalla matematica e
dalla fisica e con il passare del tempo è stata oggetto di studio di altre discipli-
ne, come la biologia e le scienze sociali. Il suo carattere di multidisciplinarità
crea delle difficoltà nel momento in cui si voglia dare una definizione di que-
sto concetto e la conseguenza principale è che non ne esiste una ampiamente
condivisa. Infatti nessuno dei tentativi, per ammissione stessa degli autori,
è in grado di spiegare in modo esaustivo ciò che gli economisti e i sociologi
intendono con questo concetto.
Una definizione generale può essere che ‘‘un sistema dinamico è complesso
se a livello endogeno non tende asintoticamente ad un punto fissato, ma
mostra comportamenti discontinui e può essere descritto come un insieme di
equazioni non lineari con elementi stocastici’’ (Rosser, 1999). Un secondo
tentativo di definizione si può trovare in Tinti (1998), dove la complessità è
definita come ‘‘lo studio interdisciplinare dei sistemi complessi adattivi e dei
fenomeni emergenti ad essi associati’’.
Infine, in Kilpatrick (2001) è illustrato il Santa Fe approach, vale a di-
5
1. COMPLESSITÀ E SIMULAZIONE 6
re la visione della complessità nella ricerca economica secondo gli studiosi
dell’Istituto degli Studi sulla Complessità di Santa Fe, che la considerano
caratterizzata da sei elementi chiave:
1. interazioni disperse tra agenti eterogenei che agiscono localmente;
2. nessun controllo centrale che può sfruttare tutte le opportunità e le
interazioni nell’economia;
3. organizzazioni gerarchiche che danno vita ad un groviglio di interazioni;
4. continuo adattamento e apprendimento degli agenti;
5. continue novità, ad esempio nuovi mercati, nuove tecnologie e nuovi
comportamenti;
6. dinamiche senza equilibrio.
Inoltre il mondo così immaginato è a razionalità limitata con aspettative non
razionali. Questa definizione di complessità è stata delineata precedente-
mente dai chimici e dai fisici delle Università di Bruxelles e Stuttgart, i quali
hanno svolto anche alcune applicazioni di carattere economico che hanno
influenzato in modo particolare l’attività dei ricercatori di Santa Fe.
La nascita del pensiero della complessità avviene alla fine degli anni Qua-
ranta da parte degli studiosi di cibernetica e di teoria dell’informazione; con
il passare del tempo ad essi si sono aggiunti studiosi provenienti da diverse
discipline. Una delle caratteristiche più importanti della teoria della com-
plessità è rappresentata dal fatto che essa contribuisce ad unire la filosofia e
la scienza, infatti a questi studi partecipano in egual misura filosofi, biologi,
psicologi, chimici ed informatici; alcuni parlano della complessità come di
una ‘‘terza cultura” (Tinti, 1998).
Inoltre è da sottolineare il ruolo assunto dal computer nello studio della
complessità, che è utilizzato come laboratorio in cui sperimentare i modelli
1. COMPLESSITÀ E SIMULAZIONE 7
computazionali del sistema che si intende studiare ed osservare il suo com-
portamento; questo tipo di esperimento è detto simulazione, della quale si
parlerà in modo più approfondito nei prossimi paragrafi di questo capitolo.
Inizialmente la maggior parte dei lavori sulla complessità hanno riguarda-
to modelli spaziali, caratterizzati dalla possibilità per gli agenti di interagire
tra loro in modo disperso; da questi modelli si può notare l’emergere di una
struttura globale a partire da fenomeni strettamente locali, caratteristica che
rappresenta l’idea principale della moderna teoria della complessità. Questo
concetto trova l’anticipatore in un lavoro di Schelling, in cui è stato crea-
to un modello che riguarda la segregazione razziale nelle città e può essere
dimostrato senza l’uso del computer.
Schelling considered a rectangle with many sub-rectangles, ea-
ch occupied by a black or a white. He allowed for movement based
on local interactions and discovered that even a very slight prefe-
rence by members of either group for living with their own kind
would eventually lead to a largely segregated city, even though
agents were only acting in relation to their immediate neighbors.
(Rosser, 1999, 176)
Il modello di Schelling è stato imitato per lo studio di sistemi formati
da agenti eterogenei che formulano strategie in base alle interazioni con gli
altri agenti; un esempio è il punto di vista della vita artificiale sviluppato da
Langton (1992), che usa automi cellulari per rappresentare agenti economici
che interagiscono tra loro.
1.2 I sistemi complessi
Gran parte del mondo è composto da sistemi complessi adattivi, strutture in
cui le componenti sono fortemente dinamiche e correlate tra loro; ciascuno di
1. COMPLESSITÀ E SIMULAZIONE 8
questi sistemi evolve e deve adattarsi al cambiamento continuo per garantirsi
la sopravvivenza. Esempi di sistema complesso possono essere la società e il
nostro sistema immunitario.
Secondo Tinti (1998) la complessità di un sistema è una proprietà del suo
modello creato dall’osservatore esterno e non una caratteristica del sistema
stesso; perciò si definisce sistema complesso una struttura la cui rappresen-
tazione scientifica ha la peculiarità di essere complessa. I sistemi di questo
tipo presentano alcune caratteristiche comuni:
• tante componenti più o meno complesse; quanto più numerose e com-
plesse sono le parti che lo compongono, tanto più complesso è il sistema
in generale;
• interazioni tra le componenti, che si passano informazioni tra loro; le
informazioni non possono essere né troppo numerose né troppo poche,
perché nel primo caso il sistema diventerebbe caotico e nel secondo si
‘‘cristallizzerebbe’’;
• assenza di gerarchia piramidale; in caso contrario il funzionamento del
sistema potrebbe essere spiegato osservando soltanto la componente
che si trova al vertice della struttura;
• interazione adattiva con l’ambiente; il sistema è tanto più complesso
quanto maggiori sono i fattori esterni che influiscono sul suo adatta-
mento all’ambiente e sulla sua evoluzione. Questa caratteristica rende
adattivi i sistemi complessi.
È possibile classificare i sistemi in tre differenti categorie in base al loro
grado di complessità. Si definiscono sistemi minimamente complessi tutti i
sistemi naturali non biologici che non manifestano interazioni con l’ambiente
esterno. I sistemi di media complessità sono gli artefatti complessi, come
1. COMPLESSITÀ E SIMULAZIONE 9
ad esempio il computer; questi sistemi possono essere adattivi e manifestare
comportamenti imprevedibili. Infine, i sistemi complessi sono sistemi adat-
tivi che manifestano fenomeni emergenti, esempi di sistemi complessi sono le
popolazioni umane e tutti i sistemi biologici.
I sistemi complessi sono detti non lineari (Sanders e McCabe, 2003),
perché le variabili al suo interno interagiscono tra loro costantemente e si
modificano in risposta alle variazioni delle altre; in questi sistemi piccoli
cambiamenti possono dare origine a variazioni di tutto il sistema. I siste-
mi non lineari non rispondono al principio della sovrapposizione, in quanto
anche scomponendoli nelle parti costitutive non è possibile comprendere il
funzionamento del sistema totale. La caratteristica fondamentale dei siste-
mi non lineari è l’importanza delle interazioni tra le parti piuttosto che le
proprietà delle sue componenti.
Al contrario, i sistemi lineari sono soggetti al principio di sovrapposizione,
cioè è possibile analizzare un sistema di questo tipo studiando separatamente
le parti che lo compongono e da esse comprendere il funzionamento completo
del sistema.
La principale differenza tra i sistemi complessi, o non lineari, e quelli
complicati, o lineari, è che per i secondi il comportamento globale è la somma
dei comportamenti locali delle sue parti; per i primi invece il comportamento
del tutto è maggiore della somma dei comportamenti locali, a causa delle
interazioni tra gli agenti del sistema (Langton, 1992).
È possibile fare un esempio legato alla realtà, mettendo a confronto il
motore di un’automobile e un formicaio (Terna, 2003a). Il primo è un siste-
ma complicato, o lineare, perché può essere scomposto in tutte le sue parti
costitutive ed a ciascuna, ad esempio il carburatore o la marmitta, può essere
associata una particolare funzione che aiuta a comprendere il funzionamen-
to generale del motore. Il formicaio è un sistema complesso, o non lineare,
1. COMPLESSITÀ E SIMULAZIONE 10
perché la più piccola unità di questo sistema, la formica, non è in grado di
dire nulla sulla struttura aggregata; per comprendere il funzionamento di un
formicaio, e di qualsiasi altro sistema complesso, si rivela quindi necessario
osservarlo nel suo insieme.
1.3 Un modello per la realtà: il formicaio
Secondo Ormerod (2003) la società è un sistema complesso formato da agen-
ti interattivi che imparano e si adattano continuamente all’ambiente circo-
stante. Questa visione è fortemente in contrasto con quella degli schemi di
pensiero tradizionali delle scienze sociali e dell’aconomia, che offrono una vi-
sione del funzionamento del mondo che può essere paragonato a quello di una
macchina.
Nella realtà si incontrano spesso fenomeni che non possono essere spiegati
con regole rigide, ma soltanto con la consapevolezza che la società è molto
simile ad un organismo vivente; ad esempio, gli individui possono prendere
delle scelte in base alle proprie opinioni, ma possono anche essere influenzati
da quelle di altri individui. Nella teoria economica convenzionale questa idea
non trova spazio, in quanto è previsto che le preferenze siano fissate per tutti.
Un modello che può essere utile per spiegare i fenomeni che si verifica-
no nella realtà è il formicaio, un esempio di sistema complesso composto da
agenti che interagiscono tra loro e si adattano all’ambiente circostante, che
consente una via interpretativa alternativa alla teoria meccanicistica tradi-
zionale. Infatti l’osservazione del comportamento di un gruppo di formiche
si rivela di grande utilità nel momento in cui si voglia formalizzare il com-
portamento di individui che si trovano di fronte a più possibilità tra cui
scegliere.
1. COMPLESSITÀ E SIMULAZIONE 11
1.3.1 Le formiche
Gli studi biologici sulle formiche hanno dato origine a risultati che sono dif-
ficili da spiegare e che mostrano l’emergere di comportamenti complessi da
parte loro che possono trovare analogie con le società umane.
Gli esperimenti entomologici condotti durante gli anni Ottanta hanno
avuto come obiettivo l’osservazione del modo in cui le formiche prendono le
decisioni e sono consistite nel posizionare due mucchietti identici di cibo a
distanze uguali da un formicaio; i due mucchietti erano reintegrati ogni volta
che una formica portava via del cibo da uno di essi.
Intuitivamente si può dire che una formica scelga in modo casuale dove
dirigersi, perciò la distribuzione delle formiche tra i due mucchietti potrebbe
essere analizzabile semplicemente lanciando una moneta e osservando la di-
stribuzione di teste e croci. Tuttavia gli studi dei biologi hanno evidenziato
che se una formica ha successo nella ricerca di cibo in un particolare luogo,
in futuro tenderà a tornare nello stesso posto; inoltre durante il ritorno al
formicaio la formica lascia una scia di secrezioni, il ferormone, che possono
stimolare altre formiche a dirigersi verso il mucchietto in cui la prima ha
trovato cibo.
Alan Kirman, un economista e uno dei ‘‘pionieri” nell’applicazione all’eco-
nomia dei modelli basati sugli agenti interattivi (Ormerod, 2003), osservando
gli studi effettuati dai biologi sulle formiche sviluppò l’idea che per compren-
dere il funzionamento di un intero sistema non è sufficiente osservare soltanto
il comportamento di un suo agente rappresentativo, che sia una formica op-
pure un agente economico o sociale. Il risultato del sistema studiato dipende
dalle interazioni che si creano tra gli agenti e dall’influenza che essi esercitano
tra loro.
Tornando all’esempio del formicaio, secondo Kirman una singola formica
può scegliere fra tre possibilità: dirigersi verso il mucchio di cibo da cui si
1. COMPLESSITÀ E SIMULAZIONE 12
è rifornita in un momento precedente, essere indotta dalla scia lasciata da
un’altra formica a scegliere un mucchio in particolare, oppure prendere una
scelta nuova in modo indipendente. Date queste ipotesi, ogni esperimento di
questo modello genera risultati imprevedibili e diversi tra loro che dipendono,
di volta in volta, dalla propensione delle formiche a cambiare comportamento
e a farsi convincere dalle altre.
Il modello di scelta fra tre possibilità descritto per le formiche è adot-
tabile anche per la descrizione delle scelte delle persone in molte situazioni
reali, infatti i fenomeni sociali ed economici presentano le stesse proprietà del
comportamento di un formicaio: nel breve termine sono imprevedibili e nel
lungo periodo originano fenomeni di carattere complesso.
1.3.2 Applicazioni alla realtà
In Ormerod (2003) si afferma che è possibile riscontrare delle analogie con
il modello del formicaio se si osservano situazioni reali semplici, come la
scelta di una serata al cinema, o altre più elaborate, come ad esempio alcuni
fenomeni che si originano sui mercati finanziari.
Il primo esempio riguarda la scelta di più individui a riguardo di quale film
da vedere al cinema. Il processo di scelta è simile a quello della formica, anche
se in questo esempio ci sono alcune differenze con il modello sopra descritto,
ad esempio i film tra cui scegliere non saranno uguali come i mucchi di cibo
per le formiche, ma i registi cercheranno il più possibile di differenziare i loro
prodotti.
Per comprendere quali siano i fattori che portano al successo un film è
necessario usare la teoria degli agenti interattivi, rappresentati dal pubblico e
dai critici, che sono responsabili del successo o dell’insuccesso di una pellicola.
Infatti le persone che ne vanno a vedere una ‘‘lasciano una traccia’’ proprio
come le formiche con il ferormone, rappresentata in questo caso dalle opinioni
1. COMPLESSITÀ E SIMULAZIONE 13
e dai passaparola, che può influenzare le scelte degli altri individui. Perciò agli
individui è possibile applicare il modello decisionale delle formiche, infatti essi
possono decidere in modo autonomo oppure farsi influenzare dalle opinioni e
dai consigli altrui. Inoltre è anche importante l’ordine con cui i film sono visti,
in quanto il fatto di andare a vedere un film l’ultimo giorno della proiezione
esercita un effetto certamente minore rispetto a quello di chi è andato la
prima sera.
Un secondo esempio è l’applicazione sviluppata da Alan Kirman in rela-
zione ad un fenomeno realmente avvenuto sui mercati finanziari. Nei primi
anni Ottanta iniziò a prendere forza l’opinione di un numero crescente di
operatori specializzati che il dollaro fosse sopravvalutato e, ovviamente, nel
1985 questa valuta crollò; il fatto ‘‘curioso” è che durante questo periodo
gli operatori si comportarono in modo inspiegabile, continuando a comprare
il dollaro e allo stesso tempo dichiarando che quest’ultimo era decisamente
sopravvalutato.
Per studiare questo fenomeno Kirman sviluppò un modello in cui si tro-
vano due categorie di operatori finanziari, da un lato i fundamentalist, coloro
che ritengono che i prezzi delle attività finanziarie siano determinati dai fon-
damentali (ad esempio, nel caso delle azioni dal valore attuale dei dividendi
futuri), e dall’altro i chartist, secondo i quali l’andamento passato di un’atti-
vità finanziaria può aiutare a prevederne il futuro. Nel 1984 i primi ritenevano
che il dollaro avrebbe subito un brusco calo, mentre i secondi erano certi del
contrario.
Nel modello ogni operatore ha tre possibilità, come le formiche: può
scegliere di comportarsi come prima, può modificare la propria opinione in-
fluenzato dalle informazioni altrui, oppure può scegliere autonomamente di
cambiare. Come nel formicaio, per ogni attività finanziaria la ripartizione
tra i due gruppi di operatori varia continuamente e in modo rapido, pertanto
1. COMPLESSITÀ E SIMULAZIONE 14
si possono verificare grandi variazioni di prezzo in modo repentino ed inspie-
gabile. La volatilità dei prezzi è dunque la conseguenza della volatilità delle
scelte degli operatori.
Questo modello permette di comprendere ex post anche un comportamen-
to senza logica come l’acquisto di una moneta considerata sopravvalutata,
dovuto a frequenti cambiamenti di opinione degli operatori, situazione che la
teoria economica tradizionale non è in grado di spiegare.
1.4 Complessità e ordine spontaneo
Le idee di Hayek secondo alcuni studiosi sono considerate anticipatrici della
teoria della complessità in quanto, in base alle loro opinioni, quest’ultima rap-
presenta semplicemente la riscoperta di alcuni principi hayekiani, ad esempio
la conoscenza e l’ordine spontaneo, o una rievocazione della sua filosofia del
mercato.
Ordine spontaneo e sistema auto-organizzante possono essere considerati
sinonimi (Kilpatrick, 2001), perché in un sistema complesso adattivo si può
rilevare una sorta di ordine che non è prevedibile in alcun modo.
Secondo Hayek il mercato non è mai in equilibrio e con il passare del
tempo evolve. Nella visione hayekiana il mercato è organizzato dagli agenti
senza che sia necessaria la presenza di un controllo accentrato ed è quasi
sempre in grado di raggiungere in modo autonomo la miglior configurazione;
un’eventuale autorità esterna non potrebbe migliorare la sua efficienza, ma
solo peggiorarla, a causa della complessità della società e della presenza di
una conoscenza dispersa tra gli uomini.
La maggior parte di queste idee sono condivise dai teorici della comples-
sità, con la sola differenza che secondo la loro visione un controllo centrale
pianificatore è in grado di sistemare la configurazione del mercato nel caso
che questa non sia la migliore.
1. COMPLESSITÀ E SIMULAZIONE 15
Un altro elemento che avvicina Hayek alla teoria della complessità è il
suo interesse per la teoria biologica evoluzionistica e per la scienza cogniti-
va, che lo avvicinò a gran parte della letteratura studiata dai teorici della
complessità, anche se una differenza con questi ultimi è rappresentata dal
fatto che i lavori di Hayek sono di limitato utilizzo per ulteriori analisi sui
sistemi complessi, perché non considerava di grande aiuto per la loro analisi
gli strumenti statistici.
Tuttavia il pensiero di Hayek e la moderna teoria della complessità mo-
strano anche alcune caratteristiche che li distinguono tra loro.
Nelle opere di Hayek sembra che sia presente l’idea di un’entità sopran-
naturale benevolente che si cela dietro l’ordine spontaneo; secondo Hayek le
persone dovrebbero impegnarsi a lasciar guidare la società all’ordine spon-
taneo piuttosto di tentare il controllo del mercato per mezzo di un’autorità
centrale.
Al contrario, i teorici della complessità non vedono una forza benevolente
dietro le dinamiche complesse. Gli uomini agiscono e ciò che fanno può
causare eventi positivi o negativi, ma non esiste una mano invisibile che
guida automaticamente l’uomo verso la migliore soluzione, perciò si rende
necessaria la presenza di un controllo accentrato che in alcune situazioni
intervenga per sistemare l’andamento della società.
Si può pertanto concludere che il pensiero di Hayek in qualche modo anti-
cipa la teoria della complessità e chi si accinge allo studio di questa disciplina
dovrebbe analizzare attentamente i lavori hayekiani. Occorre tuttavia sotto-
lineare che le teorie espresse dalle due parti sono qualitativamente differenti
(Kilpatrick, 2001).
1. COMPLESSITÀ E SIMULAZIONE 16
1.5 La vita artificiale
La vita artificiale mira a sintetizzare comportamenti di tipo biologico in am-
bienti artificiali, ad esempio in un computer, e ad osservare i fenomeni com-
plessi che sono originati dalle interazioni tra gli agenti e dal loro adattamento
all’ambiente circostante.
Tradizionalmente la biologia ha considerato un organismo vivente come
una macchina complessa ed in seguito ha proceduto a ‘‘scomporre” gli orga-
nismi nelle loro componenti più piccole al fine di comprendere i meccanismi
della vita. Grazie alla conoscenza delle parti che costituiscono gli organismi
viventi la biologia è stata in grado di proporre uno schema generale sulla
vita.
Tuttavia la vita dipende non solo dalle caratteristiche degli esseri viventi
ma anche dalle interazioni che si creano tra loro, perché i fenomeni naturali
sono non lineari e conseguentemente gli organismi devono essere studiati
osservando il comportamento che assumono se sono immersi nell’ambiente.
Perciò secondo Langton (1992) la vita artificiale applica il punto di vista
sintetico alla biologia: mette insieme gli esseri viventi e analizza le interazioni
che si generano; con il termine sintesi si intende la combinazione di più parti
diverse tra loro per formare un tutto.
Gli obiettivi della vita artificiale sono espressi in Langton (1992, 190):
la vita artificiale intende 1) sintetizzare il processo dell’evoluzio-
ne, 2) usando i calcolatori, e 3) studiare qualunque cosa emerga
da questo processo, anche quando i risultati non hanno corrispet-
tivi nel mondo naturale. È certo interessante, dal punto di vista
scientifico, sapere quali tipi di cose possono, in linea di principio,
evolversi − che siano o no evolute, di fatto qui sulla Terra.
La vita artificiale si differenzia dall’intelligenza artificiale per la diversa
1. COMPLESSITÀ E SIMULAZIONE 17
prospettiva adottata. L’intelligenza artificiale ha sempre avuto come obiet-
tivo la generazione di comportamenti intelligenti che non necessariamente
devono avere una corrispondenza con quanto avviene in natura. Al con-
trario, l’obiettivo della vita artificiale è la riproduzione dei meccanismi che
avvengono nei sistemi naturali.
Nello studio della vita artificiale i calcolatori elettronici giocano un ruolo
molto importante, perché possono essere considerati come un laboratorio
in cui effettuare gli esperimenti desiderati. Il computer offre ai ricercatori
un nuovo metodo di studio e permette l’analisi di fenomeni per i quali le
equazioni che li definiscono non hanno soluzione.
Con la simulazione della vita al calcolatore gli studiosi si sono resi conto
che i comportamenti che presentano una grande complessità a livello globale
generalmente emergono da insiemi di unità che hanno regole locali molto
semplici, perciò una conclusione che si può trarre è che anche in natura,
come si è visto precedentemente per la società, i fenomeni complessi hanno
cause semplici.
1.5.1 Genotipo e fenotipo
Dal punto di vista del comportamento dei sistemi viventi è importante la
distinzione tra genotipo e fenotipo. Il genotipo è l’insieme delle istruzioni
genetiche contenute nel DNA di un organismo, mentre il fenotipo è l’organi-
smo fisico, cioè tutto ciò che emerge come risultato dell’interpretazione del
genotipo in un particolare ambiente.
Nel contesto di vita artificiale si rende necessaria la generalizzazione di
queste definizioni in modo che siano applicabili anche nel caso di situazioni
non biologiche. Perciò di si definisce genotipo generalizzato l’insieme
non ordinato di regole di basso livello e fenotipo generalizzato i com-
1. COMPLESSITÀ E SIMULAZIONE 18
portamenti e le strutture che emergono dalle interazioni tra le regole di basso
livello quando sono attivate in un ambiente specifico.
Nella vita artificiale si utilizza la prospettiva bottom-up, secondo cui i
sistemi sono descritti a partire da semplici regole da cui possono essere origi-
nati comportamenti di grande complessità. In questo contesto inizialmente
si definisce il genotipo, cioè il repertorio di comportamenti, e in seguito dal-
le interazioni dell’insieme emerge il comportamento globale del sistema, il
fenotipo.
Se si simula la vita, si può andare incontro a fenotipi complessi costituiti
su più livelli che fanno sì che emergano delle strutture gerarchiche; questa
caratteristica è evidenziata in Langton (1992, 208):
Vale la pena di notare che il fenotipo è un fenomeno a più
livelli. Anzitutto, c’è il fenotipo associato a ciascuna istruzione
particolare − l’effetto che l’istruzione ha sul comportamento di
un’entità quando viene eseguita. In secondo luogo, c’è il feno-
tipo associato a ciascuna entità individuale − il suo particolare
comportamento nell’aggregato. In terzo luogo, c’è il fenotipo
associato al comportamento dell’aggregato come totalità.
1.5.2 Gli algoritmi genetici
Gli studi sulla vita artificiale hanno permesso di formulare delle tecniche
evolutive che si basano sull’imitazione del processo di evoluzione biologica.
In natura le regole, o gli individui, si riproducono, mutano e si estinguono
con l’obiettivo di diffondere soltanto gli esemplari migliori.
Uno dei primi esempi di utilizzazione del modello evolutivo per la ricerca
di soluzioni è rappresentato dagli algoritmi genetici, creati da John Holland,
che con il loro utilizzo ha cercato di rappresentare il processo naturale di
1. COMPLESSITÀ E SIMULAZIONE 19
evoluzione biologica in un modello che sia utile a cercare le soluzioni dei
problemi.
In Ferraris (1999) si legge che in un algoritmo ogni genotipo è rappre-
sentato da una stringa di caratteri (possono essere ‘‘0’’ e ‘‘1’’) che descrive
una particolare strategia; ad ogni individuo è assegnato un fitness value, che
indica il suo grado di adattamento ed è calcolato in base ai risultati ottenuti
dall’applicazione della strategia nell’ambiente circostante.
Durante ogni iterazione alcuni individui della popolazione sono selezionati
per la riproduzione, con particolare attenzione a scegliere quelli con il fitness
value più alto, e altri per l’estinzione. La riproduzione avviene copiando
e incrociando (crossover) le stringhe dei genitori, in modo che ai figli sia
trasmesso il patrimonio genetico di entrambi, proprio come accade in natura.
Per rendere possibile gli errori nella trasmissione genetica genitori-figli è
stata introdotta la mutazione, secondo la quale alcuni caratteri possono essere
modificati in modo casuale; il meccanismo di scelta dei caratteri avviene in
base ad una data probabilità, che in genere è molto bassa.
Dopo l’esecuzione dei processi di evoluzione e di riproduzione per più
volte si può notare che la popolazione converge verso un unico tipo di indi-
viduo al quale è associato un alto fitness value; questo significa che strategia
incorporata nelle stringhe è la migliore per l’ambiente considerato.
1.6 La simulazione e le scienze sociali
Nelle scienze della natura, come la fisica e la chimica, le teorie formulate pos-
sono essere verificate direttamente in laboratorio affinché i ricercatori siano in
grado di verificare la correttezza delle loro ipotesi. Gli esperimenti di questo
tipo consentono di capire quali sono i fattori che danno origine a determinati
fenomeni e di modificare alcuni aspetti dei primi per osservare le conseguenze
al sistema generale.
1. COMPLESSITÀ E SIMULAZIONE 20
L’opportunità di verificare le teorie non è invece disponibile per le scienze
sociali, in quanto non dispongono di un vero e proprio laboratorio. La simula-
zione al computer offre a queste discipline un nuovo ed importante strumento
di ricerca, in quanto grazie ad essa sociologi, psicologi ed economisti possono
studiare alcuni aspetti della realtà, ad esempio processi e relazioni non lineari,
tramite la creazione nel computer di modelli accuratamente specificati.
La simulazione al computer è considerata la ‘‘terza via’’ (Gilbert e Ter-
na, 2000) disponibile agli studiosi delle scienze sociali, in una classificazione
che comprende i modelli letterario-descrittivi e quelli matematico-statistici;
i primi sono molto flessibili ma la loro adeguatezza non può essere verificata
con strumenti di calcolo, mentre i secondi sono computabili ma hanno un
grave problema rappresentato semplificazioni imposte, che possono causare
un allontanamento dalla realtà. I modelli di simulazione offrono perciò un
giusto compromesso tra le esigenze di flessibilità dei primi e le possibilità di
computazione dei secondi (Terna, 2003a).
Una definizione del metodo simulativo è fornita in Parisi (1999, 28):
Le simulazioni sono teorie interpretative dei fenomeni della
realtà formulate come un programma che gira in un computer. Le
teorie della scienza mirano a identificare i meccanismi, i processi,
i fattori che stanno dietro ai fenomeni e che spiegano i fenomeni,
ce li fanno capire. Adottare il metodo della simulazione significa
tradurre una teoria in un programma di computer, far girare il
programma nel computer e verificare se il programma, cioè la si-
mulazione, riproduce i fenomeni che la teoria intende spiegare. Le
simulazioni sono il terzo strumento della scienza, uno strumento
che si è aggiunto abbastanza di recente, cioè da quando computer
veloci e potenti sono divenuti accessibili a qualunque scienziato,
1. COMPLESSITÀ E SIMULAZIONE 21
ai due strumenti di ricerca tradizionali: le teorie e gli esperimenti
di laboratorio.
Axtell (2000) osserva che la tecnica della simulazione ad agenti può esse-
re usata in tre casi distinti. Nel primo, il più semplice, si presenta quando
il fenomeno sociale che si va a studiare può essere completamente descritto
da equazioni risolvibili analiticamente o numericamente; in questo caso la
simulazione può essere usata come metodo alternativo per arrivare agli stessi
risultati o come strumento per presentarli in modo più facilmente compren-
sibile rispetto a quelli di un modello matematico. Un secondo uso emerge nel
caso in cui il modello matematico adottato per analizzare il processo sociale
possa essere descritto ma le sue equazioni non siano risolvibili oppure i risul-
tati non siano stabili. Infine, il terzo tipo di utilizzo si ha nel caso di problemi
sociali per i quali non è possibile una spiegazione fondata su equazioni; la
simulazione ad agenti è perciò l’unico metodo con cui è possibile studiare
questi fenomeni.
Gli utilizzatori della simulazione possono avere diversi obiettivi e, in par-
ticolare, se ne possono distinguere almeno tre (Conte, 1998 e Edmonds,
2003):
1. la proiezione, cioè l’uso di modelli per prevedere gli avvenimenti futuri
legati ad un particolare fenomeno; queste simulazioni non sono necessa-
riamente basate su un modello ad agenti e risultano molto utili quando
il sistema su cui si indaga è di natura complessa, ad esempio se si tratta
di un processo non lineare. La simulazione in questo caso può essere
utilizzata per prevedere gli esiti di interventi di politica economica o
sociale;
2. la sperimentazione, nel caso in cui con la simulazione si intendano spie-
gare dei particolari fenomeni e si desideri verificare la qualità dei mo-
delli proposti. Il modello creato nel computer può essere usato in due
1. COMPLESSITÀ E SIMULAZIONE 22
modi: manipolando le variabili del modello, possibilità particolarmente
indicata quando non si possono realizzare modifiche nella realtà oppure
quando si intende valutare quali siano le cause scatenanti di partico-
lari eventi, con l’obiettivo di utilizzare il computer come un vero e
proprio ‘‘laboratorio” delle scienze sociali; un secondo modo di utilizzo
è l’osservazione del comportamento del modello ‘‘così come è’’ e dei
fenomeni che hanno origine da esso;
3. infine, l’esplorazione del fenomeno costruito nel ‘‘laboratorio virtua-
le”, per osservare e studiare i diversi aspetti delle dinamiche sociali e
l’evoluzione della cooperazione tra gli agenti.
1.7 Lo sviluppo di una simulazione
Lo sviluppo di una simulazione prevede lo svolgimento di due fasi, la prima
di modelling, cioè la costruzione nel computer del modello da simulare, e in
seguito la simulazione vera e propria.
Modelling
Durante questa fase si crea una struttura all’interno del computer che sia in
grado di imitare un certo aspetto della realtà (Edmonds, 2003); il modello
solitamente è soggetto a dei parametri, perciò è possibile che lo stesso possa
essere adattato per simulare e analizzare diversi aspetti della stessa realtà.
La ‘‘bontà’’ di un modello è valutata in base ai seguenti criteri (Edmonds,
2003):
• la correttezza; un modello può essere costruito scegliendo uno tra i due
metodi maggiormente diffusi: il primo propone di seguire i principi che
sono stati sviluppati precedentemente per fenomeni simili ed è funzione
1. COMPLESSITÀ E SIMULAZIONE 23
del successo che essi hanno avuto; il secondo metodo consiste nel tenta-
tivo di imitare il più possibile il processo reale ed è il più impegnativo
e difficoltoso;
• la precisione dei principi utilizzati per costruire il modello, che è mi-
surata dalla differenza tra i risultati del modello e quelli della realtà;
generalmente la perfetta correttezza non è raggiungibile a causa della
presenza persistente di fenomeni che la ostacolano;
• la generalità, che indica la possibilità di applicare un modello in diverse
circostanze; generalmente si tende a preferire un modello più versatile
rispetto ad uno più specifico;
• la semplicità, qualità importante quando il modello deve essere appli-
cato o interpretato;
• il costo richiesto per la creazione del modello, che spesso rappresenta
uno dei criteri guida nelle scelte dei modelli di simulazione con lo scopo
di ricerca;
Un aspetto importante di questa fase riguarda la scelta del modello da
utilizzare, in quanto ne esistono di diversi tipi. In particolare, i modelli usati
dagli economisti e dai teorici dei giochi sono detti matematici e hanno la
caratteristica di definire gli agenti in base ai valori assegnati a determinate
variabili. Un secondo tipo di modelli, detti procedurali, definiscono gli agenti
in base a delle sequenze di azioni eseguite secondo regole interne.
Infine è necessario stabilire l’affidabilità del modello usato. Occorre os-
servare che si possono riscontrare diverse cause di inaffidabilità in un modello
(Conte, 1998), da un primo caso in cui sono elaborate previsioni non verificate
nella realtà fino a situazioni più gravi in cui non è possibile verificare l’atten-
dibilità del modello perché le previsioni sviluppate sono troppo generiche e
perciò impossibili da valutare.
1. COMPLESSITÀ E SIMULAZIONE 24
Simulazione
Durante questa fase si fa funzionare il modello nel computer. Si presenta
però un interrogativo, che riguarda l’utilità della simulazione per un modello
per cui è possibile l’esecuzione analitica; in almeno tre casi l’utilizzo della
simulazione si rende necessario (Conte, 1998):
1. negli studi su sistemi che presentano capacità di apprendimento, in cui
gli agenti imparano interagendo con l’ambiente e con gli altri agenti;
2. negli studi in cui possono emergere nuovi fenomeni a partire da si-
tuazioni conosciute, riscontrabili nell’osservazione di sistemi dinamici
auto-organizzanti, che possono subire delle modifiche per adattarsi ai
cambiamenti dell’ambiente esterno;
3. negli studi sull’evoluzione e sull’adattamento dei sistemi, come nel caso
degli studi dell’Istituto di Santa Fe sui sistemi complessi adattivi.
In tutti questi casi l’esecuzione analitica non può sostituire la simulazione,
perché questa tecnica si rende necessaria per tutti i sistemi il cui studio
prevede delle interazioni con l’ambiente; infatti solo con questo metodo è
possibile consentire ai sistemi di agire in un mondo artificiale, ed in seguito a
queste azioni si possono osservare fenomeni di apprendimento e di evoluzione
dei sistemi.
Infine, ci sono casi per cui l’uso della simulazione è fondamentale, in quan-
to di essi non si può ottenere una soluzione da un modello analitico. Alcuni
esempi riguardano lo studio degli effetti dei sistemi complessi e di quelli sem-
plici; questo secondo caso è molto interessante, perché in queste situazioni la
simulazione ha un carattere esplorativo, cioè è usata per formulare una teoria
e per evidenziare le proprietà più importanti del modello e non per verificare
delle ipotesi, come avviene nel primo caso.
1. COMPLESSITÀ E SIMULAZIONE 25
1.8 I vantaggi della simulazione
Un vantaggio della simulazione consiste nella possibilità di studiare fenomeni
e realtà non direttamente accessibili; questa caratteristica si è rivelata molto
importante per archeologi e storici, che con la simulazione dispongono così
di un nuovo e importante strumento di studio.
Con la simulazione si possono perciò studiare tutti i sistemi, sia quelli
semplici sia quelli complessi; da questo punto di vista la simulazione rap-
presenta per i ricercatori un metodo più completo rispetto al laboratorio,
all’interno del quale si possono analizzare soltanto i sistemi semplici, per-
ché quasi tutti i fenomeni che interessano le scienze della natura e dell’uomo
danno origine a sistemi complessi (Parisi, 1999).
La simulazione consente inoltre di elaborare modelli che mirano ad otte-
nere particolari risposte, ad esempio conoscere quali saranno le conseguenze
originate da un particolare insieme di fattori; grazie a questo metodo gli stu-
diosi delle scienze sociali possono valutare gli effetti originati da particolari
provvedimenti economici o sociali prima della loro applicazione nella realtà.
L’uso della simulazione costringe l’utilizzatore a specificare il modello in
modo molto dettagliato, senza lasciare spazio a ‘‘scatole nere’’ di cui non si
conosce il funzionamento. Quindi grazie questo metodo i ricercatori possono
conoscere la realtà in modo molto approfondito e sono in grado di formulare
le loro teorie in un modo chiaro ed esplicito (Parisi, 1999).
Infine, un altro pregio della simulazione è l’aver reso possibile l’incontro
fra diverse discipline, sia per quanto riguarda il metodo di ricerca scelto sia
per i temi di studio, che si sono rivelati, in alcuni casi, di carattere multi-
disciplinare. I temi unificanti che sono emersi dai vari studi sono i seguenti
(Conte, 1998):
• l’emergenza, cioè la manifestazione spontanea di fenomeni inaspettati
a partire da modelli conosciuti;
1. COMPLESSITÀ E SIMULAZIONE 26
• la complessità, che si può concretizzare, ad esempio, nella formazione
di organizzazioni oppure nella specializzazione funzionale;
• l’evoluzione degli agenti e dei sistemi in risposta all’ambiente circostan-
te;
• la distribuzione, ovvero la condivisione di proprietà e comportamenti
da parte delle unità del modello;
• la comunicazione, che è necessaria al coordinamento ed alla diffusione
di regolarità.
1.9 I problemi della simulazione
Il più noto dei problemi legati all’uso della simulazione riguarda l’interpreta-
zione dei dati che sono originati dal modello, una questione approfondita nel
paragrafo seguente. Da un lato, se questi ultimi non confermano le ipotesi
iniziali, è difficile capire se il risultato sia attribuibile ad un errore di speci-
ficazione del modello o semplicemente ad uno di programmazione; dall’altro
lato, se le ipotesi sono confermate, risulta difficoltoso affermare l’adeguatez-
za dei risultati, perché oltre a quelli espliciti possono essercene anche altri
impliciti.
Un secondo tipo di problema riguarda la progettazione del modello. Pur
avendo il vantaggio di usare linguaggi di programmazione non particolar-
mente difficili, questa fase ha un primo tipo di costo che può essere misurato
nel tempo dedicato alla progettazione del modello, in quanto è necessario
imparare il linguaggio da usare; dopo aver scritto il codice si presenta un
altro costo, rappresentato dal tempo impiegato a controllare che non ci siano
errori nel programma.
Un ulteriore problema consiste nella definizione delle assunzioni relative
ai diversi aspetti delle realtà che si studiano e nella scelta del modello e dei
1. COMPLESSITÀ E SIMULAZIONE 27
valori da assegnare ai parametri, che possono richiedere del tempo, necessario
all’utilizzatore per scegliere la migliore delle possibilità.
Infine, un ultimo problema riguarda il realismo della simulazione, definito
in Conte (1998) come la trappola della verosimiglianza. La simulazione rap-
presenta una semplificazione della realtà, individuando i fattori fondamentali
che determinano i fenomeni oggetto di studio, e ogni miglioramento che si
vuole portare richiede maggiori sforzi di progettazione. Tuttavia è anche im-
portante trovare il giusto bilanciamento tra i dettagli necessari e quelli che
non lo sono, per non correre il rischio di fare un’errata specificazione e creare
un modello che non è in grado di rappresentare la realtà studiata.
1.10 L’interpretazione dei modelli
Il problema dell’interpretazione dei risultati di una simulazione ha una grande
importanza perché, come argomentato in Axtell e Epstein (1994), se non si
è in grado di comprendere i sistemi complessi artificiali meglio di quanto si
riesce a fare per quelli reali non si è giunti a nessun miglioramento.
Per rendere comprensibili per se stessi e per gli altri i modelli è necessario
seguire alcune indicazioni descritte in Gilbert e Terna (2000).
Occorre innanzitutto considerare gli agenti come degli oggetti, cioè parti
di codice informatico in grado di contenere dati e regole su come agire su
essi; queste regole forniscono la spiegazione di come gli agenti reagiscono ai
messaggi provenienti dall’ambiente esterno.
Inoltre è necessario osservare sia il comportamento individuale degli agen-
ti, determinato dalle variabili di stato di ognuno di essi, sia il comportamen-
to che emerge dalle loro interazioni a livello aggregato. In Terna (1998)
si afferma che, da un punto di vista metodologico, possono esistere due ti-
pi di emergenza: l’emergenza imprevista, ma in qualche modo prevedibile,
cioè quando all’interno del modello compare un comportamento ricorrente
1. COMPLESSITÀ E SIMULAZIONE 28
le cui cause sono nascoste all’interno della struttura stessa del modello, e
l’emergenza imprevedibile, che si manifesta quando i dati di un esperimento
hanno caratteristiche simili a quelli di un fenomeno caotico; il caos è osser-
vabile nei fenomeni economici e sociali, ma non è facile tentare di riprodurlo
in un modello ad agenti.
Infine, occorre valutare se la simulazione ha successo e per fare ciò si
potrebbe utilizzare un metodo matematico-statistico, ma siccome potrebbe
risultare difficile da applicare ad un modello computazionale, spesso si uti-
lizzano criteri differenti. Un primo modo consiste nel confrontare ciò che si
conosce del comportamento degli agenti appartenenti al modello con le loro
reali azioni durante la simulazione.
Un metodo di valutazione più rigoroso è rappresentato dall’esame degli
effetti degli agenti a livello aggregato, considerando le strutture ed i gruppi
che emergono; secondo Axtell e Epstein (1994) i modelli ad agenti possono
essere classificati in base a quattro livelli:
Livello 0, se il modello è una caricatura della realtà, come stabilito tramite
l’utilizzo di semplici dispositivi grafici.
Livello 1, se il modello è conforme qualitativamente con le macro-strutture
empiriche, come dimostrato se si tracciano le distribuzioni di alcune
caratteristiche della popolazione di agenti.
Livello 2, se il modello è conforme quantitativamente con le macro-strutture
empiriche, come stabilito da procedure statistiche.
Livello 3, quando il modello mostra coerenza qualitativamente e quanti-
tativamente con le micro-strutture empiriche determinate da analisi
cross-section sugli agenti della popolazione.
Questi livelli sono progressivi, perciò se un modello presenta performance
di livello n conseguentemente sarà soddisfacente anche al livello n−1.
1. COMPLESSITÀ E SIMULAZIONE 29
I risultati della simulazione riguardanti il comportamento collettivo po-
trebbero risultare difficili da comprendere tanto quanto la stessa realtà; que-
sto problema è simile a quello incontrato nella vita artificiale riguardante la
comprensione dei legami tra il genotipo e il suo fenotipo1. In questo ambi-
to l’idea fondamentale è che il comportamento degli agenti è semplice ma
si adatta all’ambiente esterno e alle relazioni con gli altri agenti, perciò è
possibile che dalle interazioni emergano fenomeni complessi e inattesi.
Nel problema dell’interpretazione del modello è necessario includere an-
che la comprensione del programma utilizzato per far funzionare il modello
al computer (Axtell e Epstein, 1994), per verificare che esso faccia ciò che
l’utilizzatore desidera e che non ci siano delle imprecisioni dovute alla di-
sattenzione del programmatore, ad esempio errori nell’indicizzazione delle
matrici usate dagli agenti.
1.11 Gli agenti
Wooldridge e Jennings (1995) sostengono che la definizione più generale che
può essere data al termine agente consiste nel considerarlo un sistema com-
putazionale posto in un certo ambiente dotato delle seguenti caratteristiche:
• autonomia, che gli consente di operare senza la necessità di un inter-
vento umano;
• abilità sociale, cioè capacità di interagire e comunicare con altri agenti;
• reattività, che gli permette di reagire in modo tempestivo ai cambia-
menti dell’ambiente circostante;
• capacità di prendere iniziative guidate da obiettivi interni, o pro-attività.
1vedi paragrafo 1.5.1
1. COMPLESSITÀ E SIMULAZIONE 30
Secondo coloro che studiano l’intelligenza artificiale, l’agente è un sistema
computerizzato che, oltre a possedere le caratteristiche sopra descritte, è
concepito usando concetti che sono abitualmente applicati agli esseri umani.
Ad esempio, è possibile definire gli agenti usando caratteristiche come la
conoscenza, le opinioni, le intenzioni, i desideri e i doveri.
Una teoria soddisfacente degli agenti deve essere in grado di illustrare
in modo approfondito tutti gli attributi sopra considerati e di mostrare in
che modo sono collegati questi ultimi; ad esempio, dovrà specificare come
l’ambiente influisce sul comportamento dell’agente e come gli obiettivi e le
informazioni guidano le sue azioni.
È possibile effettuare una classificazione generale degli agenti usati in una
simulazione in base ai loro meccanismi di decisione, alla capacità di adatta-
mento e di apprendere; se gli agenti sono privi di capacità di apprendimento
sono detti ‘‘senza mente”, in caso contrario ‘‘con mente”. Inoltre si può ef-
fettuare una distinzione anche secondo l’ambiente in cui si trovano, che può
essere neutrale o strutturato, cioè dotato di regole precise a cui gli agenti
devono attenersi. Ne consegue che gli agenti possono essere raggruppati in
quattro categorie (Terna, 2003a):
1. agenti ‘‘senza mente’’ in un ambiente neutrale, o non strutturato;
2. agenti ‘‘senza mente’’ in un ambiente strutturato;
3. agenti ‘‘con mente’’ in un ambiente neutrale;
4. agenti ‘‘con mente’’ in un ambiente strutturato.
Nel primo caso, agenti senza mente in ambiente neutrale, si osserva che
dalla simulazione emerge un fenomeno complesso, con elementi di caos ge-
nerati indirettamente dagli agenti; in questi tipi di esperimenti si possono
1. COMPLESSITÀ E SIMULAZIONE 31
notare due tipi di emergenza, quella imprevista e quella imprevedibile, illu-
strate nel paragrafo 1.10. Tuttavia i fenomeni provocati da agenti di questo
tipo non sono realistici, perciò sono di scarso interesse scientifico.
Al contrario, se si inseriscono agenti senza mente in un ambiente strut-
turato, ad esempio la borsa, si nota che si creano fenomeni complessi che
originano risultati realistici grazie alla presenza di un ambiente con regole.
L’aspetto interessante di questo esempio è che l’emergenza di situazioni com-
plesse è dovuta alle caratteristiche dell’ambiente e non a quelle degli agenti
operanti.
Nel terzo caso si presentano agenti con mente in un ambiente neutrale.
In questa situazione gli agenti economici sono in grado di imparare ad agire
in modo coerente, conoscendo a mano a mano quali sono le conseguenze
che derivano da una particolare azione; per un osservatore esterno gli agenti
di questo tipo sembrano operare seguendo obiettivi e strategie interne, ma
in realtà sono guidati soltanto da semplici regole e il loro comportamento
è dovuto soltanto alla loro capacità di adattamento. I risultati indicano
l’emergere di un ordine in linea con la prospettiva dell’ordine spontaneo di
Hayek.
Infine, utilizzando agenti con mente in un ambiente strutturato si va in-
contro all’emergenza di fenomeni complessi come nel secondo caso; inoltre in
questa situazione gli agenti si adattano ed imparano e sono in grado di deter-
minare risultati importanti anche a livello individuale, sviluppando strategie
che ad un osservatore esterno possono sembrare non ovvie.
Capitolo 2
Gli strumenti per la simulazione
In questo capitolo si presentano Swarm, NetLogo, e RePast, alcuni strumenti
con i quali è possibile costruire all’interno del computer modelli di simulazione
ad agenti.
Tra essi Swarm è quello che vanta la maggior diffusione e la maggior ro-
bustezza del codice (Terna, 2003a) ed è presentato in modo più approfondito,
perché è il protocollo di programmazione su cui si basa jES (java Enterprise
Simulator), che sarà descritto nel capitolo 4.
Su NetLogo e RePast sono fornite soltanto alcune informazioni che con-
sentono di comprendere come è strutturato l’ambiente di simulazione.
2.1 Swarm
Il progetto Swarm1 nasce nel 1994 dall’idea di Chris Langton ed è successi-
vamente sviluppato all’interno dell’Istituto degli Studi sulla Complessità di
Santa Fe.
Swarm è una piattaforma informatica con cui è possibile effettuare simula-
zioni di sistemi complessi adattivi; l’unità base della simulazione è lo sciame,
1Disponibile alla pagina web http://www.swarm.org e http://wiki.swarm.org
32
2. GLI STRUMENTI PER LA SIMULAZIONE 33
che è definito come un insieme di agenti che eseguono una serie di azioni.
Swarm offre delle librerie di componenti con le quali si possono costruire
modelli e analizzarli.
Figura 2.1: Logo di SWARM
In Minar, Burkhart, Langton e Askenazi (1996) si legge che uno dei prin-
cipali motivi della nascita del progetto Swarm è l’esigenza di disporre di uno
strumento versatile per lo studio dei sistemi complessi che possa essere fa-
cilmente comprensibile ed utilizzabile dai ricercatori di diverse discipline; il
progetto deve pertanto la sua nascita al lavoro congiunto di più studiosi, che
hanno avuto come obiettivo primario la creazione di una ‘‘lingua franca della
simulazione ad agenti” (Terna, 2003a).
Prima della sua creazione nell’ambito dello studio dei sistemi complessi
era presente un grande numero di modelli di simulazione, che risultavano di
difficile interpretazione e comprensione per chi tentasse di avvicinarsi allo
studio di un particolare fenomeno. Il motivo principale è che le piattaforme
di simulazione esistenti erano molto specifiche e contenevano un numero di
assunzioni implicite che erano chiare soltanto ai creatori del software.
Swarm presenta il vantaggio di poter essere utilizzato in diverse area di
ricerca, ad esempio nella chimica, nell’ecologia, nell’economia e nelle scienze
2. GLI STRUMENTI PER LA SIMULAZIONE 34
sociali, grazie al fatto che il codice informatico relativo al comportamento
degli agenti deve essere integralmente scritto dall’utilizzatore; il progetto
infatti fornisce soltanto le funzioni generiche di gestione del tempo, dei cicli
di funzionamento e di interazione grafica con l’utente.
2.1.1 Sviluppo di una simulazione
Il formalismo adottato da Swarm prevede un insieme di agenti che interagi-
scono tra loro mediante eventi. L’agente è l’oggetto principale all’interno di
una simulazione e può generare eventi che interessano se stesso o altri agenti.
Il verificarsi degli eventi è regolato da un calendario interno che descrive
le azioni nel preciso ordine in cui devono essere eseguite; il tempo avanza solo
nel momento in cui gli eventi inseriti nella sequenza sono stati eseguiti.
La componente che organizza gli agenti è detto sciame (o swarm) e rap-
presenta un intero modello, in quanto contiene gli agenti e la rappresentazione
del tempo, vale a dire una sequenza di attività che devono essere eseguite.
Gli sciami possono essere anche agenti, oltre che i loro contenitori; un
agente per definizione è costituito da un insieme di regole e di capacità di ri-
sposta agli stimoli ma, come si legge in Minar, Burkhart, Langton e Askenazi
(1996), può essere allo stesso tempo anche uno sciame, cioè una collezione di
oggetti e di sequenze di azioni da svolgere. In questa situazione il comporta-
mento dell’agente è definito dalle interazioni che si svolgono all’interno dello
sciame.
Un semplice esempio di quanto esposto si può avere nel caso di una simula-
zione di carattere economico; se si sceglie di studiare un distretto industriale,
si ottiene che lo sciame è composto dalle aziende che compongono il distretto
e ogni azienda rappresenta un agente con un proprio comportamento. Ma si
può raggiungere un livello di dettaglio maggiore del sistema economico se si
afferma che ogni impresa appartenente al distretto è anch’essa uno sciame:
2. GLI STRUMENTI PER LA SIMULAZIONE 35
infatti può essere composta da agenti che rappresentano, per esempio, le uni-
tà produttive, gli impiegati e gli operai, e ha un calendario interno distinto
da quello del modello generale. Nel caso si volesse studiare il comportamento
dei singoli agenti all’interno di un’impresa, per analizzare ad esempio il ruolo
dell’imprenditore, si potrebbe creare uno sciame che lo rappresenta, forma-
to da agenti che determinano il suo comportamento generale e un orologio
interno che indica gli eventi da svolgere. Si creerebbe in questo modo una
gerarchia di modelli interdipendenti tra loro.
Per effettuare una simulazione in qualsiasi ambito di ricerca occorre por-
tare a termine una serie di azioni che possono essere riassunte in uno schema
generale:
• l’utilizzatore deve definire gli agenti e stabilire le regole che definiscono
il loro comportamento; inoltre deve decidere quali relazioni intercorrono
tra loro;
• in seguito deve inserire tutti gli agenti all’interno di uno sciame, descri-
vendo un elenco di attività da svolgere con l’indicazione dei tempi in
cui devono essere portate a termine;
• il ricercatore deve anche definire quali strumenti utilizzare per osservare
l’andamento della simulazione (grafici, statistiche, ...); essi sono messi a
disposizione dalle librerie di Swarm e sono anch’essi agenti appartenenti
ad uno sciame, detto observer. Il motivo del ricorso a questa opzione
dipende dal fatto che il fine ultimo dei ricercatori non è far funzionare il
modello, ma analizzare la nascita e l’evoluzione dei fenomeni complessi
nei mondi da loro costruiti;
• dopo aver definito e combinato il model e l’observer, l’apparato di
simulazione è completo ed è possibile far ‘‘funzionare” l’universo creato.
2. GLI STRUMENTI PER LA SIMULAZIONE 36
Dallo schema proposto risalta il fatto che la struttura di Swarm è com-
posta da due livelli differenti (Terna, 1998): al primo livello si ha il modello
(model), che rappresenta il fenomeno che si vuole analizzare, al secondo l’os-
servatore, (observer) che considera il modello come un unico oggetto con
il quale interagisce per ottenere i risultati richiesti dagli strumenti che il
ricercatore utilizza per analizzare il mondo creato.
Riprendendo l’esempio precedente sul distretto industriale, nella Figu-
ra 2.2 è mostrato un esempio sintetico della struttura della simulazione. Nel
model sono presenti gli agenti, cioè le industrie, e un gestore del tempo che
contiene le azioni da svolgere; nell’observer vi sono altri tipi di agenti, vale a
dire gli strumenti di controllo del modello, e un altro gestore del tempo. Sia
il model sia l’observer sono sciami.
Figura 2.2: Struttura di una simulazione
2.1.2 Caratteristiche principali
La struttura di Swarm è realizzata con il linguaggio di programmazione ad
oggetti Objective C. Questo stile di programmazione consiste nella definizione
2. GLI STRUMENTI PER LA SIMULAZIONE 37
di varie classi di oggetti; un oggetto è la combinazione di variabili di stato, che
ne definiscono le caratteristiche interne, e di metodi, che ne rappresentano il
comportamento.
Dalla versione 2.0 di Swarm gli utilizzatori possono scrivere i modelli
con il linguaggio Java, creato dalla Sun Microsystem; i vantaggi principali
di questo linguaggio sono la scarsa possibilità di creare errori all’interno del
modello e la sua grande diffusione (Johnson e Lancaster, 2000).
Le caratteristiche più importanti della programmazione object-oriented
dal punto di vista dell’utilizzo di Swarm sono l’incapsulamento e l’eredita-
rietà, che permettono di creare software utilizzabili in più situazioni richia-
mando semplicemente la classe di una libreria che si vuole utilizzare.
Secondo il principio dell’incapsulamento i dettagli interni di un ogget-
to sono protetti e non possono essere messi a disposizione dell’utente, ad
eccezione di quei metodi che sono scritti con l’obiettivo di trasmettere infor-
mazioni all’esterno. Come spiegato in Sciabarrà (2003), la programmazione
object-oriented applica all’informatica dei concetti che sono comuni nel modo
in cui le persone considerano gli oggetti fisici. Prendendo una semplice radio
come esempio di oggetto, possiamo notare che presenta la caratteristica di
essere incapsulato: infatti, per poterla utilizzare non occorre essere esperti
di elettronica, è sufficiente agire sui pulsanti; la stessa cosa avviene nel caso
degli oggetti informatici, dal momento che gli utenti possono agire solo sui
metodi che sono messi a loro disposizione dall’oggetto, senza dover conoscere
le sue caratteristiche interne.
L’ereditarietà permette che ogni sottoclasse erediti le variabili ed i metodi
della classe base, che è chiamata superclasse. In questo modo si può creare
una classe che contiene i metodi della classe di livello superiore e ne aggiunge
di nuovi. Tornando all’esempio della radio, possono essercene di diverse tra
loro che hanno una maggiore ricezione o un altoparlante più potente; queste
2. GLI STRUMENTI PER LA SIMULAZIONE 38
ultime ereditano le caratteristiche di base dalla radio normale, che, con una
metafora informatica, potrebbe essere definita la superclasse delle radio.
2.1.3 Le ‘‘sonde’’
Le sonde, o probes, permettono all’utilizzatore di interagire con gli oggetti
della simulazione osservando e modificando i valori delle variabili; il loro
maggior vantaggio sta nel non dover aggiungere nuovo codice informatico
per poterle utilizzare.
Una sonda è una finestra rettangolare nelle cui righe sono descritti gli
attributi dell’oggetto preso in considerazione; i dati mostrati possono riguar-
dare il modello in generale oppure possono rappresentare le informazioni di
un semplice agente che opera all’interno del modello. Tutti i progetti co-
struiti con Swarm hanno almeno due sonde: quella del ModelSwarm, che
indica i parametri del modello, e quella dell’ObserverSwarm, che contiene
le caratteristiche degli strumenti utilizzati per analizzare l’andamento della
simulazione.ella Figura 2.3 sono mostrati due esempi di sonde di model e
observer.
Figura 2.3: Esempi di sonde
2. GLI STRUMENTI PER LA SIMULAZIONE 39
2.1.4 Le librerie di Swarm
Le librerie di Swarm hanno due funzioni principali: elencano una serie di clas-
si che i costruttori del modello possono utilizzare e sono impiegate per creare
delle sottoclassi più specifiche per le particolari finalità della simulazione.
In Minar, Burkhart, Langton e Askenazi (1996) le librerie sono suddivise
in due gruppi: da un lato quelle fondamentali per ogni modello di simulazio-
ne, swarmobject, activity e simtools, dall’altro le librerie di supporto, utili per
la creazione di modelli che rispondano a particolari esigenze, defobj, collec-
tions, random, tkobjc.
La libreria swarmobject contiene le classi principali su cui si basano gli
agenti creati nel modello. Questa libreria contiene la classe SwarmObject,
dalla quale tutti gli agenti ereditano il loro comportamento, e la classe Swarm,
che è utile per la scrittura del ModelSwarm e dell’ObserverSwarm.
La libreria activity permette la definizione del calendario degli eventi e
supporta l’esecuzione della simulazione.
Infine, l’ultima libreria specifica è simtools, un insieme di classi che con-
trollano l’intero svolgimento della simulazione. Le classi contenute in questa
libreria possono, ad esempio, creare grafici riassuntivi ed elaborare statistiche.
Passando al secondo gruppo di liberie, defobj definisce le indicazioni stan-
dard per la creazione degli oggetti, per l’archiviazione di dati e per il tratta-
mento degli errori.
La libreria collections mette a disposizione le classi utili per seguire gli
oggetti, per esempio mappe e liste.
La libreria random offre all’utente una serie di classi che generano numeri
casuali e che possono trasformare sequenze di numeri casuali in numerose
distribuzioni di probabilità. Nella simulazione al computer la fase della gene-
2. GLI STRUMENTI PER LA SIMULAZIONE 40
razione di numeri casuali è molto importante, in quanto influenza i risultati
finali, pertanto è fondamentale evitare di utilizzare generatori di numeri con
distorsioni o correlazioni tra loro.
L’ultima libreria del supporto di base di Swarm è tkobjc, che contiene gli
oggetti base per la creazione di un’interfaccia per l’utente; con le sue classi è
possibile creare bottoni, istogrammi e grafici.
In aggiunta alle librerie base richieste per la simulazione ci sono molte al-
tre librerie che possono essere utilizzate per la costruzione di particolari mo-
delli. Esistono librerie che supportano gli spazi bidimensionali, gli algoritmi
genetici e le reti neurali.
La libreria space è utile nella costruzione di ambienti in cui gli agenti
interagiscono tra loro; è prevista la definizione di uno spazio a due dimensio-
ni, simile ad una griglia di punti nella quale sono collocati gli oggetti della
simulazione.
Infine, ga rappresenta la prima libreria creata dal gruppo di utilizzatori
di Swarm e consente l’uso di algoritmi genetici, mentre neuro permette di
utilizzare le reti neurali artificiali.
2.2 NetLogo
NetLogo2 è un ambiente per la simulazione di fenomeni naturali e sociali
scritto in Java.
Nasce nel 1999 dall’unione di StarLisp e Logo. Dal primo, un parallelo del
Lisp, eredita la struttura a più agenti, mentre dal secondo deriva la possibilità
di controllare una ‘‘tartaruga’’ (turtle); Logo era molto popolare per l’ottima
grafica, ma aveva il difetto, superato da NetLogo, che nel modello poteva
esserci una sola tartaruga. NetLogo rappresenta inoltre il risultato degli
2Disponibile alla pagina web http://ccl.northwestern.edu/netlogo
2. GLI STRUMENTI PER LA SIMULAZIONE 41
studi su StarLogoT fatti dai suoi creatori, che hanno riscritto completamente
il linguaggio e ridisegnato l’interfaccia grafica.
Figura 2.4: Logo di NetLogo
Gli utilizzatori possono inserire istruzioni per gli agenti indipendenti che
operano in parallelo nel modello; questo rende possibile l’analisi delle con-
nessioni tra i comportamenti individuali degli agenti e la caratteristiche che
emergono dall’interazione di popolazioni di individui.
Gli studi di fenomeni complessi effettuati con NetLogo possono interessare
una grande varietà di ambiti di studio, quali, per esempio, le scienze naturali,
la biologia, la medicina, la matematica, le scienze sociali, l’economia e la
psicologia.
2.2.1 Caratteristiche principali
Il mondo di NetLogo è popolato da agenti che seguono le istruzioni impartite
dall’utilizzatore. Nel modello possono esserci tre tipi di agenti (Wilensky,
1999):
• la tartarughe, turtles, che si muovono ed interagiscono tra loro nel mon-
do in cui si trovano; si possono anche definire diversi tipi di tartaru-
ghe, in modo da associare ad essi differenti variabili e comportamenti
e valutare i fenomeni che emergono dalla loro interazione;
• i patch, che sono delle sezioni quadrate di uno spazio continuo a due
dimensioni in cui le tartarughe si possono muovere. I patch hanno
delle coordinate chiamate pxcor, per la dimensione orizzontale, e pycor,
2. GLI STRUMENTI PER LA SIMULAZIONE 42
per la dimensione verticale; il patch al centro del mondo ha coordinate
(0, 0). Il mondo in cui si trovano le tartarughe non è limitato, è un
toroide, perciò se una tartaruga si muove oltre il limite sinistro del
mondo scompare per poi riapparire all’estremo destro della zona che
rappresenta il mondo;
• l’observer, che osserva ciò che accade nel modello; quando si avvia
il modello non esistono tartarughe ed è compito dell’observer crearne
nuove.
Un’importante e nuova caratteristica del linguaggio di NetLogo è l’intro-
duzione dell’agentset, o collezione di agenti, che permette la definizione di un
insieme di agenti aventi le stesse caratteristiche e lo stesso comportamento.
Un agentset può essere costituito da un insieme di più tartarughe o di più
patch di un certo tipo, ad esempio solo tartarughe rosse oppure una colonna
di patch, cioè una serie di patch con la stessa coordinata per l’ascissa.
Oltre alle speciali strutture che supportano il modelli formati da più agen-
ti, NetLogo prevede anche le altre possibilità della programmazione standard
come ad esempio i cicli, le condizioni, le recursioni e le liste.
2.2.2 Obiettivi futuri
In Tisue e Wilensky (2004) si legge che gli obiettivi per il futuro riguardano
l’aumento della velocità di simulazione e una maggiore estendibilità.
Per quanto riguarda il secondo aspetto, NetLogo è nato con la caratte-
ristica di ‘‘piattaforma chiusa”: gli utilizzatori non potevano modificarlo o
controllarlo con codice esterno. I primi miglioramenti si sono avuti con la
versione 2.0.1, nella quale è presente un’interfaccia per le estensioni che con-
sente all’utente di inserire nuovi elementi al modello base; per esempio è ora
possibile far produrre un suono agli agenti usando le capacità midi di Java.
2. GLI STRUMENTI PER LA SIMULAZIONE 43
Tra gli obiettivi delle future versioni del software si ricordano:
• la creazione di 3-D NetLogo, che al linguaggio base aggiunge la grafica
tridimensionale;
• ulteriori miglioramenti nel codice informatico;
• una maggiore flessibilità degli agenti.
2.3 RePast
RePast3, acronimo per REcursive Porous Agent Simulation Toolkit, è uno
strumento per la simulazione ad agenti scritto completamente in Java e simile
a Swarm creato dal Social Science Research Computing dell’Università di
Chicago.
Questo software offre una libreria di classi utili per creare e far funzionare
i modelli di simulazione e per l’uso di grafici che visualizzino i risultati.
Figura 2.5: Logo di RePast
Inizialmente RePast era stato concepito con l’idea di creare una serie
di librerie Java da affiancare a Swarm per semplificarne l’utilizzo; tuttavia
questo progetto venne abbandonato nel momento in cui uscì la versione Java
di Swarm, in quanto RePast rappresentava soltanto un doppione. Pertanto
lo sviluppo di questo software è continuato in modo indipendente da Swarm
all’interno dell’Università di Chicago ed anche in altri ambienti di ricerca.
3Disponibile alla pagina web http://repast.sourceforge.net/index.php
2. GLI STRUMENTI PER LA SIMULAZIONE 44
2.3.1 Obiettivi
In Collier (2003) si legge che gli obiettivi principali dei creatori di RePast
sono il raggiungimento di un buon livello di astrazione della struttura della
simulazione, l’estendibilità, e la performance ‘‘good enough’’.
L’astrazione è una delle caratteristiche più importanti di RePast, che
astrae la maggior parte degli elementi chiave della simulazione ad agenti e li
rappresenta in classi Java. La versione 1.4 di RePast offre una serie di classi
per molte delle più comuni astrazioni della simulazione ad agenti, come ad
esempio le sequenze e la raccolta di dati, componenti utili alla costruzione di
rappresentazioni.
L’estendibilità è resa possibile dall’uso del linguaggio Java, in quanto
la programmazione ad oggetti permette la creazione di strutture estendibili
grazie alle proprietà dell’ereditarietà e dell’incapsulamento.
Il concetto della performance ‘‘good enough’’ si riferisce al livello delle
prestazioni di RePast in rapporto agli altri benefici di questo strumento di
analisi. L’attenzione maggiore dei creatori di RePast è concentrata sulla
minimizzazione del numero di oggetti creati e sulla velocità della simulazione,
che si basa principalmente sui miglioramenti che saranno portati alla Java
Virtual Machine.
2.3.2 Caratteristiche della simulazione
Con RePast è possibile realizzare una simulazione concepita come una sta-
te machine costituita dagli stati di tutte le sue componenti; queste ultime
possono essere divise in due gruppi, l’infrastruttura e la rappresentazione.
L’infrastruttura rappresenta tutti i meccanismi che permettono di far fun-
zionare la simulazione, come ad esempio mostrare e raccogliere dati. Lo stato
dell’infrastruttura è lo stato dei grafici e degli oggetti che raccolgono dati.
La rappresentazione è ciò che l’utilizzatore della simulazione costruisce,
2. GLI STRUMENTI PER LA SIMULAZIONE 45
cioè il modello. Lo stato della rappresentazione è lo stato degli agenti appar-
tenenti al modello, indicato dai valori delle loro variabili e dello spazio in cui
operano.
Qualsiasi modifica agli stati dell’infrastruttura e della rappresentazione
sono realizzati attraverso un calendario; questo meccanismo permette una
grande flessibilità per l’utilizzatore della simulazione.
L’unità di tempo usata dal simulatore è, come in Swarm, il tick e il
passare del tempo è scandito dall’esecuzione delle attività programmate nel
calendario; durante la simulazione si passa al tick successivo solo nel momento
in cui l’azione programmata per un dato tick si è conclusa, perciò in RePast i
tick rappresentano soltanto un modo per far trascorrere gli eventi in un certo
ordine.
Una tipica simulazione costruita con RePast è composta da una serie di
agenti, che possono essere omogenei oppure inseriti all’interno di una ge-
rarchia, e da un modello che controlla che gli agenti eseguano i loro com-
portamenti secondo il calendario interno. Il calendario ha anche il compito
di controllare gli eventi all’interno del modello, ad esempio aggiornando il
monitor e raccogliendo dati, e può essere può essere creato internamente al
modello o esternamente da parte dell’utilizzatore.
Nel formalismo di RePast gli eventi sono chiamati azioni (Collier, 2003).
2.3.3 Le librerie
RePast è composto da 210 classi Java organizzate nelle seguenti librerie:
• la libreria analysis contiene le classi che sono usate per raccogliere dati
e rappresentarli su grafici;
• le classi contenute nel pacchetto engine sono responsabili dell’organiz-
zazione e del controllo di una simulazione;
2. GLI STRUMENTI PER LA SIMULAZIONE 46
• le classi del pacchetto event sono usate internamente da RePast e sono
incaricate, insieme ad alcune della libreria engine, della comunicazione
tra le parti interne del modello non di competenza del calendario della
simulazione;
• la libreria games contiene le classi utili a simulare giochi cooperativi
come il dilemma del prigioniero;
• le classi gui sono responsabili della visualizzazione grafica della simu-
lazione e della possibilità di creare delle animazioni del modello con
QuickTime;
• la libreria network contiene le classi incaricate di creare la rete del-
la simulazione; la classe interna NetworkFactory è usata per creare il
network o per caricarlo da un file;
• il pacchetto space contiene le classi che si occupano delle relazioni
spaziali e possono rappresentare vari tipi di spazio;
• la libreria util contiene classi che possono essere sfruttate sia interna-
mente da RePast sia dall’utilizzatore; le più importanti sono la classe
Random, che contiene un grande numero di distribuzioni casuali, e
SimUtilities, in cui ci sono metodi per creare sonde e liste.
2.3.4 Progetti futuri
Il lavoro dei creatori di RePast è concentrato su Evolver, un rapido ambien-
te di simulazione che può essere composto da diverse parti, ad esempio da
modelli predefiniti e da componenti di analisi; tutto ciò che non è incluso nel
modello base può essere inserito usando il linguaggio NQPython (Not Quite
Python), simile a Python e più semplice di Java, specificamente creato per
integrare RePast.
Capitolo 3
Impresa, imprenditore e
conoscenza
In questo capitolo si presentano gli studi di diversi economisti che hanno avu-
to come oggetto l’impresa e le sue influenze sull’ambiente economico generale.
Nell’esposizione è riservata una particolare attenzione alla figura dell’impren-
ditore e al ruolo assunto dalla conoscenza, con l’obiettivo di comprendere l’im-
portanza che hanno nell’impresa e nel sistema economico secondo le diverse
teorie presentate.
La teoria neoclassica ha presentato la figura dell’imprenditore conside-
randolo come un semplice fattore produttivo dell’impresa, il cui compito è
organizzare al meglio le risorse e scegliere la miglior funzione di produzione.
In piena contrapposizione con i neoclassici si trovano gli esponenti della
Scuola Austriaca, secondo i quali la figura dell’imprenditore è molto impor-
tante sia per l’impresa sia per il sistema economico in generale. L’impren-
ditore ha un ruolo di primo piano all’interno dell’impresa e il suo compito
è scoprire nuove opportunità di profitto nel mercato; questa funzione emer-
ge anche dal significato etimologico del termine imprenditore, che deriva dal
verbo latino prehendo, il cui significato è ‘‘vedere, scoprire, percepire, ren-
47
3. IMPRESA, IMPRENDITORE E CONOSCENZA 48
dersi conto di qualcosa”. L’imprenditore inoltre ha la funzione di trasmettere
nuove conoscenze a tutti gli appartenenti al mercato, perciò nella visione
Austriaca ha una grande importanza per il sistema economico generale.
La visione della Scuola Austriaca è ripresa e approfondita da uno dei
suoi allievi, Israel M. Kirzner, che aggiunge degli elementi nuovi alla figura
dell’imprenditore, la cui principale caratteristica è la capacità di notare nel
mercato ciò che altri imprenditori non sono stati in grado di vedere e in
questo modo di sfruttare nuove occasioni di profitto.
Una nuova posizione emerge dagli studi di Herbert Simon sulle decisio-
ni nelle organizzazioni, secondo i quali l’imprenditore agisce in condizioni
di razionalità limitata; questa situazione è causata dall’impossibilità per gli
individui di raggiungere il grado di conoscenza completa, che consentirebbe
loro di effettuare le scelte in modo perfettamente razionale. Perciò secon-
do Simon l’imprenditore non è in grado di prendere la decisione migliore
possibile, bensì la più soddisfacente in base alle informazioni di cui dispone.
3.1 La teoria neoclassica
Secondo la visione neoclassica l’impresa rappresenta un insieme di fattori che
sono utilizzati per produrre un bene che possa essere venduto ad un prezzo
almeno pari alla somma dei costi affrontati (Colombatto, 2001).
Il processo produttivo per ogni bene è una funzione a se stante all’inter-
no dell’impresa ed agisce secondo meccanismi conosciuti che possono essere
modificati da eventuali variazioni delle variabili esogene, ad esempio il costo
dei fattori produttivi.
Nella prospettiva neoclassica non esistono l’incertezza e le asimmetrie
informative, infatti gli unici dubbi sul futuro riguardano i valori che le va-
riabili esterne all’impresa possono assumere e non il funzionamento interno
o l’attività dell’imprenditore.
3. IMPRESA, IMPRENDITORE E CONOSCENZA 49
L’imprenditore ha il semplice ruolo di amministratore delle risorse, deve
scegliere la funzione di produzione che meglio si adatta all’impresa e verifica
che il funzionamento dell’impresa sia coerente al modello adottato. Le sue
responsabilità non comprendono la scoperta di nuove opportunità di profitto
o qualsiasi altra attività volta a produrre innovazioni; inoltre la perfetta
informazione non permette l’esistenza di imprenditori migliori di altri, che
siano cioè in grado di ottenere condizioni più vantaggiose nel mercato.
Tuttavia non è vero dire che l’impresa non è soggetta a nessun tipo di
incertezza, in quanto gli stessi neoclassici sostengono che il concetto di im-
prenditori tutti uguali è soltanto una finzione per rendere più semplice la
modellistica. In questo contesto se si considerasse l’esistenza di aleatorietà,
questa potrebbe essere eliminata dalla perfetta informazione, cioè dalla pos-
sibilità per gli imprenditori di conoscere tutte le caratteristiche degli eventi
che li potrebbero riguardare in modo da poter decidere la miglior strategia da
adottare. Ma le informazioni possono avere un costo e l’imprenditore sceglie-
rà di non usufruirne più nel momento in cui la spesa generata sarà superiore
ai benefici creati.
Pertanto in Colombatto (2001) si sostiene che nell’ambito neoclassico è
possibile ottenere imprenditori e imprese diversi tra loro quando almeno una
delle seguenti ipotesi sia soddisfatta:
• gli imprenditori hanno una diversa percezione riguardo al beneficio ge-
nerato dall’acquisto dell’informazione, pertanto le loro conoscenze si
distingueranno per contenuto e dimensione;
• a parità di spesa corrispondono insiemi di informazione distinti; in
questo caso gli imprenditori scelgono funzioni di produzione diverse
a seconda dell’informazione da loro posseduta.
Inoltre possono esistere elementi di incertezza legati anche alle risorse
3. IMPRESA, IMPRENDITORE E CONOSCENZA 50
interne all’azienda che, secondo l’impostazione neoclassica, possono essere
eliminati con l’acquisto di ulteriori informazioni.
Perciò si può concludere che l’imprenditore neoclassico è soggetto a due
forme di rischio, il rischio interno, che riguarda le variabili interne all’azien-
da, e il rischio esterno, che si riferisce alle variabili esogene.
L’idea di equilibrio della teoria neoclassica prevede il conseguimento di
profitti nulli sia nel caso di prodotti omogenei sia in presenza di prodotti
differenziati; in questo secondo caso l’azzeramento dei profitti è provocato
dall’entrata nel mercato di nuove imprese che, avendo notato la possibilità
di conseguire utili, cercano di cogliere le occasioni di profitto.
Ma non è sempre vero che i profitti dell’impresa neoclassica sono nulli,
perché se sono soddisfatte le ipotesi di incertezza sopra descritte è possibile
che esistano imprenditori migliori di altri che siano in grado di conseguire
profitti positivi anche in mercato concorrenziale. Tuttavia i profitti saranno
annullati con il passare del tempo, quando gli altri imprenditori imiteranno
le scelte del migliore, perciò nel medio-lungo termine soltanto delle variazioni
nelle variabili esogene possono causare differenziazioni tra le imprese.
Considerato in questo modo, il lungo periodo non è visto come un interval-
lo temporale esteso, ma come somma di più brevi periodi (Colombatto, 2001)
in cui possono avvenire dei cambiamenti che modificano l’assetto economico
generale.
3.2 La Scuola Austriaca
La Scuola Austriaca ha profondamente criticato la visione neoclassica dell’e-
conomia di mercato. Infatti, in contrasto con le assunzioni neoclassiche di
completa informazione e perfetto equilibrio, questa scuola di pensiero sostiene
che il sistema economico si trova perennemente in situazioni di disequilibrio,
3. IMPRESA, IMPRENDITORE E CONOSCENZA 51
dal momento che gli agenti operano in situazioni di incertezza e non cono-
scono tutti gli elementi dell’ambiente esterno che possono avere influenza su
di loro.
Il concetto di studio dell’economia secondo Mises, uno dei maggiori espo-
nenti della Scuola Austriaca, è il seguente:
lo studio dell’economia non consiste nell’esame delle condizioni di
ottimo; bensì nell’analisi delle possibilità, in condizioni di incer-
tezza, di allentare i vincoli tipici dell’attività economica − la scar-
sità delle risorse a disposizione dei produttori − e di accrescere la
soddisfazione dei consumatori, aumentando il loro potere d’acqui-
sto e offrendo loro l’opportunità di acquistare nuovi beni e servizi,
in grado di soddisfare meglio le loro esigenze. (Colombatto, 2001,
14-15)
Secondo questa impostazione l’importanza dell’economia di mercato sta
nella capacità di creare le condizioni per cui gli agenti, o imprenditori, si
impegnino a superare i vincoli imposti dalle funzioni di produzione tramite
le innovazioni o con la ricerca di nuove opportunità, in modo da raggiungere
nuovi mercati e diversi tipi di domanda.
Secondo gli Austriaci l’attività imprenditoriale coincide con l’azione uma-
na. Il significato etimologico della parola ‘‘imprenditore” illustrato nell’intro-
duzione a questo capitolo aiuta a comprendere che, secondo la Scuola Au-
striaca, la sua attività consiste nel percepire e scoprire nuove opportunità nel
mercato e comportarsi in modo da ottenere un profitto.
L’attività imprenditoriale è un processo di apprendimento continuo, gra-
zie alle scoperte degli agenti che generano nuove informazioni e nuove cono-
scenze; secondo la teoria Austriaca la conoscenza ha determinate caratteri-
stiche (Huerta De Soto, 2003):
• è di tipo pratico;
3. IMPRESA, IMPRENDITORE E CONOSCENZA 52
• è esclusiva e dispersa nella mente di tutti gli uomini;
• è tacita e non articolabile;
• è trasmissibile.
La conoscenza imprenditoriale è definita pratica perché non è rappre-
sentabile in modo formale, ad esempio con un modello matematico; la sua
principale caratteristica è che rappresenta tutte le informazioni che un agen-
te considera importanti ai fini di una situazione in cui si trova. È possibile
acquisire nuove conoscenze attraverso concrete azioni umane.
Inoltre le conoscenze sono considerate esclusive perché il modo in cui la
mente degli uomini assimila e interpreta le informazioni è strettamente per-
sonale e varia da una persona all’altra. Perciò gli agenti che svolgono la
funzione di imprenditore lo fanno in modo assolutamente personale ed irri-
petibile, perché le decisioni adottate dipendono dalla loro personale visione
del mondo e dall’insieme di informazioni che non possono essere replicate da
nessun altro.
La conoscenza ha anche la caratteristica di essere dispersa, perché non
rappresenta un complesso di informazioni prestabilite e offerte alla comunità
nello stesso modo, ma è ottenibile da diverse fonti, quali, ad esempio, le
statistiche, i media o i libri.
L’ultima peculiarità della conoscenza è il fatto di essere tacita, in quanto
l’agente sa come effettuare determinate azioni, ma non conosce tutte le parti
e le caratteristiche di ciò che sta facendo; per comprendere meglio questa
caratteristica si riporta un esempio di Polanyi descritto in Huerta De Soto
(2003, 38):
È anche possibile citare, rifacendosi a Polanyi, l’esempio di
quella persona che impara ad andare in bicicletta cercando di
3. IMPRESA, IMPRENDITORE E CONOSCENZA 53
mantenere l’equilibrio muovendo il manubrio verso il lato dal qua-
le sta per cadere, causando in tal modo una forza centrifuga che
tende a mantenerlo in equilibrio. Tutto ciò senza che nessun ci-
clista sia cosciente né conosca i principî fisici sui quali si basa la
sua abilità. Al contrario ciò che il ciclista utilizza è il suo ‘‘senso
di equilibrio” che gli indica, in qualche modo, come comportarsi
in ogni momento per non cadere.
È possibile comprendere il principio di conoscenza tacita prendendo come
esempio una sua manifestazione, l’intuizione, che è definita come ‘‘conoscenza
immediata delle cose ottenuta mediante una visione diretta di esse”; un’in-
tuizione è difficile da spiegare agli altri individui, ed è per questo che la
conoscenza imprenditoriale è anche non articolabile.
Altri esempi di conoscenza tacita sono rappresentati dalle abitudini, dalle
tradizioni e dalle norme giuridiche e morali, a cui gli individui si adeguano
senza essere in grado di spiegare il ruolo che queste norme hanno nei processi
sociali in cui intervengono.
3.2.1 L’attività imprenditoriale
L’attività imprenditoriale è creativa, perché non comporta nessun costo per
la sua esecuzione e origina dei benefici che nascono dal nulla, che sono detti
benefici imprenditoriali puri.
Ogni atto imprenditoriale comporta tre effetti: crea informazioni nuove
che precedentemente non esistevano, permette la trasmissione delle informa-
zioni sul mercato e, infine, fa sì che gli agenti imparino a comportarsi in
funzione delle necessità degli altri.
3. IMPRESA, IMPRENDITORE E CONOSCENZA 54
Creazione delle informazioni
Un’azione imprenditoriale consiste nella scoperta, da parte di un agente eco-
nomico, di un’occasione di profitto sul mercato; grazie a questa scoperta si ha
la creazione dal nulla di una nuova informazione, che consiste semplicemente
nella conoscenza dell’esistenza dell’opportunità in questione.
La creazione di conoscenza può coinvolgere anche più di un solo soggetto,
infatti se si considera un’operazione di arbitraggio, come illustrato in Huer-
ta De Soto (2003), gli agenti che apprendono nuove informazioni sono tre:
l’arbitraggista e i due soggetti da lui coinvolti. L’arbitraggista si rende conto
della possibilità di acquistare un bene ad un certo prezzo e rivenderlo o ad
uno superiore; il soggetto che vende impara che il suo bene ha un valore di
mercato maggiore di quello che gli era stato dato erroneamente; infine il sog-
getto che compra apprende che sul mercato esiste il bene di cui aveva bisogno
e grazie ad esso può intraprendere nuove iniziative.
La trasmissione delle informazioni
La creazione di informazioni comporta la sua immediata trasmissione nel
mercato.
Occorre ricordare che le informazioni, poiché sono percepite e trasmesse
dagli individui, non possono essere divise dallo scopritore e circolare indipen-
dentemente. Si può perciò concludere che la trasmissione delle informazioni
nella società è tacita e soggettiva, cioè esse sono perfettamente comprensibili
a chi le diffonde, ma potrebbero non esserlo per tutti gli altri agenti presenti
sul mercato.
Il coordinamento
Grazie alle nuove informazioni gli agenti imparano ad agire in modo coordi-
nato, modificando le loro attività in funzione dei bisogni degli altri; inoltre
3. IMPRESA, IMPRENDITORE E CONOSCENZA 55
apprendono senza rendersi conto e in un contesto in cui ognuno cerca di
conseguire i propri obiettivi.
Si può concludere che l’attività imprenditoriale è la funzione sociale per
eccellenza, perché rende possibile la vita degli agenti nella società adattando
e coordinando continuamente il loro comportamento.
Il processo di coordinamento sociale originato dall’attività imprendito-
riale non si ferma mai, perché le informazioni che sono create modificano la
percezione degli obiettivi e dei mezzi degli altri imprenditori e creano nuove
opportunità ripristinando perciò il ciclo.
3.2.2 La competizione
L’attività imprenditoriale è per definizione competitiva, in quanto gli agenti
cercano continuamente nuove opportunità di profitto nei mercati per affer-
marsi nella società.
La competizione è pertanto intesa come un processo dinamico di rivalità,
in cui tutti gli imprenditori cercano di prevalere sugli altri, e non come il
modello di concorrenza perfetta in cui tutti vendono allo stesso prezzo.
3.3 L’imprenditore di Kirzner
Israel M. Kirzner, allievo di Mises, sviluppò notevolmente l’idea della funzio-
ne imprenditoriale della Scuola Austriaca.
Secondo Kirzner l’imprenditore è colui che è in grado di trovare occasioni
di profitto nei mercati e di trasformarle in fonte di reddito per se stesso e per
la comunità.
L’imprenditore kirzneriano cerca nel mercato imperfezioni che si possano
tradurre in attività fruttifere, ma la sua attività non si manifesta in un’assi-
dua indagine degli errori compiuti dai rivali o delle occasioni da loro manca-
3. IMPRESA, IMPRENDITORE E CONOSCENZA 56
te, bensì in una costante attenzione dell’ambiente che lo circonda; infatti in
Kirzner (1997) si precisa che l’attività imprenditoriale consiste nel guardare
all’orizzonte senza sapere cosa si stia cercando e senza attuare una particolare
tecnica di ricerca, in attesa di sfruttare le scoperte che si presenteranno.
Nella visione kirzneriana e austriaca l’imprenditore esiste nel solo caso in
cui all’interno del mercato vi siano situazioni di disequilibrio o imperfezioni
di varia natura, grazie alle quali è possibile la presenza di occasioni di pro-
fitto, che sono viste come un segnale di vitalità imprenditoriale, di crescita
e miglioramento per il benessere collettivo. Pertanto quanto più è intenso lo
squilibrio nei mercati, tanto maggiori sono le opportunità di profitto per gli
agenti economici.
Il profitto è considerato in una nuova prospettiva, non è più il compen-
so per le capacità organizzative, perché questi incarichi non competono al-
l’imprenditore, ma all’amministratore. Il profitto remunera la capacità del-
l’imprenditore di cogliere le opportunità di miglioramento prima ancora che
queste siano realizzate all’interno dell’azienda; anche se il guadagno si con-
cretizza nel momento in cui si realizza l’attività nell’impresa, questo valore è
riferito all’atto precedente dell’imprenditore, alla ‘‘scoperta imprenditoriale”.
La teoria kirzneriana porta anche spunti di originalità alla figura dell’im-
prenditore delineata dagli Austriaci. Infatti questi ultimi sostengono che un
agente può decidere di dedicare del tempo all’attività imprenditoriale, al con-
trario Kirzner sottolinea che l’individuazione di occasioni profittevoli avviene
per caso, senza un’azione di ricerca alle spalle; se così non fosse, profitto sa-
rebbe non solo la remunerazione della la scoperta, ma anche del tempo e delle
risorse impiegati nella ricerca.
Da queste osservazioni si può affermare che, secondo Kirzner, chiunque
può essere un imprenditore, in quanto l’unica qualità richiesta è l’alertness,
ossia vivacità, prontezza mentale, senza la necessità di mezzi di produzione.
3. IMPRESA, IMPRENDITORE E CONOSCENZA 57
Questa tesi tuttavia può creare alcune perplessità per due principali mo-
tivi (Colombatto, 2001). Da un lato, la conoscenza delle caratteristiche del
settore e dei potenziali consumatori può sicuramente costituire un vantaggio
per alcuni imprenditori a sfavore di altri. Dall’altro, se l’imprenditore non ha
una struttura produttiva alla quale appoggiarsi difficilmente vedrà realizzate
le occasioni scoperte nel mercato e pertanto non otterrà nessun profitto.
Pertanto è possibile rivedere la visione di Kirzner sostenendo che, a parità
di alertness, non tutti hanno le stesse possibilità di essere imprenditori di
successo.
3.4 Simon e la razionalità limitata
Herbert A. Simon propone, con le sue teorie, un modo nuovo per analizzare
le scelte fatte nelle organizzazioni capovolgendo le assunzioni neoclassiche
secondo le quali il decisore sceglie sempre la migliore delle possibilità. Lo
studio delle decisioni nelle organizzazioni può essere applicato anche allo
studio delle scelte all’interno delle imprese che, secondo Simon (1985), sono
organizzazioni formali.
La figura dell’imprenditore è studiata introducendo la teoria della razio-
nalità limitata, secondo la quale in certe situazioni non è possibile avere una
conoscenza completa e pertanto le decisioni prese non sono le migliori, ma le
più soddisfacenti in base alle informazioni possedute.
L’idea della bounded rationality nasce dalla consapevolezza che il modello
classico dell’agire razionale non è più in grado di descrivere il comportamento
degli imprenditori, in quanto secondo Simon le decisioni sono prese in un
ambiente in cui è difficile valutare tutte le opzioni e le loro conseguenze
(Egidi, 2003).
Per illustrare il modo in cui i manager prendono le decisioni Simon fece
una serie di studi sui giocatori di scacchi, le cui mosse possono essere compa-
3. IMPRESA, IMPRENDITORE E CONOSCENZA 58
rate con le scelte imprenditoriali ma con il vantaggio di essere in un contesto
maggiormente dominabile rispetto a quello dell’impresa. Il giocatore di scac-
chi deve cercare in modo razionale la soluzione migliore e per fare ciò deve
avere essere in grado di prevedere le conseguenze che ogni spostamento della
pedina potrebbe generare. Tuttavia si pone il seguente problema:
In media, ad ogni data posizione in una partita di scacchi,
corrispondono circa trenta mosse possibili − in cifra tonda, con-
siderando una mossa e le sue risposte, una media di circa 103
continuazioni della posizione data. Quaranta mosse non sono una
stima irragionevole della lunghezza media di una partita. Quindi
ci sarebbero circa 10120 possibilità di svolgimento di una partita di
scacchi. Ovviamente il numero esatto non ha importanza: un nu-
mero come 1040 sarebbe meno spettacolare, ma sufficientemente
grande per avallare le nostre conclusioni.
Studi sui processi decisionali degli scacchisti indicano atten-
dibilmente che anche i giocatori forti guardano raramente ad un
centinaio di possibilità − cioè un centinaio di proseguimenti dal-
la posizione data − nella scelta di una mossa o di una strategia.
Cento è un numero ragionevolmente grande, rispetto ad altri pa-
rametri, ma è un po’ più piccolo di 10120! Gli scacchisti non pren-
dono in considerazione tutte le strategie possibili scegliendo poi
la migliore, ma ne ipotizzano ed esaminano un numero piuttosto
piccolo, facendo una scelta appena ne trovano una che ritengono
soddisfacente. (Simon, 1985, 263-264)
Da queste righe si comprende come sia difficile per un giocatore di scac-
chi raggiungere la razionalità nelle decisioni, a causa del grande numero che
sarebbero necessarie. Simon conclude perciò che a maggior ragione la razio-
nalità non è raggiungibile neanche nel mondo reale, perché in questo contesto
3. IMPRESA, IMPRENDITORE E CONOSCENZA 59
le variabili da conoscere sono di gran lunga più numerose rispetto a quelle
necessarie per una partita di scacchi.
Le ragioni per cui non è raggiungibile la completa razionalità nella realtà
sono l’incertezza sulle conseguenze che deriveranno dalle decisioni, il grande
numero di possibilità di scelta, le loro informazioni incomplete e la comples-
sità dei calcoli necessari per valutare le diverse opzioni.
Un ulteriore ostacolo è rappresentato dalla difficoltà di previsione, perché
per gli individui può essere difficile descrivere completamente le conseguenze,
dal momento che la mente umana difficilmente è in grado di prevedere tutto
ciò che deriverà da una particolare scelta; questa motivazione emerge anche
dalla lettura dell’analisi di Simon sul gioco degli scacchi.
Per risolvere il problema dell’incompletezza della conoscenza si potrebbe
cercare di capire quali siano le variabili ed i fattori che hanno la maggiore im-
portanza in relazione ad una determinata situazione (Simon, 1958). La scelta
si baserebbe perciò su quell’insieme di fattori e poterebbe essere considerata
razionale nel solo caso in cui non emergessero altri effetti non considerati
legati a quella decisione.
3.4.1 La razionalità procedurale
Simon introduce il concetto di razionalità procedurale nell’ambito dello studio
delle decisioni. Secondo questo principio non si prende più in esame la scelta
finale dell’individuo, ma il processo mentale che conduce ad essa. Un deciso-
re è pertanto definito razionale se il suo comportamento è razionale in senso
procedurale. Il principio della razionalità procedurale è necessaria nel mo-
mento in cui si introduce nel modello di scelta l’incertezza, l’apprendimento
e la complessità.
Il processo di scelta segue delle regole che possono essere rappresentate
3. IMPRESA, IMPRENDITORE E CONOSCENZA 60
da semplici regole empiriche, o thumb rules, da routines complesse all’interno
dell’organizzazione, o da algoritmi computazionali.
Razionalità limitata e razionalità procedurale sono due aspetti dello stes-
so concetto (Avvisati, 2003), perché se si accetta l’idea che la razionalità
umana ha dei limiti è necessario introdurre un modello di comportamento
rule-follower, secondo il quale non è importante la scelta finale ma l’iter che
conduce ad essa.
3.4.2 Il processo di scelta
Nei casi in cui non è possibile raggiungere la completa razionalità per ef-
fettuare le scelte, il processo di formazione delle decisioni è caratterizzato
da quello che nella teoria dell’organizzazione è definito subgoal identification
(Simon, 1985). Secondo questo principio gli essere umani valutano le deci-
sioni in base ad obiettivi subordinati, la cui formulazione è funzione delle
conoscenze, dell’esperienza e dell’ambiente organizzativo di chi decide.
I punti chiave del processo di scelta sono search e satisficing. La teoria
della ricerca prevede che se il decisore non dispone delle alternative per la
scelta deve cercarle. Durante la ricerca la massimizzazione dell’utilità può
non essere l’obiettivo guida, in quanto il soggetto può decidere un livello di
bontà che deve essere raggiunto dalle possibilità prese in esame; questo modo
di agire è definito statisficing, secondo cui l’individuo si indirizza sulla scelta
che raggiunge il livello di utilità prestabilito.
Con questo metodo è pertanto possibile effettuare delle scelte anche nel
caso in cui non si disponga di informazioni complete.
Questa teoria sovverte il modello classico secondo il quale per effettuare
una decisione è necessaria la completa conoscenza delle alternative e delle
loro conseguenze, modello più rigoroso ma che, come dimostrato da Simon,
non trova riscontro nella realtà.
Capitolo 4
jES: java Enterprise Simulator
Il modello java Enterprise Simulator (jES ) è una struttura interamente
basata sulla versione Java di Swarm, con la quale è possibile sviluppare mo-
delli di simulazione di impresa per studiare l’attività di un’azienda reale o
per studiare la nascita e l’evoluzione di imprese ‘‘virtuali”, in una prospettiva
esclusivamente teorica.
Con la piattaforma jES è possibile effettuare lo studio del modo in cui
le scelte complesse sono trattate all’interno delle organizzazioni, in quanto
con esso si possono ricostruire le imprese reali all’interno del computer e
osservare il loro funzionamento durante tutte le fasi produttive. È inoltre
possibile effettuare il confronto tra più modalità organizzative per trovare
quale potrebbe essere la miglior struttura dell’impresa.
La simulazione ad agenti offre un importante strumento di studio della
realtà, tuttavia occorre ricordare che potrebbe essere ‘‘pericoloso” utilizzarla
come base unica su cui poggiare per le scelte aziendali, in quanto i risulta-
ti forniscono risposte adatte per il mondo creato all’interno del computer,
che potrebbe essere, e spesso è, diverso da quello reale, nel quale possono
verificarsi eventi diversi da quelli ipotizzati nella simulazione.
61
4. JES: JAVA ENTERPRISE SIMULATOR 62
4.1 Introduzione all’uso del simulatore
Per comprendere le funzionalità di jES è necessario illustrare il significato
di unità produttiva, ordine e ricetta. L’unità produttiva rappresenta una
struttura, che può essere interna o esterna all’azienda, in grado di eseguire
uno o più passi produttivi. Un ordine è un oggetto che rappresenta un bene
da produrre o un’attività da svolgere; le sue caratteristiche sono descritte
da una ricetta. La ricetta è una sequenza di passi produttivi che devono
essere portati a termine per la produzione di un bene o di un servizio; i passi
produttivi sono espressi da una sequenza di numeri.
Per la rappresentazione della realtà il formalismo jES consente tre diffe-
renti descrizioni del mondo:
• la prima, detta WD side (What to Do), è rappresentata dall’elenco
delle attività da svolgere, descritte da ricette che indicano i passi che
le unità produttive devono compiere;
• nella seconda, definita DW side (which is Doing What), si delinea la
struttura produttiva, elencando le unità che possono svolgere i passi
indicati nelle ricette;
• nell’ultima, denominata WDW side (When Doing What), si definisce
la sequenza degli eventi nel tempo.
L’assegnazione delle lavorazioni alle unità durante una simulazione av-
viene nel seguente modo: le unità che hanno eseguito un passo produttivo
chiedono alle altre unità e a se stesse per sapere quale sia l’unità in gra-
do di eseguire il passo successivo della ricetta, e inviano l’ordine alla prima
unità che risponde. Questo meccanismo si ripete sino ad aver ultimato la
produzione e varia da caso a caso a seconda delle code nelle liste d’attesa
delle unità, dei parametri del modello e di tutte le interazioni che nascono
4. JES: JAVA ENTERPRISE SIMULATOR 63
Figura 4.1: Interazioni tra ordini e unità
tra ordini, ricette e unità. Per valutare come agisce l’impresa virtuale in di-
verse situazioni è possibile effettuare delle modifiche al modello, ad esempio
ipotizzando una riduzione delle unità produttive o un aumento degli ordini
da eseguire, o ancora introducendo nuovi criteri di scelta per valutare quale
potrebbe essere il migliore.
Dai risultati delle interazioni tra ordini e unità che emergono nelle si-
tuazioni simulate è possibile studiare i problemi interni alle organizzazioni e
analizzare gli eventuali fenomeni complessi che si creano (Figura 4.1).
4.2 Lo schema ERA
Durante la simulazione gli agenti devono effettuare delle scelte di vario ti-
po e il meccanismo su cui si basa la decisione è fondato sul formalismo
Environment-Rules-Agents (ERA) illustrato in Gilbert e Terna (2000).
Secondo questo schema, mostrato in Figura 4.2, gli agenti non sono in gra-
do di comunicare direttamente tra loro, ma soltanto attraverso l’ambiente;
4. JES: JAVA ENTERPRISE SIMULATOR 64
questo non è obbligatorio, è soltanto un artificio volto a rendere il codice
meno complesso di quello che risulterebbe se gli agenti potessero comunicare
direttamente tra loro.
Figura 4.2: Lo schema ERA
Il comportamento degli agenti del modello è determinato da un oggetto
esterno, un gestore di regole, detto Rule Master. Quest’ultimo può essere
rappresentato da un insieme di regole, da una rete neurale o da un algorit-
mo genetico; si potrebbe anche scegliere di far operare come Rule Master un
agente umano e ciò permetterebbe di studiare in che modo le persone prendo-
no le decisioni nelle organizzazioni e quali sono le scelte in diverse situazioni
aziendali.
L’oggetto Rule Master è a sua volta collegato all’oggetto Rule Maker, che
ha il compito di creare e modificare le regole su cui si basa il comportamento
degli agenti.
La rigidità della struttura dello schema ERA conduce ad una maggior
4. JES: JAVA ENTERPRISE SIMULATOR 65
chiarezza del codice, che può essere visto come un vantaggio per l’utilizza-
tore finale. Un secondo vantaggio è la possibilità di agire separatamente sui
generatori e sui gestori di regole potendo passare a diversi sistemi di gestori
di regole, per esempio ad algoritmi genetici o a reti neurali.
4.3 Applicazioni a casi aziendali
Sono state e sono tuttora eseguite alcune applicazioni di simulazione di im-
presa su casi reali. I files utilizzati per la rappresentazione e le simulazioni si
trovano nella cartella appCases/.
Il primo caso (appCases/Case_i) riguarda un’azienda del settore mecca-
nico, la VIR S.p.A., che produce su larga scala prodotti per lo più simili ma
molto segmentati per quanto riguarda le dimensioni e alcune caratteristiche.
In questa applicazione il problema principale concerne l’assegnazione delle
priorità alle lavorazioni tenendo conto della disponibilità dei macchinari; la
simulazione ad agenti è stata utile per trovare quali sono i cosiddetti ‘‘colli
di bottiglia” legati alla produzione.
Il secondo caso (appCases/Case_ii) è riferito ad un’azienda che opera
nel settore della moda, la BasicNet S.p.A., che gestisce la propria attività
esclusivamente tramite il web. Lo studio di questo caso è approfondito nei
capitoli che seguono.
Nel terzo caso (appCases/Case_iii) è analizzata la struttura aziendale
del 118 di Grugliasco, che si occupa del trasporto medico di urgenza.
È in corso lo studio di una nuova versione di jES, chiamato jESopen-
foundation, con il quale è possibile, all’interno di un’applicazione chiamata
jESevol, simulare e analizzare la nascita e l’evoluzione delle imprese. Si crea
pertanto un ‘‘sistema evolutivo” in cui da una parte ci sono le cose da fare
e dall’altra chi è in grado di eseguirle; con questo modello è possibile osser-
4. JES: JAVA ENTERPRISE SIMULATOR 66
vare in che modo le nuove imprese sopravvivono o scompaiono e come e se
interagiscono tra loro, creando, ad esempio, dei distretti di imprese.
4.4 Il primo formalismo: le cose da fare
4.4.1 Le ricette
Gli ordini che l’impresa virtuale deve eseguire sono descritti nelle ricette
produttive. Una ricetta è composta da una sequenza di passi seguiti dall’in-
dicazione del tempo necessario per l’esecuzione; nella Tabella 4.1 è mostrato
un semplice esempio di ricetta produttiva composta da un solo passo nella
quale n1 indica il passo produttivo da eseguire, ts l’unità di misura tempo-
rale, che può essere il secondo (second), l’ora (hour) o il giorno (day), e m1
rappresenta la quantità di tempo necessaria per l’esecuzione dell’ordine.
n1 ts m1
Tabella 4.1: Esempio di ricetta produttiva
4.4.2 I layer
I layer possono essere definiti come delle ‘‘etichette” che contraddistinguono
prodotti simili tra loro ma che sono trattati in modo indipendente tra loro
dal simulatore; l’utilizzo dei layer all’interno del simulatore introduce la pos-
sibilità di differenziare due ordini associati ad una stessa ricetta produttiva
ma con caratteristiche qualitative diverse.
Ad esempio, se si considera un’impresa che opera nel settore della moda,
le T-shirt possono essere considerate un prodotto omogeneo se si guarda il
processo di creazione, ma sono diverse se si va a vedere dal punto di vista delle
collezioni; in questo caso due magliette appartenenti a collezioni diverse sono
4. JES: JAVA ENTERPRISE SIMULATOR 67
considerate prodotti distinti tra loro. I layer sono utili per operare questa
distinzione nell’impresa simulata e il loro utilizzo è automatico all’interno di
jES.
Il numero di layer utilizzati è indicato dal parametro della simulazione
totalLayerNumber. Il numero di layer è pari a (totalLayerNumber − 1); se
il parametro è impostato su 1 significa che non si usano layer durante la
simulazione.
L’assegnazione degli ordini ai layer è effettuata dall’utente nel momento
in cui crea il file recipeData/orderSequence.xls1, che contiene il calendario
delle cose che devono essere fatte dall’impresa.
4.4.3 I batch
In alcune situazioni aziendali non è realistico considerare la produzione come
una serie di processi indipendenti tra loro, pertanto è più corretto ragionare
in termini di gruppi di prodotti uguali tra loro.
Sequential batch
Un processo sequential batch esegue contemporaneamente un insieme di or-
dini uguali; può essere impiegato per lavorazioni che richiedono un tempo
molto ridotto per essere portate a termine, perciò è più realistico considerare
che la loro produzione avvenga solo quando c’è un certo numero di ordini in
attesa.
Nella Tabella 4.2 è mostrato un esempio di sequential batch: l’unità che
deve svolgere il passo n1 deve attendere che b1 ordini simili siano arrivati
nella sua waiting list prima di iniziare la lavorazione; il tempo necessario
per la realizzazione del passo è pari a m1, mentre il tempo di produzione di
ciascun ordine è uguale a m1
b1.
1Per maggiori chiarimenti su questo file vedere il paragrafo 4.6
4. JES: JAVA ENTERPRISE SIMULATOR 68
n1 ts m1 \ b1
Tabella 4.2: Sequential batch
Stand alone batch
Un processo stand alone batch produce contemporaneamente un insieme di
ordini ed è utilizzato, ad esempio, nel caso di un approvvigionamento esterno
di semilavorati.
La ricetta (Tabella 4.3) contenente il processo deve essere composta di
due parti: lo stand alone batch e l’indicazione della endUnit 2; con endU-
nit si intende un magazzino nel quale vengono riposti i semilavorati quan-
do non vengono utilizzati. Nell’esempio che segue, il passo n1 produce b1
semilavorati nel tempo m1 e li colloca nell’endUnit c1.
n1 ts m1 / b1 e c1
Tabella 4.3: Stand alone batch e indicazione dell’endUnit
4.4.4 I procurement
Il procurement è un passo che procura semilavorati, prodotti internamente
o esternamente all’azienda. Nel caso di semilavorati provenienti da fornitori
esterni, i procurement sono considerati come ‘‘black boxes’’, senza indagare
sul modo in cui vengono prodotti. Se, al contrario, sono prodotti all’interno
dell’azienda, la loro realizzazione può essere descritta in un modo più o meno
dettagliato con una ricetta composta di un solo passo o con uno stand alone
batch.
La sintassi dei procurement è la seguente:
il passo m1 prima della sua realizzazione richiede una fase di approvvi-
gionamento nella quale vengono cercati semilavorati in k endUnit che han-
2Per maggiori dettagli: paragrafo 4.5.2
4. JES: JAVA ENTERPRISE SIMULATOR 69
p k c1 ... ck n1 ts m1
Tabella 4.4: Procurement
no codice c1 ... ck; nella sintassi del procurement l’indicazione della p è
obbligatoria.
4.4.5 Il processo OR
Grazie al processo or è possibile creare delle situazioni in cui l’azienda si-
mulata si trovi a dover effettuare delle scelte su come operare. Ad esempio,
potrebbe essere possibile che per l’approvvigionamento di uno stesso semila-
vorato l’impresa decida una volta di produrlo internamente e la volta succes-
siva decida invece di rivolgersi ad un fornitore esterno, oppure può avvenire
che per la produzione di uno stesso prodotto si possano usare due diversi
metodi di lavorazione, pertanto l’azienda sceglierà di volta in volta quale
utilizzare.
Per inserire una scelta tra due o più opportunità all’interno delle ricette
si usa, come nel formalismo del linguaggio C, il simbolo || seguito dalle alter-
native, come nella Tabella 4.5, tenendo presente che l’ultima ramificazione
deve iniziare con la notazione ||0. Nel caso mostrato l’impresa, dopo aver
eseguito il passo n1, può scegliere se eseguire il passo n2 o il passo n12 o n81.
n1 ts m1 ||1 n2 ts m2 ||2 n12 ts m12 ||0 n81 ts m81
Tabella 4.5: Processo or
Le possibilità di scelta tra le diverse ramificazioni dipende dal valore
assunto dal parametro orCriterion, che può variare tra 0 e 5:
• 0 significa che si eseguono tutte le alternative (utile solo nelle fasi di
test del simulatore);
4. JES: JAVA ENTERPRISE SIMULATOR 70
• 1 per scegliere sempre il primo ramo;
• 2 per scegliere sempre il secondo ramo;
• 3 per una scelta effettuata in modo casuale;
• 4 nel caso in cui si scelga l’alternativa il cui primo passo ha la minor
lista d’attesa;
• 5 se la scelta del branch è basata sul risultato di un passo computazio-
nale3
4.5 Il secondo formalismo: chi fa cosa
4.5.1 Le unità produttive
L’unità produttiva è una struttura aziendale in grado di eseguire uno o più
passi di una ricetta. Le unità sono semplici se sono in grado di eseguire solo
un passo, complesse se ne possono eseguire più di uno.
Unità semplici
Le unità produttive semplici sono elencate nel file unitData/unitBasicDa-
ta.txt, che si presenta come mostrato in Figura 4.3, nel quale sono indicate,
per ciascuna unità, le seguenti informazioni:
• il numero dell’unità produttiva presa in considerazione;
• il parametro useWarehouse. Se è impostato su 1, l’unità produce magaz-
zino in modalità stand alone, cioè nel momento in cui non è chiamata
ad operare da una ricetta; se ha valore 0 non produce magazzini;
• il numero del passo produttivo che è in grado di eseguire;
3Per maggiori dettagli: paragrafo 4.7.2
4. JES: JAVA ENTERPRISE SIMULATOR 71
• il valore dei costi fissi per ogni unità di tempo;
• il valore dei costi variabili per ogni unità di tempo.
Figura 4.3: File unitData/unitBasicData.txt
Unità complesse
Le unità complesse sono in grado di eseguire più di un passo produttivo;
nel file unitData/unitBasicData.txt sono indicate con uno 0 nella colonna
corrispondente al passo che svolgono; esempi di unità complesse sono l’unità
2 e 4 nella Figura 4.3).
Queste unità sono descritte in un foglio Excel, nel quale sono indicati il
numero di fasi che possono svolgere, il codice della fase, i loro corrispondenti
costi fissi e variabili, e l’indicazione se producono magazzini in caso di assenza
di attività.
4.5.2 Le endUnit
Le endUnit rappresentano dei magazzini in cui sono riposti i semilavorati o
i prodotti finiti e hanno lo stesso codice della componente che contengono;
sono elencate nel file unitData/endUnitList.txt. Nelle ricette le endUnit sono
indicate con una e che precede il loro codice identificativo.
Le endUnit possono essere layer sensitive, se indicate con un numero
positivo, o layer insensitive, se indicate con numero negativo; nel primo caso
4. JES: JAVA ENTERPRISE SIMULATOR 72
si creano tante endUnit quanti sono i layer e i prodotti saranno immagazzinati
nella endUnit avente il suo stesso layer.
4.5.3 La scelta delle unità
Nel caso che più unità siano in grado di eseguire lo stesso passo il simulatore
deve scegliere quale di queste dovrà effettuare la lavorazione. Il metodo di
scelta è indicato dal parametro unitCriterion e può essere:
0, se si sceglie la prima unità disponibile seguendo l’ordine del file unitDa-
ta/unitBasicData.txt ;
1, se la scelta è effettuata in modo casuale;
2, se è scelta l’unità con la minore lista d’attesa.
4.5.4 La trasmissione delle informazioni
Un’unità può inviare informazioni riguardanti un ordine all’unità successiva
secondo l’ordine della ricetta; lo scambio di informazioni è possibile se il pa-
rametro useNewses è impostato su true. Questo aspetto è molto interessante
nel corso di una simulazione, in quanto è possibile osservare quali interazioni
si creano tra le unità in diverse situazioni aziendali e che tipo di fenomeni
complessi possono emergere.
Un’unità può inviare informazioni ad un’altra nel solo caso in cui siano
legate nella matrice presente nel file unitData/informationFlowMatrix.txt ; le
righe indicano le unità che inviano le informazioni e le colonne da quelle che
le ricevono. Se due unità sono legate dal valore 1 si scambiano informazioni,
in caso contrario sono contrassegnate con 0; i valori sulla diagonale principale
della matrice non sono da tenere in considerazione, in quanto le unità non
scambiano informazioni con loro stesse.
4. JES: JAVA ENTERPRISE SIMULATOR 73
4.6 Il terzo formalismo: quando fare cosa
Il terzo formalismo è alla base della sequenza degli eventi: descrive degli
ordini da eseguire, contenenti le ricette, e la sequenza in cui questi ordini
devono essere eseguiti.
L’elenco delle ricette è contenuto nel file recipeData/recipes.xls, in cui,
per ogni ricetta è indicato nel seguente ordine:
• il nome della ricetta;
• il numero identificativo;
• il ‘‘corpo’’ della ricetta;
• un punto e virgola che indica la fine della ricetta.
Tutti gli elementi della ricetta devono essere scritti uno per ogni cella del
foglio di lavoro.
La sequenza con cui devono essere eseguiti gli ordini è contenuta nel file
recipeData/orderSequence.xls. Ciascun blocco del file descrive gli eventi che
si verificano in un tick della simulazione e si conclude con un punto e virgola
che indica che sono finite le attività da compiere in quel tick. Ogni blocco è
composto dai seguenti elementi:
• numero del tick;
• la lettera l, che sta per layer, seguita dal numero di layer corrispondente;
• numero della ricetta che deve essere lanciata;
• il segno ‘‘*’’;
• il numero di volte che deve essere eseguita la ricetta.
4. JES: JAVA ENTERPRISE SIMULATOR 74
Se ad un tick non accade nulla, nel calendario della simulazione si indica
il numero del tick seguito da un punto e virgola. La sintassi del file recipe-
Data/orderSequence.xls è mostrata in Tabella 4.6; al tick 1 non accade nulla,
mentre al secondo deve essere lanciata la ricetta 101 con layer 5 per 25 volte.
1 ;
2 l 5 101 * 25 ;
Tabella 4.6: recipeData/orderSequence.xls
4.7 Le capacità computazionali
jES ha delle capacità computazionali che possono essere associate ai passi
delle ricette; il loro scopo è l’esecuzione di operazioni immateriali, ad esempio
previsioni, aste per selezionare gli approvvigionamenti e valutazioni di diverso
tipo.
I passi computazionali utilizzano i dati contenuti all’interno delle matrici
di memoria, che sono elencate nel file unitData/memoryMatrixes.txt mostrato
in Figura 4.4, e possono essere sensibili o no ai layer; se sono layer insensitive
sono indicate con un numero negativo, in modo analogo a quanto accade per
le endUnit. Nel file unitData/memoryMatrixes.txt sono indicati il numero
delle memoryMatrix ed i numeri di righe e di colonne di ciascuna. Occorre
ricordare che per usare le memoryMatrix si deve aggiornare il parametro della
simulazione totalMemoryMatrixNumber, che indica il numero delle matrici di
memoria usate durante la simulazione.
Per indicare che il passo di una ricetta richiede l’utilizzo di una compu-
tazione occorre usare il formalismo mostrato in Tabella 4.7, nel quale c è
obbligatorio e indica che si deve utilizzare un passo computazionale, code
rappresenta il codice del passo usato (che per convenzione può andare da
1001 a 1999), n esprime il numero di matrici di memoria che si intendono
4. JES: JAVA ENTERPRISE SIMULATOR 75
Figura 4.4: File unitData/memoryMatrixes.txt
usare e a1 ... an i loro numeri, che si possono trovare nel file unitData/me-
moryMatrixes.txt. Pertanto il passo in Tabella 4.7 si può leggere nel seguente
modo: il passo n1 necessita di una computazione del metodo code che usa n
matrici numerate a1 ... an.
c code n a1 ... an n1 ts m1
Tabella 4.7: Uso di passi computazionali
Per inserire nuove capacità computazionali al simulatore è necessario mo-
dificare il file ComputationalAssembler.java, che eredita i suoi metodi di base
dalla classe ComputationalAssemblerBasic; entrambi i files si trovano nella
cartella src/ ed il ComputationalAssembler.java non contiene alcun metodo.
Nel momento in cui si aggiungono nuovi metodi alla classe Computationa-
lAssembler occorre spostare il file nella cartella principale, in modo che sia
visibile al comando make durante la compilazione.
I metodi seguenti sono quelli che i passi computazionali ereditano dalla
classe ComputationalAssemblerBasic e che consentono loro di interagire con
le matrici di memoria:
• getEmpty(layer, (int) row, (int) col), restituisce vero o falso a seconda che
la casella della memoryMatrix considerata sia, rispettivamente, vuota
o piena;
• setEmpty(layer, (int) row, (int) col), cancella il contenuto della casella
della matrice;
4. JES: JAVA ENTERPRISE SIMULATOR 76
• getValue(layer, (int) row, (int) col), legge il valore contenuto nella riga e
colonna indicate della memoryMatrix;
• setValue(layer, (int) row, (int) col, (double) value) o setValue(layer, (int)
row, (int) col, (float) value), scrive un valore all’interno della casella
della matrice presa in considerazione.
4.7.1 Un semplice esempio
Si ipotizzi che durante la simulazione si presenti la seguente ricetta, composta
di un solo passo:
c 1998 1 25 7 s 4 ;
ciò significa che il passo 7 impiega 4 secondi per la sua esecuzione e ha
bisogno del passo computazionale 1998 che usa una matrice, la numero 25.
Il passo computazionale c1998, nel momento in cui viene chiamato ad
operare, legge il numero della matrice di memoria nella posizione 0, cioè la
prima posizione, con il metodo getMemoryMatrixAddress, e assegna l’indirizzo
della matrice alla variabile mm di tipo MemoryMatrix; in seguito controlla il
layer della matrice con il metodo getOrderLayer.
Il compito di questo passo computazionale è scrivere 1 nella riga 0 e
colonna 0 della matrice mm ed a tal fine utilizza il metodo setValue.
Infine, il passo computazionale è impostato su done. Questa operazione
è molto importante, perché in caso contrario l’ordine rimane in sospeso e il
passo successivo della ricetta non può essere eseguito; il passo computaziona-
le sarà ripetuto in ogni ciclo di simulazione, fino a quando la variabile done
sarà impostata true.
4. JES: JAVA ENTERPRISE SIMULATOR 77
Listing 4.1: Esempio di passo computazionale¨
pub l i c void c1998 ( )
{
mm = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet .
getOrderLayer ( ) ;
mm. setValue ( layer , 0 , 0 , 1 . 0 ) ;
done = true ;
}//end c1998§ ¦
4.7.2 La matrice orMemoryMatrix
Come accennato nel paragrafo 4.4.5, se il parametro orCriterion è uguale a 5
la scelta del ramo del processo or è effettuata grazie alle capacità computa-
zionali del simulatore. Infatti in questo caso il ramo da scegliere è cercato
nella prima colonna di una matrice di memoria, che è individuata mediante
il parametro orMemoryMatrix.
Il contenuto della orMatrix può essere modificato dai passi computazionali
ed è uno strumento utile per aumentare la casualità all’interno dell’impresa
simulata.
4.7.3 Le ricette che lanciano ricette
Un ulteriore utilizzo delle capacità computazionali del simulatore è legato alla
presenza di ‘‘ricette che lanciano altre ricette’’. Questa potenzialità discende
dal fatto che durante la simulazione può accadere che, durante l’esecuzione di
una ricetta, contemporaneamente debba essere effettuata una lavorazione che
4. JES: JAVA ENTERPRISE SIMULATOR 78
richiede l’intervento di un’altra ricetta, oppure che una ricetta debba valutare
se eseguire o no una lavorazione e, in caso affermativo, avvii l’operazione
lanciando un’altra ricetta produttiva.
Questa funzione speciale è assolta da due passi computazionali presenti
nella classe ComputationalAssemblerBasic, il C1001 e il C1002. Per co-
noscere quali sono le ricette che devono essere lanciate si utilizza un file
di testo, recipeData/recipesFromRecipes.txt, nel quale l’utente scrive il loro
numero, ciascuno separato da uno spazio vuoto; in seguito il passo computa-
zionale C1001 legge il contenuto di questo file ed inserisce ogni numero in una
memoryMatrix nella posizione (0, 0). Il lancio delle ricette è effettuato dal
passo computazionale C1002, che legge nella memoryMatrix il numero della
ricetta e lo invia al metodo distill della classe OrderDistiller, che si occupa di
avviare l’esecuzione della ricetta.
Ci sono due restrizioni nell’uso di questa funzionalità:
• non possono essere lanciate più di 10 ricette, anche se è possibile
modificare questo limite nel ComputationalAssemblerBasic.java;
• è consentito il lancio di un massimo di 1.000 ricette nello stesso tick
della simulazione; anche questo vincolo è modificabile nel file OrderDi-
stiller.java.
La sintassi dei passi computazionali sopra descritti è mostrata nella Ta-
bella 4.8. In questo esempio il passo C1001 richiede tre matrici, le numero
10, 20, 30; il passo produttivo 100 è fittizio, ha il solo scopo di permettere
l’esecuzione della computazione. Il passo C1002 richiede la sola matrice 20,
nella quale è contenuto il numero della ricetta che deve essere lanciata.
4. JES: JAVA ENTERPRISE SIMULATOR 79
c 1001 3 10 20 30 100 s 1
c 1002 1 20 10 s 2
Tabella 4.8: Ricette che lanciano ricette
4.8 Le capacità contabili
jES è in grado di tenere automaticamente una semplice contabilità secondo
due differenti punti di vista:
• nel primo caso ogni prodotto è caricato dei costi fissi e variabili relativi
alle unità che sono state coinvolte nella produzione;
• nella seconda visione si contabilizzano i costi per unità produttiva; per
le unità inattive sono considerati solo i costi fissi.
I costi sono contabilizzati ad ogni tick dell’orologio della simulazione.
Per quanto riguarda i ricavi, sono calcolati dal simulatore applicando,
alternativamente, un margine di ricarico ad ogni costo sostenuto dall’azienda
oppure ad ogni passo produttivo eseguito. Il mark-up è pertanto definito da
un valore, detto v, che risulta dalla seguente somma:
v = [numeroDiT ick]× revenuePerEachStep
+ [costi]× revenuePerCostUnit
il parametro revenuePerEachStep indica il margine di ricarico da applicare
per ogni passo produttivo eseguito, il parametro revenuePerCostUnit quello
da applicare ad ogni costo sostenuto dall’azienda, che deve essere scritto nel
seguente modo: (1+mark-up). Nel corso della stessa simulazione soltanto
uno dei due parametri può essere diverso da zero.
4. JES: JAVA ENTERPRISE SIMULATOR 80
4.8.1 I costi
Nella cartella Costs/ si trovano i seguenti files creati da jES che riportano i
costi relativi all’azienda simulata:
1. nel file totalDailyCosts.txt c’è la somma dei costi fissi e variabili gior-
nalieri. Il giorno è considerato l’unità di tempo della simulazione ed è
definito come un blocco di tick il cui numero è fissato dal parametro
ticksInATimeUnit; pertanto se il parametro è uguale a 10, un giorno
della simulazione sarà composto da 10 tick;
2. in totalCosts.txt è presente la somma cumulata dei costi contabilizzati
nel file precedente;
3. finishedOrderCosts.txt riporta il costo degli ordini conclusi dall’inizio
della simulazione;
4. il file dailySemimanufacturedOrderCosts.txt indica i costi derivanti dal-
la produzione degli ordini alla fine di uno specifico giorno.
5. in totalInventoryFinancialCosts.txt si trova il costo dei magazzini con-
tabilizzati secondo il criterio stabilito dal parametro inventoryEvalua-
tionCriterion, che può essere 1 se si considerano solo i costi variabili,
2 per tenere conto anche dei costi fissi, 3 per valorizzarli secondo il
parametro v illustrato nel paragrafo precedente.
4.8.2 I ricavi
I ricavi sono contabilizzati nel momento in cui i beni o servizi creati sono
venduti. Nella cartella Revenues/ sono riportati i seguenti files di testo:
1. dailyRevenues.txt, nel quale si trovano i ricavi derivanti dagli ordini
conclusi, valorizzati secondo il parametro v ;
4. JES: JAVA ENTERPRISE SIMULATOR 81
2. totalRevenues.txt, in cui si riporta il totale del file precedente dall’inizio
della simulazione;
3. nel file dailyStoredComponentValue.txt si trova il valore dei magazzini,
valorizzati secondo il criterio espresso dal parametro inventoryEvalua-
tion;
4. in dailySemimanufacturedProductRevenues.txt si ha il valore dei semi-
lavorati valorizzati con v.
4.8.3 L’utile
L’utile dell’impresa è riportato, per ogni tick, nel file Benefit/benefit.txt ed è
calcolato nel seguente modo:
totalRevenues
+dailyStoredComponentV alue
+totalSemimanufacturedRevenues
−totalCosts
−totalInventoryF inancialCosts
4.9 Lanciare una simulazione
Per attivare una simulazione è possibile scegliere se lanciare gli ordini in modo
casuale o utilizzare un calendario preciso.
Nel primo caso gli ordini sono generati usando l’orderGenerator.
Nella seconda ipotesi si utilizza l’orderDistiller; in questo caso è necessario
introdurre il terzo formalismo, When Doing What, che contiene il calendario.
Questa modalità è la più adatta per lo studio di situazioni reali, come ad
esempio gli studi sulle imprese VIR S.p.A. e BasicNet S.p.A., in cui le attività
sono legate ad un preciso calendario.
4. JES: JAVA ENTERPRISE SIMULATOR 82
4.9.1 I grafici di una simulazione
Durante una simulazione sono visibili i grafici che forniscono alcune infor-
mazioni sulla simulazione stessa e sulle attività che si stanno svolgendo
nell’azienda virtuale.
Il grafico mostrato in Figura 4.5 indica l’andamento generale delle liste
d’attesa delle unità nel corso della simulazione; è composto da tre linee che
rappresentano il livello minimo (linea arancione), massimo (linea gialla) e
medio (linea blu) delle waiting list.
Il grafico in Figura 4.6 indica l’andamento durante la simulazione del
guadagno o della perdita dell’impresa virtuale.
Il grafico della Figura 4.7 indica il rapporto tra l’attuale tempo richiesto
per l’esecuzione degli ordini già completati e il tempo previsto in ciascu-
na ricetta; un eventuale ritardo rispetto ai tempi previsti potrebbe signi-
ficare un’errata specificazione dei tempi delle ricette oppure un problema
organizzativo all’interno dell’impresa.
Nel grafico mostrato in Figura 4.8 è indicato, con un istogramma per
ogni unità, il numero di ordini presenti nella waiting list di ciascuna unità.
Sull’ascissa sono rappresentate le unità produttive e sull’ordinata il numero
di ordini nella lista d’attesa.
In Figura 4.9 è mostrato il grafico relativo alle endUnit; sull’asse orizzon-
tale sono indicate le endUnit e sull’asse verticale la quantità di semilavorati
o prodotti finiti presenti in ciascuna di esse.
4. JES: JAVA ENTERPRISE SIMULATOR 83
Figura 4.5: Grafico dell’andamento delle liste d’attesa
Figura 4.6: Andamento dell’utile durante la simulazione
4. JES: JAVA ENTERPRISE SIMULATOR 84
Figura 4.7: Rapporto totaltimetotallenght
Figura 4.8: Liste d’attesa delle unità dell’impresa virtuale
4. JES: JAVA ENTERPRISE SIMULATOR 85
Figura 4.9: Livello delle endUnit
Capitolo 5
L’azienda reale: BasicNet
Il Gruppo BasicNet opera nel settore dell’abbigliamento informale e sportivo,
delle calzature e degli accessori per lo sport e per il tempo libero. I marchi
con cui è presente sul mercato sono Kappa, Robe di Kappa e, da febbraio
2004, K-Way e Superga; il Gruppo possiede inoltre il marchio Jesus Jeans,
per il quale è previsto uno sviluppo nel futuro.
L’attività del gruppo consiste nello sviluppo dei marchi posseduti e nella
diffusione dei prodotti ad essi collegati attraverso una rete di aziende licenzia-
tarie e indipendenti; secondo i dati di maggio 2004, il network dei licenziatari
copre 83 mercati a livello mondiale.
Il gruppo fa capo a BasicNet S.p.A., con sede a Torino, quotata alla Borsa
Italiana nel segmento STAR.
5.1 La storia
Il Gruppo BasicNet nasce nel 1994, quando Football Sport Merchandise S.r.l.
di Marco Boglione rileva dal fallimento il Maglificio Calzificio Torinese, pro-
prietario dei marchi di abbigliamento Kappa, Robe di Kappa e Jesus
Jeans.
86
5. L’AZIENDA REALE: BASICNET 87
Football Sport Merchandise S.r.l. è fondata nel 1983 e il suo presidente
è Marco Boglione, attuale presidente di BasicNet. La società è la prima in
Italia, e tra le prime in Europa, ad ottenere dalle principali squadre di calcio
la licenza per produrre e distribuire capi d’abbigliamento per il tempo libero
contrassegnato dai loro marchi e segni distintivi.
Nel 1988 Football Sport Merchandise, a fronte di una rilevante crescita
a livello mondiale del mercato dei prodotti contrassegnati dai marchi delle
squadre sportive, costituisce la Basic Merchandise S.r.l.. L’obiettivo di que-
sta nuova società, oggi BasicItalia, è l’ottimizzazione dei processi produttivi
e la distribuzione dei prodotti in alcuni mercati esteri, nonché diventare li-
cenziatario e distributore esclusivo per l’Italia dell’americana Starter Inc., al
tempo leader mondiale di abbigliamento realizzato su licenza delle squadre
delle ‘‘Major Leagues” statunitensi.
Nel 1994, come affermato precedentemente, Football Sport Merchandise
rileva dal curatore fallimentare i marchi, il magazzino e l’immobile di proprie-
tà del Maglificio Calzificio Torinese S.p.A., fondato nel 1916, in cui Marco
Boglione aveva iniziato la sua carriera professionale nel 1976. L’obiettivo
dell’acquisizione è quello di disporre di marchi conosciuti ed affermati per
poter valorizzare nel modo migliore le potenzialità organizzative e commer-
ciali di Football Sport Merchandise nel mercato dell’abbigliamento informale,
sportivo e per il tempo libero.
Nel 1996 il gruppo Ventuno Investimenti, guidato da Alessandro Benet-
ton, diventa nuovo partner strategico del Gruppo BasicNet. Si firmano nuovi
contratti di licenza per i principali mercati europei e si definiscono le strate-
gie per la penetrazione dei marchi nei mercati degli Stati Uniti, dell’Asia e
dell’Africa. In questa occasione Football Sport Merchandise assume la nuova
denominazione sociale di Basic Properties Services S.p.A..
Nel 1997, coerentemente con la strategia di penetrazione del mercato
5. L’AZIENDA REALE: BASICNET 88
USA, sono acquisite le attività di una piccola azienda americana, fortemente
specializzata nel segmento dell’abbigliamento e delle calzature per il calcio
e con una struttura organizzativa e distributiva adatta a costituire la base
operativa del licenziatario statunitense del Gruppo. Nasce così la Kappa
USA, attualmente controllata da BasicNet. Nel corso dello stesso anno la
controllata Kappa Italia, oggi BasicItalia, avvia la costruzione di un nuovo
complesso immobiliare a Torino destinato ad attività di confezionamento,
magazzino e spedizione.
Nel 1998 ha inizio la ristrutturazione della sede del Gruppo BasicNet a
Torino, che prevede la realizzazione del primo progetto BasicVillage per ospi-
tare, oltre alle attività gestionali del gruppo, anche il nuovo modello di punto
vendita, il Gigastore Kappa. Quest’ultimo rappresenta lo strumento con il
quale il Gruppo si propone di smaltire le rimanenze generate dall’attività
dei licenziatari e, allo stesso tempo, entrare in mercati ad alto potenziale di
consumo, ma a basso potere d’acquisto.
All’inizio del 1999 Basic World N.V., l’azionista di maggioranza relativa,
decide di quotare nella Borsa Italiana le azioni del Gruppo, il cui cespite
principale è rappresentato dai marchi Kappa e Robe di Kappa. Nel giu-
gno del 1999 viene deliberato di far confluire in BasicNet S.p.A. tutte le
partecipazioni delle società attive del Gruppo detenuto da Basic World N.V..
A febbraio 2004 BasicNet, a seguito di una trattativa con Formula Sport
Group, acquisisce il marchio K-Way e diventa licenziatario unico mondiale
del marchio Superga, per un periodo di 14 anni e con un diritto di opzione
per l’acquisto dello stesso. L’acquisto di questi marchi rientra nel piano im-
prenditoriale di BasicNet, fondato sulla gestione di marchi aventi una buona
tradizione e forti prospettive di sviluppo. Per il marchio K-Way il Gruppo
prevede di sviluppare una strategia distributiva simile a quella di Kappa in-
dirizzata soprattutto ai negozi multimarca di articoli sportivi; per Superga è
5. L’AZIENDA REALE: BASICNET 89
previsto il raggiungimento dei mercati asiatici e americani mediante accordi
di licenza, mentre quello europeo verrà in larga misura fornito con vendite
dirette organizzate da Kappa Italia, il licenziatario italiano del Gruppo, che
a luglio 2004 ha cambiato la sua ragione sociale ridenominandosi BasicItalia.
5.2 Il business system
Il gruppo BasicNet ha impostato il proprio sviluppo su un modello di impresa
‘‘a rete’’, identificando nel licenziatario il mezzo ideale per la diffusione e la
distribuzione dei propri prodotti nel mondo.
Questo modello di business ha consentito al gruppo di crescere rapida-
mente e, allo stesso tempo, mantenere una struttura flessibile ed efficiente.
Si presenta infatti come una grande azienda composta di tante piccole impre-
se collegate tra loro da una piattaforma informatica tramite internet. Alla
capogruppo BasicNet fanno capo tutte le attività strategiche:
• Ricerca e Sviluppo di prodotto;
• Global Marketing;
• sviluppo e coordinamento del network dei licenziatari;
• finanza strategica;
• Information Technology, cioé creazione di sistemi di software per con-
sentire la gestione on line di tutti i processi della catena dell’offerta.
La piattaforma informatica rappresenta uno dei principali investimenti
strategici del Gruppo, al quale è dedicata la massima attenzione; è stata con-
cepita e sviluppata completamente integrata al web, considerato dal Gruppo
lo strumento ideale di comunicazione fra gli elementi che costituiscono il
network.
5. L’AZIENDA REALE: BASICNET 90
Direttamente collegati con BasicNet vi sono i Sourcing Center, che hanno
il compito di individuare e coordinare le fabbriche a cui affidare la realizza-
zione dei prodotti. Ai licenziatari è affidata la distribuzione dei prodotti ai
dettaglianti e l’attività di marketing su base locale, secondo le linee guida del
Gruppo; per l’approvvigionamento dei prodotti finiti i licenziatari possono
appoggiarsi ai Sourcing Centers che BasicNet mette loro a disposizione.
Inoltre, il Gruppo BasicNet è anche presente nella vendita diretta al
pubblico con tre modelli di concept store:
• il negozio monomarca RDK, che trova l’ideale collocazione nei centri pe-
donali e storici cittadini e nelle gallerie dei centri commerciali. Gestito
in franchising, propone una gamma di abbigliamento classico-sportivo
per adulti;
• il Gigastore, grande boutique dei marchi BasicNet. Propone tutto
l’assortimento di sport, jeans e abbigliamento casual;
• lo Spaccio, realizzato in aree non tipicamente commerciali con la carat-
teristica di proporre un vasto assortimento di stock e convenienza di
prezzo.
La Figura 5.1 mostra il modello di business BasicNet, così strutturato:
1. attività di collaborazione e contatto tra il gruppo BasicNet ed i licen-
ziatari; fase di acquisto del campionario da parte dei licenziatari;
2. realizzazione dei MetaSamples, scelta dei MetaSamples da realizza-
re come campionario, richiesta delle specifiche tecniche, produzione e
consegna delle merci;
3. richiesta di previsioni di vendita ai licenziatari;
5. L’AZIENDA REALE: BASICNET 91
Figura 5.1: Rappresentazione del business system di BasicNet
5. L’AZIENDA REALE: BASICNET 92
4. richiesta ai Sourcing Centers del preventivo per la produzione degli
articoli;
5. raccolta degli ordini delle merci; gli ordini sono passati ai Soucing
Centers;
6. vendita dei prodotti sul mercato.
5.3 La struttura del Gruppo
In testa al Gruppo, come si può notare dalla Figura 5.2, si trova BasicNet.
Accanto alla funzione di capogruppo, gestisce e coordina il network, pre-
sidiando direttamente le attività strategiche; inoltre supporta i licenziatari
nella gestione dei contratti di sponsorizzazione più importanti sia attraverso
le proprie strutture sia tramite la controllata Basic Properties.
Figura 5.2: La struttura del Gruppo
BasicNet controlla al 90% Kappa Italia S.p.A., ridenominata a luglio 2004
BasicItalia, che opera come licenziatario per l’Italia per i marchi Kappa, Robe
5. L’AZIENDA REALE: BASICNET 93
di Kappa, Jesus Jeans e K-Way e come licenziatario europeo per il marchio
Superga; inoltre si presenta come azienda licenziataria per tutti i paesi del
mondo in cui non sono già presenti altri licenziatari. BasicItalia gestisce
anche tutte le iniziative di vendita al dettaglio che fanno capo al Gruppo,
vale a dire i negozi RDK, i Gigastore e gli spaci aziendali.
Basic Village S.p.A., interamente controllata da BasicNet, è la società
immobiliare proprietaria dell’ex stabilimento del Maglificio Calzificio Torine-
se, ribattezzato Basic Village; la società concede in locazione gli immobili
del Village alle società del Gruppo.
BasicNet controlla interamente anche Basic Properties B.V., che opera
come licenziataria mondiale di Basic Trademark S.A., società proprietaria
dei marchi. La sua attività consiste nel concedere in sub-licenza i diritti
di proprietà intellettuale del Gruppo BasicNet ai diversi licenziatari locali,
amministrare e gestire i contratti di sub-licenza e le royalties da essi derivanti.
La società è titolare di contratti di sponsorizzazione e coordina l’attività di
comunicazione, promozione e marketing globale del Gruppo BasicNet.
LF Basic Ltd è controllata per il 50% da Basic Properties B.V. e per
il 50% da Li & Fung Trading Ltd di Hong Kong, società del gruppo mul-
tinazionale Li & Fung. LF Basic controlla a sua volta al 100% LF Basic
Europe S.r.l. di Torino; le due società operano come Sourcing Centers, la
prima prevalentemente per l’area asiatica, la seconda nell’area del bacino del
Mediterraneo.
Basic Properties America Inc., già Kappa USA Inc., ha operato fino al 30
ottobre 2001 come licenziatario del Gruppo negli Stati Uniti; successivamente
le operazioni sono state cedute a terzi, con la sub-licenza dei marchi. Dal
1◦ novembre 2001, dopo aver provveduto a cedere il proprio ramo di attività
operativa alla Kappa USA, opera esclusivamente come sub-licenziante dei
marchi per il mercato statunitense.
5. L’AZIENDA REALE: BASICNET 94
Kappa Spain Sports S.L., partecipata dal Gruppo BasicNet con una quota
del 30%, opera quale licenziatario per la Spagna.
5.4 Le divisioni dot.com
Il processo produttivo che dalla creazione conduce alla commercializzazione
delle collezioni è suddiviso in numerose fasi, ciascuna delle quali viene por-
tata a termine da una divisione aziendale; queste ultime, nella terminologia
adottata da BasicNet, vengono definite divisioni dot.com, per sottolineare
ancora una volta l’importanza del web all’interno dell’azienda. Le divisioni
dot.com sono descritte qui di seguito.
BasicBiddings.com
Gestisce l’asta per la scelta delle aziende che dovranno produrre gli articoli
per i licenziatari e sceglie le vincitrici per ogni articolo. L’asta è rivolta alle
Trading Company (società esterne al Gruppo) ed ai Sourcing Center (società
gestite in joint-venture dal Gruppo). Nel 2004 le società che partecipano
all’asta sono 5.
BasicCountry.com
Rappresenta l’insieme dei licenziatari legati al gruppo BasicNet. È da sot-
tolineare che i licenziatari non acquistano i loro articoli da BasicNet ma
direttamente dalle fabbriche asiatiche e pagano una commissione per l’inter-
mediazione (7% del fatturato) alle Trading Company.
I licenziatari, ogni tre mesi, devono pagare al Gruppo una somma pari al
10% del loro fatturato per l’insieme dei servizi offerti; di tale somma, un 4%
spetta a World Wide Strategic Advertisement, che ha funzioni di
marketing, un 4% è destinato alla remunerazione dei marchi e il restante 2%
5. L’AZIENDA REALE: BASICNET 95
va a BasicNet che lo suddivide ulteriormente tra le divisioni dot.com.
Secondo i dati del 2004 esistono circa 35 licenziatari che coprono 83 paesi nel
mondo.
BasicFactory.com
Ha in carico la gestione della produzione; esistono due deadline per gli
ordini di produzione di ogni collezione, a distanza circa di un mese una
dall’altra. I licenziatari possono effettuare gli ordini non appena sul sito
www.basicfactory.com vengono pubblicate le immagini degli articoli che com-
pongono la collezione. Una volta raccolti gli ordini la produzione viene lan-
ciata. Le società che si occupano della produzione, generalmente asiatiche,
sono in continuo contatto con le fabbriche locali e forniscono loro adeguate
garanzie finanziarie.
BasicForecast.com
Si occupa delle previsioni di produzione e vendita interagendo con i licenziata-
ri. Le previsioni sono sostanzialmente l’aggregato delle quantità di probabile
acquisto indicate dai licenziatari in sede di ordine dei MetaSamples.
BasicMarketing.com
Effettua lo studio del marketing globale dei marchi e la supervisione dei
licenziatari.
BasicSamples.com
Svolge l’attività di ideazione e design del campionari, considerata, all’inter-
no dell’azienda, la fase più importante di tutto il processo produttivo. La
vendita del campionario è una delle principali fonti reddituali della divisione.
5. L’AZIENDA REALE: BASICNET 96
BasicSpecs.com
Determina le specifiche tecniche dei prodotti da consegnare alle Trading Com-
pany e ai Sourcing Centers. La divisione agisce in due momenti, la prima
volta prima della produzione del campionario e fornisce alla sartoria incari-
cata da BasicSamples.com la ‘‘distinta base” degli articoli. In seguito viene
chiamata ad operare prima che le Trading Company e i Sourcing Centers
inizino la produzione e fornisce loro tutte le caratteristiche che gli articoli de-
vono possedere in modo più dettagliato rispetto al precedente. L’obiettivo di
BasicSpecs.com è che diverse fabbriche siano in grado di realizzare prodotti
uguali.
5.5 Il ciclo di produzione
La creazione di una collezione inizia circa un anno prima della sua data di
commercializzazione. L’ideazione e lo sviluppo degli articoli avviene all’in-
terno di BasicSamples, divisione dot.com incaricata dell’attività di ricerca e
sviluppo, design e prototyping; questa fase è considerata la più importante
di di tutta la catena produttiva e culmina con la produzione e commercia-
lizzazione del campionario. Le collezioni possono essere di due tipi: Gene-
ral Make-Up (gmu), collezioni proposte interamente da BasicNet, e Special
Make-Up (smu), proposte dai licenziatari; queste ultime sono generalmen-
te più piccole rispetto alle gmu e i licenziatari possono scegliere se avere
l’esclusiva degli articoli o permetterne l’acquisto ad altri licenziatari.
I licenziatari possono visualizzare e acquistare gli articoli sul sito inter-
net di BasicSamples e hanno la possibilità di interagire con i designers e di
inviare commenti relativi agli articoli; i licenziatari possono acquistare an-
che solo una parte della mega-collezione proposta da BasicSamples, creando
una collezione più piccola personalizzata alle esigenze del mercato in cui si
5. L’AZIENDA REALE: BASICNET 97
trovano. Secondo i dati di BasicNet del 2002, il 95% degli articoli proposti
da BasicSamples è stato approvato dai licenziatari. Dopo aver ricevuto il
campionario, i licenziatari iniziano l’attività di promozione locale che dura
indicativamente 10 settimane.
Una volta ordinati i campionari, i licenziatari comunicano a BasicForecast
le loro previsioni di vendita; queste informazioni delineano con una buona
approssimazione quella che sarà la produzione per ogni singolo articolo.
L’industrializzazione del prodotto compete a BasicSpecs, che specifica la
distinta base dei singoli capi, in modo da fornire regole comuni a tutti i
produttori sparsi nel mondo.
Dopo la definizione delle specifiche tecniche di produzione degli articoli,
BasicBiddings si rivolge ai Sourcing Centers, gestiti in joint-venture, e alle
Trading Company, esterne al Gruppo, per l’asta di aggiudicazione dei pro-
dotti e quindi alla stesura del listino definitivo, che conterrà il minor prezzo di
produzione offerto durante l’asta per ogni articolo della collezione. I Sourcing
Centers e le Trading Company hanno il compito di individuare e coordinare
le società alle quali affidare la realizzazione dei prodotti.
La fase successiva viene gestita da BasicFactory, che passa alle fabbriche
incaricate della produzione gli ordini dei licenziatari. La produzione richiede
circa quattro mesi di tempo.
Infine, le fabbriche consegnano i prodotti finiti direttamente ai licenzia-
tari, che li distribuiscono ai dettaglianti. Generalmente il prezzo di vendita
all sale degli articoli è pari al prezzo di produzione offerto in fase di asta
moltiplicato per un coefficiente, che viene stabilito da BasicNet, pari a 2.2.
5.6 Le attività di promozione
BasicNet promuove la propria attività e la notorietà dei marchi attraverso
un’importante attività di sponsorizzazione in numerose discipline sportive.
5. L’AZIENDA REALE: BASICNET 98
Il calcio è lo sport dove il marchio Kappa storicamente è più presente e
oggi vestono questo marchio gli atleti di più di 100 team in tutto il mondo tra
cui il Totteham, Feyenoord, Werder Bremen, Real Betis, Genk, Sampdoria e
Brescia.
Tra gli altri sport, BasicNet è attiva nel rugby, con la Nazionale Italiana
ed il più esclusivo club di Francia, lo Stade Français, e nel ciclismo, con i
campioni del mondo della SAECO e nello sci con la fornitura tecnica a 30 tra
i più importanti sci club europei e con le federazioni nazionali di Argentina
e Messico.
Ulteriori attività dell’azienda torinese riguardano anche il basket, con ben
15 squadre di livello internazionale, il volley, con oltre 20 team in 5 paesi, il
motociclismo, con Honda, e l’hockey su ghiaccio.
A sostegno del marchio Robe di Kappa BasicNet è impegnata nel golf con
la federazione italiana campione d’Europa e con l’abbinamento ai prestigiosi
tornei dell’Italian Open e RDK Ladies Europen tour.
Capitolo 6
L’azienda virtuale: Basic_jES
6.1 Prima analisi e possibili sviluppi
L’azienda BasicNet è già stata oggetto di studio in due tesi di laurea, Lamieri
(2002) e Merlo (2003a), nelle quali è stata creata una prima formalizzazione
dell’azienda virtuale, Basic_jES. Con questo lavoro si intende rendere più
vicino alla realtà questo modello di impresa e creare uno strumento che sia
in grado di fornire una buona rappresentazione di una realtà complessa come
quella aziendale.
Con la simulazione è possibile mettere a confronto diversi modelli orga-
nizzativi che un’impresa potrebbe adottare e analizzare le caratteristiche di
ognuno per definire quali sarebbero i vantaggi e i problemi derivanti da un
cambiamento all’interno dell’azienda. Tuttavia occorre ricordare che que-
sto metodo non è in grado di includere tutte le peculiarità del mondo reale,
pertanto i risultati della simulazione sono in grado di fornire indicazioni di
massima utili a scopo scientifico ma che devono essere considerate con le
dovute cautele nel caso di applicazioni concrete.
Nell’autunno 2004 è uscita una nuova versione di jES, che incorpora
l’analisi presente in Merlo (2003b), nella quale sono presenti tre diverse
99
6. L’AZIENDA VIRTUALE: BASIC_JES 100
ricostruzioni del business system dell’azienda:
• nella prima viene descritta l’azienda nel modo in cui realmente opera:
BasicNet non partecipa direttamente al processo produttivo, in quanto
quest’ultimo è attribuito totalmente ai Sourcing Centers. Le principali
fonti di ricavo dell’azienda sono rappresentate dall’incasso delle royal-
ties, pari al 10% del totale degli acquisti effettuati dai licenziatari, e
dalla prestazione dei servizi di assistenza a favore delle altre società del
gruppo;
• nella seconda viene descritta un’ipotetica BasicNet che operi come un’a-
zienda tradizionale producendo i prodotti e vendendoli direttamente ai
licenziatari;
• nel terzo esempio si descrive la BasicNet come un’azienda che faccia
produrre i propri prodotti in outsourcing e li venda direttamente ai
licenziatari.
Nel confronto tra modelli di business presente in Merlo (2003b) è stata
eseguita un’analisi dei costi e ricavi originati da ciascuna tipologia di azienda.
Alle divisioni dot.com sono stati assegnati degli ordini di grandezza di costi
fissi e variabili in base a quanto suggerito dalla dottoressa Bruschi1; il termine
‘‘dot.com’’ è utilizzato in BasicNet per riferirsi alle divisioni interne illustrate
nel paragrafo 5.4.
Alle Trading Company sono stati imputati costi fissi e variabili pari a 1, a
titolo di puro esempio, a causa della mancanza di dati che indichino il loro
vero valore dei costi di produzione. Infatti le Trading Company sono esterne
all’azienda e le uniche informazioni che BasicNet ha su esse è il prezzo offerto
nella fase di bidding per la produzione delle collezioni.
1Direttore Generale dei Sistemi Informativi di BasicNet
6. L’AZIENDA VIRTUALE: BASIC_JES 101
Dalle simulazioni svolte si è notato che l’andamento dei costi totali è si-
mile nei tre casi, in quanto il peso delle Trading Company, con costi fissi e
variabili pari a 1, è ininfluente sul totale; per ottenere risultati più realistici
occorrerebbe conoscere i costi reali imputabili alle Trading Company. Nel
secondo e terzo caso si nota inoltre, come previsto, che si registrano ricavi
consistenti durante l’intero periodo, a differenza di quanto accade nella si-
tuazione reale; questo perché in queste due ricostruzioni l’azienda partecipa
attivamente a tutte le fasi del processo produttivo e vende direttamente le
collezioni ai licenziatari.
Un possibile sviluppo proposto nei precedenti lavori (Lamieri 2002 e Mer-
lo 2003a) riguarda l’approfondimento del confronto tra i diversi modelli di
business, inserendo valori di costo più vicini alla realtà, e in particolare l’a-
nalisi di una divisione dot.com, in particolare BasicSamples, considerata la
parte di maggiore interesse dell’intera azienda. Infatti studiando più a fondo
questa divisione dot.com sarebbe possibile definire un calendario più detta-
gliato della produzione, che nell’analisi di Lamieri (2002) e Merlo (2003a) è
stato solo ipotizzato.
Una seconda indicazione consiste nello studio più approfondito di due im-
portanti momenti del processo produttivo: le aste bandite da BasicNet nei
confronti delle Trading Company, necessarie per stabilire a chi sarà affida-
ta la produzione dei prodotti, e le previsioni eseguite dai licenziatari sulla
base dei MetaSamples proposti da BasicSamples. I MetaSamples sono, se-
condo la terminologia dell’azienda, le prime bozze dei modelli che verranno
commercializzati in seguito.
6.2 Novità nell’azienda
Nell’incontro del 26/03/2004 la dottoressa Bruschi mi ha informato di alcune
novità che forse verranno realizzate nell’azienda nel prossimo futuro.
6. L’AZIENDA VIRTUALE: BASIC_JES 102
Entro luglio 2004 il licenziatario italiano Kappa Italia cambierà la ragio-
ne sociale in BasicItalia. Il nome attuale era stato utile nel momento della
quotazione dell’azienda nella Borsa Italiana, per dare un punto di riferimento
facilmente riconoscibile agli investitori; l’esigenza di un nuovo nome viene dal
fatto che l’azienda attualmente possiede e commercia diversi marchi: Kap-
pa, Robe di Kappa, Jesus Jeans, K-Way e Superga (gli ultimi due acquisiti
recentemente).
È in fase di studio la possibilità per i Sourcing Centers di assumere un
nuovo ruolo all’interno del gruppo. Attualmente essi propongono, durante la
fase di bidding, un prezzo per la produzione degli articoli di una collezione e in
seguito assegnano la produzione ad altre aziende; queste ultime si occupano
direttamente di consegnare e fatturare ai licenziatari.
La novità consisterebbe nell’affidare ai Sourcing Centers una funzione di
maggiore responsabilità: oltre ad organizzare la produzione delle collezioni
incaricando le aziende dovrebbe consegnare e fatturare la merce ai licenzia-
tari; in questo modo diventerebbero direttamente responsabili del buon fine
della produzione e consegna delle collezioni.
Inoltre attualmente il processo produttivo dell’azienda segue una time-
table che specifica le fasi e i relativi tempi necessari per il percorso dei pro-
dotti dalla preparazione dei MetaSamples alla consegna del prodotto finito.
Questa è un’informazione molto utile per il modello, in quanto con queste
nuove indicazioni sarà possibile fare un passo avanti per ottenere una maggior
veridicità della simulazione.
6.3 Le modifiche al modello precedente
Ho effettuato alcune modifiche al modello presente in Lamieri (2002) e Merlo
(2003a) grazie alle nuove informazioni sull’azienda fornite dalla dottoressa
Bruschi e a causa di alcune variazioni nella prassi operativa di BasicNet.
6. L’AZIENDA VIRTUALE: BASIC_JES 103
Per quanto riguarda le collezioni, attualmente BasicNet non produce più
MegaCollection, collezioni di 300 articoli, ma le suddivide in più collezioni
piccole composte da circa 100-150 articoli; ho pertanto deciso di inserire que-
sta novità nel modello. Inoltre attualmente le collezioni possono essere di
due tipi, General Make-Up (gmu) e Special Make-Up (smu); le prime sono
normali collezioni create da BasicNet, mentre per le seconde è presente la
possibilità per i licenziatari di proporre la creazione di nuovi articoli a Ba-
sicSamples, in base alle proprie esigenze o a particolari richieste del mercato.
I nuovi articoli possono essere messi a disposizione di tutti i licenziatari o
possono essere considerati come esclusiva del licenziatario, a seconda della
volontà del proponente. Nel modello descritto qui di seguito non è prevista
la presenza di Special Make-Up.
Ho inserito la possibilità per i licenziatari di effettuare un secondo ordine
ai Sourcing Centers a distanza di circa un mese dal primo ordine. La ragione
di questa opportunità è permettere ai licenziatari di ricevere un certo tipo
di articoli prima di altri; ad esempio, per una collezione primavera-estate i
licenziatari potrebbero decidere di ordinare prima le T-shirts e le canottiere
per averle a disposizione già all’inizio di maggio, e in seguito, con il secondo
ordine, i costumi da bagno per poterli commerciare all’inizio di giugno.
Ho inoltre deciso di simulare 2 anni (600 giorni) di vita di BasicNet, in
cui ogni mese è composto da 25 giorni. Per il calendario delle fasi di ciascuna
collezione mi sono basato sulla scansione reale degli ordini, che viene illustrata
nel prossimo paragrafo.
6. L’AZIENDA VIRTUALE: BASIC_JES 104
6.4 Analisi del calendario
6.4.1 La time-table di BasicNet
Secondo la time-table che mi ha consegnato la dottoressa Bruschi il processo
produttivo per ciascuna collezione si articola nelle fasi illustrate in seguito.
Dopo l’esecuzione ciascuna di esse deve essere notificata con una e-mail a
BasicNet. Nella prassi di BasicNet le date delle fasi sono stabilite a ritroso,
partendo dalla data in cui si desidera che sia commercializzata la collezione
fino ad arrivare a determinare il momento in cui deve essere creata; in alcuni
casi è possibile che alcune fasi siano saltate o che altre durino di meno, in
modo da accelerare il processo produttivo, a seconda delle esigenze aziendali.
1. Creation: BasicSamples crea i MetaSamples di una collezione.
2. smu Request: uno o più licenziatari propongono nuovi articoli da in-
serire in una collezione a parte; anche se il numero di articoli proposto è
esiguo, questi vengono inseriti in una collezione a se stante, una Special
Make-Up.
3. Collection Approved/Rejected: se il licenziatario proponente for-
nisce le garanzie necessarie viene iniziato lo sviluppo della nuova colle-
zione. La principale garanzia che il licenziatario deve dare è il raggiun-
gimento di una quota di acquisti sufficiente per la copertura dei costi
di produzione dell’articolo.
4. Development: rappresenta il periodo di tempo in cui BasicSamples
sviluppa e definisce i MetaSamples.
5. View What is Ready: è il momento in cui i licenziatari vedono i
primi disegni della nuova collezione ed esprimono un parere in merito;
in base alle loro opinioni BasicNet decide se continuare lo sviluppo degli
6. L’AZIENDA VIRTUALE: BASIC_JES 105
articoli o interromperlo. La maggior parte degli articoli viene in genere
approvato dai licenziatari, infatti le statistiche di BasicNet mostrano
che nel 2002 il 95% degli articoli proposti è stato approvato.
6. Proto Receiving: BasicSamples riceve i prototipi degli articoli del-
la collezione, per essere in grado di effettuare una prima verifica dei
prodotti.
7. BasicSample Buy: BasicSamples vende il campionario ai licenziata-
ri; per la sua realizzazione non viene bandita un’asta tra le Trading
Company, ma viene prodotto direttamente da una sartoria scelta da
BasicSamples.
8. Intermediate Forecast: i licenziatari effettuano una prima previsio-
ne degli acquisti per ciascun articolo della collezione. La necessità di
questa previsione è fornire immediatamente a BasicNet un’informazio-
ne di massima sui probabili acquisti dei licenziatari; in seguito viene
richiesta una seconda previsione, più attendibile della precedente, dopo
che i licenziatari hanno visionato il campionario.
9. Samples receiving at Licensee Warehouse: i licenziatari ricevono
il campionario.
10. Final Forecast: i licenziatari effettuano la previsione definitiva sugli
acquisti della collezione.
11. Sales Campaign: periodo di tempo di circa un mese nel quale i
licenziatari effettuano la campagna promozionale presso i negozi per
pubblicizzare la nuova collezione e raccogliere gli ordini.
12. Bid: in questa fase BasicBiddings indice l’asta tra i Sourcing Centers
interessati alla produzione della collezione; ciascuno propone un prezzo
6. L’AZIENDA VIRTUALE: BASIC_JES 106
per la produzione di ogni articolo e viene scelto il Sourcing Center che
offre il prezzo più conveniente per BasicNet, vale a dire il più basso.
13. BasicFactory: la collezione di cui è stato venduto il campionario vie-
ne pubblicata sul sito www.basicfactory.com; da questo momento i li-
cenziatari possono ordinare la produzione di ogni articolo al Sourcing
Center che ha vinto l’asta;
14. First Deadline: i licenziatari hanno un mese di tempo per effettuare
il primo ordine di acquisto.
15. Second Deadline: secondo ordine dei licenziatari per gli articoli della
collezione.
16. Deliveries To Shop: periodo in cui può essere venduta la collezione;
la produzione e la consegna dei prodotti richiedono circa quattro mesi
di tempo.
Con le date precise in cui è stata eseguita ciascuna fase è possibile ag-
giornare il calendario della simulazione inserito nel file orderSequence.xls ;
per calcolare il tempo da una fase all’altra (mostrato nella Tabella 6.1)
ho considerato soltanto i giorni lavorativi di una settimana (dal lunedi al
venerdi).
6. L’AZIENDA VIRTUALE: BASIC_JES 107
Fase Data Giorni Giorni
effettivi lavorativi
dalla fase seguente dalla fase seguente
Creation 3-set-03 25 18
Development 28-set-03 10 7
View What is Ready 8-ott-03 25 18
Proto Receiving 2-nov-03 22 15
BasicSample Buy 24-nov-03 113 72
Intermediate Forecast 16-mar-04 0 0
Samples receiving at
Licensee Warehouse 16-mar-04 0 0
Final Forecast 16-mar-04 0 1
Sales Campaign 17-mar-04 15 10
Bid 1-apr-04 39 26
BasicFactory 10-mag-04 15 11
First Deadline 25-mag-04 27 18
Second Deadline 21-giu-04 133 94
Deliveries To Shop 1-nov-04
Tabella 6.1: Successione delle fasi per una collezione
6. L’AZIENDA VIRTUALE: BASIC_JES 108
6.4.2 Il calendario di Basic_jES
Per stabilire il calendario della simulazione ho ripreso il modello creato in La-
mieri (2002) e Merlo (2003a) e ho adattato il calendario dell’azienda simulata
al calendario dell’azienda reale. Le fasi della simulazione sono le seguenti:
1. Disegno dei Metasamples : BasicSamples crea una nuova collezione.
2. Previsione dei licenziatari : ciascun licenziatario esprime una previsione
degli acquisti per ciascun articolo della collezione.
3. Somma delle previsioni : BasicForecast somma le previsioni dei licen-
ziatari per ciascun articolo della collezione; se le previsioni superano
una certa soglia l’articolo viene sviluppato, in caso contrario viene
abbandonato.
4. Produzione campionario: BasicSample, tramite un Sourcing Center da
essa scelto, produce il campionario.
5. Consegna Campionario: il campionario viene consegnato ai licenziatari.
6. Asta Trading Company : le cinque Trading Company presenti nella si-
mulazione offrono un prezzo per la produzione di ciascun articolo della
collezione.
7. Scelta Trading Company : BasicBiddings sceglie, per ciascun articolo,
la Trading Company che ha offerto il prezzo di produzione minore e
affida a questa la produzione.
8. Primo ordine: i licenziatari effettuano un ordine per la collezione.
9. Secondo ordine: i licenziatari effettuano il secondo ordine.
10. Produzione: la Trading Company che ha vinto l’asta inizia la produ-
zione.
6. L’AZIENDA VIRTUALE: BASIC_JES 109
11. Consegna: le Trading Company consegnano i prodotti ai licenziatari.
6.5 Le ricette produttive
Le ricette produttive descrivono i passi che le unità del modello devono com-
piere. Ho mantenuto le stesse presenti in Lamieri (2002) e Merlo (2003a) e
ne ho aggiunta una nuova che permette ai licenziatari di effettuare il secondo
ordine alle Trading Company.
Le ricette 101, 102, 103, 104 descrivono la fase di creazione del campiona-
rio di quattro collezioni diverse. Nel modello precedente si riferivano rispet-
tivamente alla creazione di una collezione Kappa, Robe di Kappa, ‘‘scarpe”
e ‘‘sport’’. Per aggiornare il modello ho chiamato queste quattro ricette con
i marchi posseduti attualmente da BasicNet, perciò:
• La ricetta 101 si riferisce ad una collezione Kappa.
• La ricetta 102 si riferisce ad una collezione Robe di Kappa.
• La ricetta 103 si riferisce ad una collezione K-Way.
• La ricetta 104 si riferisce ad una collezione Superga.
Le ricette da 201 a 235 consentono ai licenziatari di esprimere una previ-
sione di acquisto su ciascun articolo della collezione.
Con la ricetta 300 BasicForecast somma le previsioni dei licenziatari per
ogni articolo.
La ricetta 301 simula la produzione del campionario della collezione e
accumula i prodotti nella endUnit 101.
La ricetta 302 esegue un procurement sulla endUnit in cui è contenuto
il campionario e simula la consegna ai licenziatari; in seguito sono anche
contabilizzati i ricavi derivanti dalla sua vendita.
Le ricette da 401 a 405 simulano l’asta tra le Trading Company.
6. L’AZIENDA VIRTUALE: BASIC_JES 110
Con ricetta 500 BasicBiddings sceglie la vincente dell’asta: vince la Tra-
ding Company che ha offerto il prezzo di produzione più conveniente.
Le ricette da 601 a 635 simulano il primo ordine dei licenziatari.
Le ricette da 701 a 735 descrivono il secondo ordine dei licenziatari.
Con la ricetta 800 le Trading Company producono le collezioni e accumu-
lano gli articoli nella endUnit 102.
Con la ricetta 900 le unità rappresentative di BasicNet effettuano un
procurement sulla endUnit 102 e simulano la consegna delle collezioni ai
licenziatari; inoltre viene contabilizzato il valore delle royalties derivanti dalla
vendita.
La ricetta 1 conclude la simulazione.
6.6 Le memoryMatrixes
Le memoryMatrixes sono utili per gestire le operazioni immateriali e per
contenere i dati della simulazione per tutte le collezioni e possono essere
utilizzate con l’ausilio degli oggetti computazionali. Ho ridotto le dimensioni
delle colonne da 301 a 152, in quanto nel modello sono state eliminate le
MegaCollections sostituendole con collezioni minori. Le matrici di memoria
del modello sono le seguenti:
designMatrix : vettore di una riga e una colonna nel quale viene inserito il
numero di MetaSamples disegnati da BasicSample;
agentMatrix : matrice nella quale sono salvate, nella prima riga, le previ-
sioni dei licenziatari per ciascun articolo della collezione e le quantità
richieste nel primo e nel secondo ordine, rispettivamente nella secon-
da e nella terza riga; nel modello è presente una agentMatrix per ogni
licenziatario;
6. L’AZIENDA VIRTUALE: BASIC_JES 111
tcMatrix : matrice in cui sono salvati i prezzi offerti dalla Trading Company;
anche in questo caso si ha una matrice per ogni Trading Company;
basicNetMatrix : contiene le informazioni possedute da BasicNet:
• la prima riga contiene la somma dei valori previsti dai licenziatari
per ogni articolo;
• la seconda indica lo status di ciascun articolo: 0 se è da non rea-
lizzare, 1 se è da realizzare, 2 se il campionario è stato realizzato,
3 se l’articolo è stato prodotto;
• la terza contiene il prezzo, per ogni articolo, che ha vinto l’asta
per la produzione;
• la quarta contiene la quantità di ogni articolo richiesta dai licen-
ziatari per il primo ordine;
• la quinta contiene la quantità di ogni articolo richiesta dai licen-
ziatari per il secondo ordine;
• la sesta indica la quantità totale richiesta dai licenziatari per ogni
articolo; il valore inserito in questa riga per ciascun articolo sarà
moltiplicato per il prezzo di vendita nel momento in cui si BasicNet
calcola e contabilizza le royalties.
orMatrix : in ogni colonna è indicata la Trading Company che deve produrre
l’articolo a cui è intestata la colonna.
6.7 Le modifiche al codice
Nella classe ComputationalAssembler.java ho inserito un nuovo oggetto com-
putazionale, C1909, che permette ai licenziatari di effettuare il secondo
ordine.
6. L’AZIENDA VIRTUALE: BASIC_JES 112
Inizialmente il codice crea un contatore con il metodo privato getCounter
verifica che la riga e colonna 0 della designMatrix non sia vuota, cioè che la
collezione esista. In seguito controlla che il licenziatario abbia effettuato il
primo ordine alla Trading Company; per far ciò utilizza il metodo getEmpty,
il quale controlla che la casella della memoryMatrix del licenziatario preso in
considerazione non sia vuota, in caso contrario non si esegue il nuovo ordine
e nella riga 3 alla colonna corrispondente all’articolo dell’agentMatrix viene
scritto il valore 0; la stessa cosa avviene nella sesta riga della basicNetMatrix
nel caso che la casella in considerazione sia vuota. L’obiettivo di questo
accertamento è evitare che sia fatto un ordine per un articolo il cui sviluppo
è stato abbandonato.
In seguito il passo computazionale sceglie se effettuare un nuovo ordine
in modo casuale, utilizzando come parametro un numero estratto da una di-
stribuzione normale con media 100 e varianza 50000; se il numero è maggiore
della media della distribuzione l’ordine è eseguito.
Anche la quantità da ordinare è scelta in modo casuale estraendo un
campione da una distribuzione normale con media 500 e varianza 900000 (si
attivano dei correttivi nel caso che il valore ottenuto sia troppo piccolo o
troppo grande). Il valore così ottenuto è salvato nelle caselle corrispondenti
all’articolo dell’agentMatrix e della basicNetMatrix con il metodo setValue,
e sul monitor è stampata l’indicazione dell’avvenuto ordine del licenziatario
e la quantità ordinata.
In seguito il passo computazionale somma, per ogni articolo, il valore dei
due ordini e lo inserisce nella riga 6 della basicNetMatrix; questo valore sarà
utile nel corso della simulazione per la Trading Company che dovrà produrre
l’articolo e per il calcolo del valore delle royalties.
Listing 6.1: ComputationalAssembler.java: C1909¨
pub l i c void c1909 ( )
6. L’AZIENDA VIRTUALE: BASIC_JES 113
{
i n t th r e sho ld = 100 ;
checkMatr ixes ( 1 909 , 3 ) ;
des ignMatr ix=(MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
agentMatrix=(MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
bas icNetMatr ix=(MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 2 ) ;
l a y e r=pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
i n t j = getCounter ( agentMatrix , 3 ) ;
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
i f ( j <= des ignMatr ix . getValue ( layer , 0 , 0 ) )
{
//Checks i f the l i c e n s e e has a l r eady done the f i r s t order
i f ( ! agentMatrix . getEmpty ( layer , 2 , j ) )
{
i n t s e l e c t = ( i n t )
normal . getSampleWithMean$withVariance (100 , 50000 ) ;
// dec ide to do or not another order
i f ( s e l e c t > thre sho ld )
{
i n t order2 = ( i n t )
normal . getSampleWithMean$withVariance (500 ,900000) ;
//Min va lue
i f ( order2 <10)
order2 = 10 ;
6. L’AZIENDA VIRTUALE: BASIC_JES 114
//Max va lue
i f ( order2 >25000)
order2 = 25000 ;
agentMatrix . setValue ( layer , 3 , j , order2 ) ;
i f ( bas icNetMatr ix . getEmpty ( layer , 5 , j ) )
bas icNetMatr ix . setValue ( layer , 5 , j , 0 . 0 ) ;
i n t totOrder2 = ( i n t )
bas icNetMatr ix . getValue ( layer , 5 , j ) + order2 ;
bas icNetMatr ix . setValue ( layer , 5 , j , totOrder2 ) ;
System . out . p r i n t l n ( "The␣2nd␣ order ␣ o f ␣ L i censee␣#"
+ myUnit . getUnitNumber ( ) + "␣ i s ␣" + order2 + "␣ f o r ␣ item␣#"
+ j + "␣with␣ l ay e r␣#" + lay e r + "␣ totOrder␣#"+ totOrder2 ) ;
}//end i f ( s e l e c t )
e l s e
{
agentMatrix . setValue ( layer , 3 , j , 0 . 0 ) ;
i f ( bas icNetMatr ix . getEmpty ( layer , 5 , j ) )
bas icNetMatr ix . setValue ( layer , 5 , j , 0 . 0 ) ;
}//end e l s e
i n t totOrder1 = ( i n t ) bas icNetMatr ix . getValue ( layer , 4 , j ) ;
i n t totOrder2 = ( i n t ) bas icNetMatr ix . getValue ( layer , 5 , j ) ;
i n t totOrder = totOrder1 + totOrder2 ;
bas icNetMatr ix . setValue ( layer , 6 , j , totOrder ) ;
6. L’AZIENDA VIRTUALE: BASIC_JES 115
}/end i f ( check ing f i r s t order )
}
}
}
done = true ;
// The a r t i c l e can not be ordered −> done=f a l s e
}//end c1909§ ¦
6.8 Analisi di diversi business system
L’obiettivo finale di questo lavoro è l’analisi di tre diverse modalità di busi-
ness system che BasicNet potrebbe adottare. Nel primo caso si descrive la
BasicNet reale, che affida le fasi della produzione e delle vendite totalmente
ai Sourcing Centers o alle Trading Company. Nella seconda ricostruzione si
immagina una BasicNet che agisca come un’azienda tradizionale, producendo
i prodotti al suo interno e vendendoli direttamente ai licenziatari. Nel terzo
esempio si rappresenta la BasicNet come un’azienda che produce le collezioni
in outsourcing, tramite le Trading Company, ma che si occupa direttamente
della vendita.
Con l’analisi di costi e ricavi originati in queste tre situazioni è possibile
effettuare un confronto tra il modello di business adottato da BasicNet e due
ipotetici business system alternativi. Tuttavia occorre ricordare che lo studio
qui proposto prende in considerazione solo alcuni aspetti della realtà, perciò i
risultati ottenuti possono costituire un’indicazione per le scelte aziendali che
deve essere affiancata anche da altre valutazioni; questo modello infatti offre
un confronto tra tre diversi tipi di gestione partendo da una base comune,
la BasicNet come è descritta nel caso 1, che è diversa da quella reale per-
6. L’AZIENDA VIRTUALE: BASIC_JES 116
ché nella vera azienda possono verificarsi eventi diversi da quelli immaginati
in Basic_jES. Il modello illustrato fornirebbe risultati assoluti nel solo ca-
so in cui la realtà descritta nel computer riproducesse quella del mondo reale.
Nei prossimi paragrafi è illustrata la formalizzazione dei tre diversi modelli
di Basic_jES e le modifiche portate al modello generale descritto preceden-
temente.
6.9 Caso 1
In questa ricostruzione si presenta la BasicNet reale, che opera come descrit-
to nel paragrafo 6.4.1. Gli unici costi che l’azienda sostiene sono legati al
mantenimento del network e all’ideazione e produzione del campionario; i
centri di costo sono rappresentati dalle divisioni dot.com. I ricavi sono ori-
ginati dalla vendita del campionario ai licenziatari e dalla riscossione delle
royalties, che rappresentano il 10% degli acquisti effettuati dai licenziatari
alle Trading Company; le royalties sono suddivise all’interno della BasicNet
nel seguente modo:
• 4% a World Wide Strategic Advertisement, che ha funzioni di marke-
ting;
• 4% per la remunerazione del marchio;
• il restante 2% ripartito tra le divisioni dot.com nel modo illustrato in
Tabella 6.2;
6.9.1 Le unità produttive
In questo modello, come nella BasicNet reale, le Trading Company consegna-
no direttamente la merce ai licenziatari, perciò per ciascuna di esse ho ag-
6. L’AZIENDA VIRTUALE: BASIC_JES 117
DIVISIONE % royalties
BasicSamples 0,5%
BasicForecast 0,25%
BasicSpecs 0,25%
BasicBiddings 0,25%
BasicFactory 0,25%
BasicNet 0,5%
TOTALE 2%
Tabella 6.2: Suddivisione delle royalties
giunto un’unità produttiva nel file unitData/unitBasicData.txt, ipotizzando
che all’interno siano organizzate almeno in due divisioni: la prima si occupa
dell’asta per l’aggiudicazione e della produzione e la seconda della consegna
ai licenziatari.
In questo caso le unità produttive sono le seguenti:
• 35 licenziatari, ognuno suddiviso in due sezioni, una che si occupa di
effettuare le previsioni sugli acquisti futuri e una che esegue gli ordini;
• 5 Trading Company, strutturate nel modo illustrato precedentemente;
• BasicSamples, divisa in quattro sezioni ognuna incaricata della gestione
di uno specifico tipo di collezione;
• BasicForecast;
• BasicSpecs;
• un’ipotetica Trading Company che rappresenta una sartoria che pro-
duce il campionario per conto di BasicSamples. È un’unità esterna
a BasicNet, alla quale non sono imputati costi, in quanto sono già
compresi nei costi di BasicSamples;
6. L’AZIENDA VIRTUALE: BASIC_JES 118
• BasicBiddings;
• BasicFactory;
• unità rappresentative di BasicNet che si occupano della consegna del
campionario, della contabilizzazione dei ricavi e interrompono la simu-
lazione al giorno 600.
In questa ricostruzione le uniche unità che originano dei costi sono le
divisioni dot.com, perché i licenziatari e le Trading Company sono unità
esterne a BasicNet. Per ottenerne un’indicazione plausibile ho estratto i
valori dalla sezione del bilancio consolidato di BasicNet in cui si elencano i
costi di gestione in base alla loro variabilità (Figura 6.1); i costi al di sopra
del Margine di Contribuzione sono tutti variabili, mentre quelli al di sotto
sono fissi. Nell’incontro del 26/03/2004 la dottoressa Bruschi mi ha suggerito
di ripartire i costi fissi in base alla suddivisione delle royalties mostrata in
Tabella 6.2 e di imputare solo a BasicSamples costi variabili, perché è l’unica
divisione la cui operatività è legata al numero di MetaSamples prodotti, a
differenza delle altre che hanno soltanto compiti di gestione del network di
BasicNet.
I costi fissi delle divisioni sono mostrati nella Tabella 6.3. Per ottenere
il costo unitario variabile da assegnare a BasicSamples occorre dividere il
valore a bilancio dei costi variabili totali per il numero di articoli creati da
BasicNet nell’anno 2002, pari a 66762:
CUVBasicSamples =CV T
n◦MetaSamples=
59.806.000
6.676∼= 8.958
Il valore dei costi di ciascuna divisione deve essere diviso per il numero
di unità che nel modello la rappresentano; questo numero si può ricavare dal
2Fonte: BasicNet (2002)
6. L’AZIENDA VIRTUALE: BASIC_JES 119
Figura 6.1: Costi variabili e fissi di BasicNet
unitData/unitBasicData.txt. In questo file sono indicati anche il valore dei
costi fissi e variabili di ciascuna unità.
Dal momento che i costi presi in considerazione sono annuali, i costi fissi
dovranno anche essere divisi per il numero di giorni che rappresentano un
anno nel modello (300) e per il numero di tick che compongono un giorno
della simulazione (32). La motivazione è che jES contabilizza i costi ad ogni
tick e non facendo ciò si causerebbe un’amplificazione dei costi dell’azienda.
I costi variabili di BasicSamples non devono essere divisi per il numero di
tick totali della simulazione, in quanto essi indicano quanto costa all’azienda
la produzione di ciascun articolo. Perciò questo valore deve essere diviso per
il numero di tick necessari alla produzione di ogni MetaSamples; il motivo è
che ad ogni tick jES contabilizza il costo variabile delle unità attive, quindi
se un’unità impiega 6 tick per la creazione di un articolo il costo totale sarà
pari a sei volte il costo indicato nel file unitData/unitBasicData.txt.
6. L’AZIENDA VIRTUALE: BASIC_JES 120
Divisione % costo CFT
imputabile
BasicSamples 25% 9.874.000
BasicForecast 12,5% 4.937.000
BasicSpecs 12,5% 4.937.000
BasicBiddings 12,5% 4.937.000
BasicFactory 12,5% 4.937.000
BasicNet 25% 9.874.000
TOTALE 100% 39.947.000
Tabella 6.3: Costi fissi delle divisioni dot.com (in euro)
6.9.2 Le nuove ricette
Ho diviso la ricetta 900, che simula la consegna dei prodotti ai licenziatari e
contabilizza il valore delle royalties, in due distinte, perché nella realtà questi
incarichi spettano a due soggetti diversi.
Ho creato la ricetta 900 (Figura 6.2) che simula la consegna degli arti-
coli della collezione ai licenziatari effettuando un procurement sull’endUnit
102 da parte della Trading Company incaricata della produzione; in seguito
l’oggetto computazionale C1913 aggiorna lo status dell’articolo inserendo
nella riga 2 della basicNetMatrix il numero 4, che significa ‘‘prodotto conse-
gnato”, e stampa sul monitor l’indicazione che l’articolo è stato consegnato
ai licenziatari dalla Trading Company che lo ha prodotto. Nella ricetta è
presente il processo or che è utilizzato per scegliere la Trading Company che
dovrà consegnare l’articolo ai licenziatari; per la decisione si fa ricorso alla
orMatrix, matrice di memoria in cui in ciascuna colonna è indicato il numero
della Trading Company che ha prodotto l’articolo a cui è intestata la colonna
stessa.
6. L’AZIENDA VIRTUALE: BASIC_JES 121
Figura 6.2: Ricette 900 e 950
La ricetta 950 (Figura 6.2) simula il pagamento e la contabilizzazione
delle royalties da parte di BasicNet; il passo computazionale C1912 ne cal-
cola il valore moltiplicando per 0,1 il totale dei ricavi derivanti dalla vendita
degli articoli e lo inserisce nel file log/grossSales.txt creato dalla simulazione.
Nell’incontro del 13/07/2004 la dottoressa Bruschi mi ha informato che
in BasicNet il prezzo di vendita di ciascun articolo si ottiene moltiplicando
per un coefficiente il prezzo di produzione offerto dalla Trading Company che
ha vinto l’asta; questo coefficiente è calcolato da un software e attualmente
è pari a 2,2 per tutti gli articoli. Nel modello Basic_jES la determinazione
del prezzo all sale avviene nello modo descritto qui sopra.
6.9.3 Il calendario
Anche il calendario ha subito una modifica rispetto a quanto descritto nei
paragrafi precedenti, in quanto ho ipotizzato che i licenziatari paghino le
royalties a BasicNet dopo un certo periodo di tempo. Pertanto l’esecuzione
della sopra descritta ricetta 950 avviene 10 giorni dopo la consegna delle
collezioni.
6. L’AZIENDA VIRTUALE: BASIC_JES 122
6.9.4 Le modifiche al codice
C1913
Ho inserito nella classe ComputationalAssembler.java il metodo C1913, che
simula la distribuzione degli articoli da parte delle Trading Company.
Questo passo computazionale, dopo aver creato un contatore, verifica che
la designMatrix non sia vuota e controlla il numero di MetaSamples con
il metodo getValue. In seguito va a determinare lo status dell’articolo nella
seconda riga della basicNetMatrix e, se l’articolo considerato è stato prodotto
(il suo status è 3), inserisce nella casella il valore 4 con il metodo setValue,
per indicare che il prodotto è stato consegnato.
Successivamente l’oggetto computazionale cerca nella orMatrix il numero
della Trading Company incaricata di produrre l’articolo e lo copia nella co-
lonna 0 della della matrice; si utilizza questo espediente perché jES durante
la simulazione legge il branch da scegliere per il processo or nella casella (1,0)
della orMatrix.
Infine, sul monitor è stampata l’indicazione che l’articolo è stato conse-
gnato dalla Trading Company incaricata di produrlo.
Listing 6.2: ComputationalAssembler.java: C1913¨
pub l i c void c1913 ( )
{
checkMatr ixes ( 1 913 , 3 ) ;
des ignMatr ix=(MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
bas icNetMatr ix=(MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
orMatrix=(MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 2 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
6. L’AZIENDA VIRTUALE: BASIC_JES 123
i n t counter = getCounter ( basicNetMatrix , 2 ) ;
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
i f ( counter <= des ignMatr ix . getValue ( layer , 0 , 0 ) )
{
//Check i f item has been produced
i f ( bas icNetMatr ix . getValue ( layer , 2 , counter ) > 2)
{
f l o a t tc = orMatrix . getValue ( layer , 1 , counter ) ;
orMatrix . setValue ( layer , 1 , 0 , tc ) ;
System . out . p r i n t l n ( " Item␣␣#" + counter + "␣with␣ l ay e r␣#"
+ lay e r + "␣has␣been␣ d e l i v e r e d ␣by␣Trading␣Company␣" +
orMatrix . getValue ( layer , 1 , 0 ) ) ;
bas icNetMatr ix . setValue ( layer , 2 , counter , 4 . 0 ) ;
}
}
}
done = true ;
}//end c1913§ ¦
C1912
Ho portato alcune modifiche al passo computazionale C1912 che si occupa
della contabilizzazione delle royalties. Questo metodo inizialmente crea un
contatore, cerca il numero di MetaSamples creati nella designMatrix e in
seguito controlla nella basicNetMatrix, per ciascun articolo, il suo status (riga
6. L’AZIENDA VIRTUALE: BASIC_JES 124
2), il prezzo di produzione che ha vinto l’asta (riga 3) e la quantità totale
ordinata dai licenziatari (riga 6). Successivamente, se lo status dell’articolo è
4, cioè ‘‘prodotto consegnato’’, si calcolano il prezzo di vendita dell’articolo
moltiplicando il prezzo offerto dalla Trading Company per 2.23, il totale dei
ricavi e il valore delle royalties. Il valore delle royalties è memorizzato nel
file nel file log/grossSales.txt insieme all’indicazione del tick in cui è stato
contabilizzato. Infine sul monitor è stampata l’indicazione che le royalties
sono state pagate.
Listing 6.3: ComputationalAssembler.java: C1912¨
pub l i c void c1912 ( )
{
checkMatr ixes ( 1 912 , 2 ) ;
des ignMatr ix=(MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
bas icNetMatr ix=(MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
l a y e r=pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
i n t counter = getCounter ( basicNetMatrix , 6 ) ;
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
i f ( counter <= des ignMatr ix . getValue ( layer , 0 , 0 ) )
{
i f ( ! bas icNetMatr ix . getEmpty ( layer , 2 , counter )
&& ! bas icNetMatr ix . getEmpty ( layer , 3 , counter )
&& ! bas icNetMatr ix . getEmpty ( layer , 6 , counter ) )
{
i f ( bas icNetMatr ix . getValue ( layer , 2 , counter ) > 3 .0 )
{
3vedi paragrafo 6.9.2
6. L’AZIENDA VIRTUALE: BASIC_JES 125
double i temPr ice =
basicNetMatr ix . getValue ( layer , 3 , counter ) ∗ 2 . 2 ;
double totRevenues =
itemPr ice ∗ basicNetMatr ix . getValue ( layer , 6 , counter ) ;
double i t emSa l e s = ( totRevenues ∗ 0 . 1 ) ;
System . out . p r i n t l n ( " Roya l t i e s ␣ f o r ␣ item␣␣#" +
counter + "␣with␣ l ay e r␣#" + lay e r +
"␣have␣been␣payed␣by␣ l i c e n s e e s " ) ;
S t r ing text =
Globals . env . getCurrentTime ( ) + " ␣ |␣ " +
i temSa le s + "␣\n" ;
logOpen ( f a l s e , " l og / g r o s s S a l e s . txt " ) ;
t ry
{
gro s sSa l e sLog . wr i t e ( t ex t ) ;
g ro s sSa l e sLog . f l u s h ( ) ;
}
catch ( IOException e )
{
System . out . p r i n t l n ( e ) ;
MyExit . e x i t ( 1 ) ;
}
}
}
}
}
done = true ;
}//end c1912§ ¦
6. L’AZIENDA VIRTUALE: BASIC_JES 126
C1910
Ho effettuato una modifica anche al codice del metodo C1910, il cui compito
è concludere la simulazione e creare il file log/report.txt ; questo file indica,
per ogni collezione, il numero di MetaSamples creati e il numero di articoli
prodotti e abbandonati, in base al loro status indicato nella riga 2 della
basicNetMatrix. Ho impostato la creazione di questo file in modo che sia
indicato anche il numero di articoli che sono stati consegnati per ciascuna
collezione.
Il file log/report.txt è utile perché permette di verificare quanti sono gli
articoli che sono prodotti e consegnati e quanti quelli che sono abbandonati
a causa delle insufficienti previsioni di acquisto dei licenziatari.
6.9.5 I parametri della simulazione
Qui di seguito viene mostrato il file jesframe.scm, nel quale sono indicati i
parametri su cui si basa la simulazione e che sono mostrati nel probe del
ESFrameModelSwarm e del ESFrameObserverSwarm. Il linguaggio di pro-
grammazione utilizzato in questo file si chiama scheme, ed è un dialetto del
linguaggio Lisp.
Listing 6.4: jesframe.scm per il Caso 1¨
( l i s t
(
cons ’ eSFrameObserverSwarm
(
make−i n s t ance ’ ESFrameObserverSwarm
#:disp layFrequency 32
#:verboseChoice #f
#: pr in tMatr ixe s #f
#:checkMemorySize #f
#:unitHistogramXPos 1
6. L’AZIENDA VIRTUALE: BASIC_JES 127
#:unitHistogramYPos 600
#:endUnitHistogramXPos 578
#:endUnitHistogramYPos 1
)
)
(
cons ’ eSFrameModelSwarm
(
make−i n s t ance ’ ESFrameModelSwarm
#: u s eO rd e rD i s t i l l e r #t
#:ticksInATimeUnit 32
#:totalUnitNumber 134
#:totalEndUnitNumber 2
#:totalLayerNumber 17
#:totalMemoryMatrixNumber 43
#:sameStepLifoAssignment #t
#:assignEqualStepsToSameUnit #t
#:maxTickInAUnit 2080
#:useWarehouses #f
#:useNewses #f
#: revenuePerEachRecipeStep 0
#: revenuePerCostUnit 0
#: o rC r i t e r i o n 5
#:orMemoryMatrix 42
#: un i tC r i t e r i o n 2
)
)
)
;§ ¦
Essi significano:
useOrderDistiller: la successione delle ricette viene tratta dal file recipe-
Data/orderSequence.xls ; se il parametro fosse impostato false gli ordini
verrebbero generati in modo casuale;
6. L’AZIENDA VIRTUALE: BASIC_JES 128
ticksInATimeUnit: indica il numero di tick che costituiscono un giorno
della simulazione; in questo caso sono 32, ciascuno pari a 15 minuti;
totalUnitNumber: indica il numero di unità della simulazione;
totalEndUnitNumber: numero delle endUnit;
totalLayerNumber: numero di layer;
totalMemoryMatrixNumber: numero delle matrici di memoria;
sameStepLifoAssignment: se impostato su true, se un’unità è in grado
effettuare due passi per uno stesso ordine, la produzione avviene con
procedura LIFO; in questo modo la produzione risulta sequenziale;
assignEqualStepsToSameUnit: se impostato su true, se un ordine neces-
sita dello stesso passo per due volte consecutive tra loro, la lavorazione
viene svolta dalla stessa unità;
maxTickInAUnit: indica il numero massimo di tick in cui un ordine può
rimanere nella lista d’attesa di un’unità; una volta trascorsi l’ordine
viene eliminato;
useWarehouse: se impostato su true significa che le unità creano magaz-
zini;
useNewses: se è impostato su true le unità si scambiano informazioni;
revenuePerEachRecipeStep e revenuePerCostUnit: metodo di calco-
lo dei ricavi; siccome in questo caso Basic_jES non presenta ricavi, i
parametri sono entrambi nulli;
orCriterion: indica il criterio di scelta del ramo da parte del processo or
avviene con l’ausilio della orMatrix ;
6. L’AZIENDA VIRTUALE: BASIC_JES 129
orMemoryMatrix: numero della orMatrix ;
unitCriterion: indica il criterio di assegnazione degli ordini tra unità che
sono in grado di eseguire lo stesso passo; in questo caso, l’ordine viene
assegnato all’unità che ha la lista d’attesa meno lunga.
6.10 Caso 2
In questa seconda ricostruzione si presenta una BasicNet che si comporta
come un’azienda tradizionale che produce le collezioni al suo interno e le
vende direttamente ai licenziatari.
Costi e ricavi hanno una diversa origine causata dalla differente operativi-
tà dell’impresa rispetto al caso precedente. I costi derivano dalla produzione
diretta degli articoli da parte delle Trading Company, che in questo modello
sono considerate unità interne alle quali sono pertanto attribuiti dei costi. I
ricavi sono originati dalla vendita diretta delle collezioni ai licenziatari e sono
calcolati in base ad un margine di ricarico applicato sui costi di produzione.
Dal momento che le Trading Company sono unità interne all’azienda,
non ha più senso che l’assegnazione delle produzioni degli articoli sia decisa
tramite un’asta, perché è più corretto immaginare che di volta in volta le
lavorazioni siano affidate alla Trading Company con la lista d’attesa meno
lunga; per ottenere questo risultato ho portato alcune modifiche al modello
illustrato nei paragrafi precedenti.
6.10.1 Le modifiche al modello
Le ricette
Per ottenere un’azienda in cui i prodotti sono fabbricati internamente e le
attività sono assegnate alle unità secondo il criterio del numero di lavorazioni
presenti nelle liste d’attesa è necessario modificare la ricetta che descrive la
6. L’AZIENDA VIRTUALE: BASIC_JES 130
fase di produzione ed eliminare quelle che gestiscono l’asta tra le Trading
Company.
Ho perciò eliminato le ricette 401, 402, 403, 404, 405, che simulano
l’offerta di un prezzo di produzione da parte di ogni Trading Company, e la
ricetta 500, il cui compito è scegliere la Trading Company vincente.
Inoltre ho modificato la ricetta 800, riferita alla produzione; in questo ca-
so gli articoli possono essere prodotti da una qualsiasi delle Trading Company
e la scelta è fatta in base alla waiting list di ciascuna. Perciò ho eliminato
il processo or secondo cui la decisione è effettuata in base alla orMatrix e
ho ottenuto la nuova ricetta mostrata in Figura 6.3 composta di un solo
passo incaricato della produzione degli articoli. Questa ricetta non contiene
nessuna computazione, perciò è lanciata per ogni prodotto, anche per quelli
abbandonati; questo non è però un errore, perché nella versione definitiva del
modello la ricetta sarà lanciata da un’altra ricetta nel solo caso in cui l’arti-
colo debba essere prodotto. Per una trattazione più approfondita si rimanda
a Balla (2004).
Figura 6.3: Ricetta 800
In questo modello le collezioni sono consegnate direttamente da BasicNet,
perciò ho eliminato dal file recipeData/recipes.xls le ricette 900 e 950 descrit-
te nel paragrafo 6.9.2 e le ho sostituite con una ricetta unica, mostrata nella
Figura 6.4 che simula la consegna degli articoli ai licenziatari effettuando un
procurement sull’endUnit 102; l’oggetto computazionale C1913 stampa sul
monitor l’indicazione che l’articolo è stato consegnato.
Ho anche modificato la ricetta 302, che si occupa di consegnare il cam-
pionario, eliminando l’oggetto computazionale C1911 il cui compito era cal-
6. L’AZIENDA VIRTUALE: BASIC_JES 131
Figura 6.4: Ricetta 900
colare il prezzo degli articoli del campionario. Infatti in questa ricostruzione
i ricavi del campionario sono compresi nel calcolo del margine di ricarico. La
nuova ricetta, mostrata in Figura 6.5, esegue un procurement sull’endUnit
101 (nella quali è ‘‘immagazzinato” il campionario) e simula la consegna ai
licenziatari. Nella versione definitiva del modello anche questa ricetta è lan-
ciata da un’altra ricetta, il cui compito è valutare se il campionario debba
essere consegnato.
Figura 6.5: Ricetta 302
Il calendario
Nel calendario, descritto nel file recipeData/orderSequence.xls, ho eliminato
per tutte le collezioni prodotte durante la simulazione la fase dell’asta, che si
articola in due momenti: inizialmente le Trading Company offrono un prezzo
di produzione per ogni articolo e successivamente BasicBiddings sceglie la
vincente.
Le unità
Ho portato anche alcune modifiche al file unitData/unitBasicData.txt ; in
questo modello tutte le Trading Company sono in grado di effettuare lo stesso
passo produttivo, il numero 2010, il cui compito è produrre gli articoli (come
si vede in Figura 6.3).
6. L’AZIENDA VIRTUALE: BASIC_JES 132
Ho anche eliminato dal modello le unità che rappresentano BasicBiddings
e BasicFactory, perché la prima rimarrebbe inattiva per tutta la simulazione,
e la seconda non ha più motivo di esistere, siccome l’assegnazione della pro-
duzione avviene secondo quanto stabilito dall’orCriterion. A causa di queste
modifiche ho modificato il parametro totalUnitNumber nel file jesframe.scm,
che indica il numero di unità del modello.
Le matrici di memoria
Le matrici di memoria relative alle Trading Company non sono più necessarie,
dal momento che non esiste più l’asta. Inoltre occorre cancellare la orMatrix,
che non è più utilizzata durante la simulazione.
Perciò in questo modello le memoryMatrix sono una per ogni licenziatario
e una per BasicNet. Per non causare errori nella simulazione ho modificato
il numero della basicNetMatrix nel file recipeData/recipes.xls per tutte le
ricette che la utilizzano.
Inoltre ho modificato nel file jesframe.scm il parametro totalMemoryMatri-
xNumber, perché in questo caso ci sono 36 matrici di memoria, e ho eliminato
i parametri orMemoryMatrix e orCriterion.
6.10.2 I costi delle unità produttive
I costi delle unità sono gli stessi mostrati per il caso 1, con due differenze
rispetto al caso precedente: nell’azienda non esistono più BasicBiddings e
BasicFactory e perciò nemmeno i loro costi; inoltre le Trading Company in
questo esempio sono considerate interne all’azienda, e pertanto il loro utilizzo
comporta dei costi.
Per ricavare un ordine di grandezza dei costi di produzione delle colle-
zioni ho ricavato dal bilancio consolidato di BasicNet del 2002 il valore delle
Commissioni del Sourcing, che rappresentano la remunerazione conferita ai
6. L’AZIENDA VIRTUALE: BASIC_JES 133
Sourcing Centers dai licenziatari per coprire i costi di struttura originati dal
servizio di intermediazione loro offerto. Il dato a bilancio si riferisce alle so-
cietà LF Basic Ltd, che opera come Sourcing Center per l’area asiatica, e LF
Basic Europe S.r.l., Sourcing Center dell’area europea.
Per avere un’indicazione dei costi ho ipotizzato che i Sourcing Centers
chiudano il bilancio in pareggio, pertanto il valore delle commissioni pagate
dai licenziatari corrisponde ai costi da loro sostenuti. Inoltre, su indicazione
della dottoressa Bruschi, ho ipotizzato che il valore delle commissioni sia pari
al 7% dei costi totali di produzione degli articoli. Grazie a queste congetture
mi è stato possibile ricavare il valore dei costi (CT ) per la produzione degli
articoli.
Costi Di Produzione =
=CommissionidelSourcing × 100
7=
1.588.000× 100
7=
= 22.685.714
Questo valore rappresenta il costo sostenuto da due Sourcing Centers;
per ottenere il costo complessivo per la produzione delle collezioni occorre
considerare i costi delle 5 Trading Company alle quali BasicNet si affida. Per
conoscere questo valore, adottando l’ipotesi che i Sourcing Centers abbiano
gli stessi costi, è sufficiente impostare la seguente proporzione:
22.685.714÷ 2 = Costi totali ÷5
CostiTotali =22.685.714× 5
2= 56.714.286
Un ultimo problema da risolvere è il modo in cui ripartire i costi tra fissi
e variabili. Con il professor Terna abbiamo deciso di indicare tutti variabili
i costi delle Trading Company, immaginando che la scelta tra esse sia simile
6. L’AZIENDA VIRTUALE: BASIC_JES 134
ad una decisione di make-or-buy : le Trading Company avranno influenza sui
costi aziendali solo nel momento in cui verranno chiamate a operare e non
daranno origine a costi sommersi (o sunk costs).
Date queste assunzioni, il costo unitario variabile per la produzione di
un articolo è pari ai costi di produzione totali divisi per il numero di arti-
coli ordinati, e perciò prodotti, che nel primo semestre del 2002 ammonta
a 40.0004; ipotizzando che nei sei mesi successivi si sia prodotta la stessa
quantità, il numero di articoli prodotti per il 2002 è 80.000. Perciò il costo
variabile unitario è pari a:
CUVTradingCompany =CostiDiProduzione
n◦articoli=
56.714.286
80.000∼= 709
Per inserire i costi nel file unitData/unitBasicData.txt è necessario divi-
dere questo valore per il numero di tick necessari ad una Trading Company
per produrre un articolo, in modo analogo a quanto fatto per BasicSamples
nel paragrafo 6.9.1.
6.10.3 I ricavi aziendali
Per ottenere i ricavi di questa ipotetica BasicNet ho impostato un margine
di ricarico che viene applicato a tutti i costi sostenuti dall’azienda durante
la simulazione; per ottenere tale margine mi sono basato sui costi e ricavi
reali di BasicNet indicati a bilancio, in modo da ottenere un mark-up il più
possibile vicino alla realtà.
Il valore dei costi totali si ottiene sommando i costi totali delle divisioni
dot.com a quelli di produzione delle Trading Company. I costi delle divisioni
dot.com si ricavano sommando i costi variabili totali di BasicSamples ai costi
fissi totali (Tabella 6.3), mentre quelli delle Trading Company si trovano nel
4Fonte: BasicNet (2002)
6. L’AZIENDA VIRTUALE: BASIC_JES 135
modo descritto nel paragrafo precedente. Si ottiene pertanto che i costi totali
(CT ) di questa ipotetica BasicNet sono pari a:
CT = CV TBasicSamples + CFT + CV TTradingCompany =
= 59.806.000 + 39.497.000 + 56.714.286 =
= 156.017.286
Per quanto riguarda i ricavi, in questa ricostruzione BasicNet vende il
campionario, come anche nel caso 1, e le collezioni; pertanto i proventi totali
si ottengono dalla somma dei loro importi. Per il valore del campionario mi
sono basato sulla voce Vendita campionari presente nel bilancio di esercizio
di BasicNet del 2002. Per determinare i ricavi derivanti dalla vendita delle
collezioni ho estratto dal bilancio consolidato di BasicNet del 2002 la voce
Royalties ; siccome queste ultime sono pari al 10% degli acquisti dei licenzia-
tari dalle Trading Company, per ottenere il valore delle vendite (RTV endite) è
sufficiente impostare la seguente proporzione:
royalties÷ 0.1 = RTV endite ÷ 1
Inoltre occorre anche considerare tra i ricavi aziendali quelli che deriva-
no dalle vendite di Kappa Italia, ora BasicItalia, che a bilancio non sono
compresi nel computo delle royalties, ma sono indicati alla voce Vendite di
abbigliamento sportivo. Si ottiene pertanto che i ricavi totali aziendali (RT )
sono pari a:
RT = RTCampionario + RTV endite + RTKappaItalia =
= 2.602.375 + 163.110.000 + 91.739.000 =
= 257.451.375
6. L’AZIENDA VIRTUALE: BASIC_JES 136
In conclusione, il margine di ricarico che viene applicato a ciascun costo
effettuato dall’azienda è pari al 65%, che si ottiene nel modo seguente:
mark-up = RTCT∼= 1, 65
Questo valore sarà inserito nel file jesframe.scm, che contiene i parametri
della simulazione.
6.10.4 Le modifiche al codice
Rispetto al caso 1 la classe ComputationalAssembler presenta alcune novità.
Come descritto nel paragrafo 6.10.1, ho eliminato il passo computazionale
C1911, che si occupava del calcolo del prezzo del campionario, ed il passo
C1912, che calcolava il valore delle royalties.
Inoltre in questo modello non sono più necessari i passi computazionali
C1905, C1906, e C1908, che si occupano, rispettivamente, dell’offerta dei
prezzi da parte delle Trading Company, della scelta di BasicBiddings e della
scelta di BasicFactory della Trading Company che deve produrre. Ho perciò
eliminato questi metodi dal file ComputationalAssembler.java.
Infine, ho effettuato alcune modifiche all’oggetto computazionale C1913,
che sono illustrate qui di seguito.
C1913
In questa ricostruzione le collezioni sono consegnate ai licenziatari diretta-
mente da BasicNet. Questo passo computazionale crea un contatore con il
metodo getCounter, controlla che i MetaSamples siano stati disegnati nella
designMatrix e ne memorizza il numero con il metodo getValue; in seguito
controlla con getValue nella seconda riga della basicNetMatrix che l’articolo
sia stato prodotto e ne aggiorna lo status impostando con setValue il valore
4; infine stampa sul monitor l’indicazione che l’articolo in questione è stato
consegnato.
6. L’AZIENDA VIRTUALE: BASIC_JES 137
Listing 6.5: ComputationalAssembler.java: C1913¨
pub l i c void c1913 ( )
{
checkMatr ixes ( 1 913 , 2 ) ;
des ignMatr ix=(MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
bas icNetMatr ix=(MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
i n t counter = getCounter ( basicNetMatrix , 2 ) ;
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
i f ( counter <= des ignMatr ix . getValue ( layer , 0 , 0 ) )
{
//Check i f item has been produced
i f ( bas icNetMatr ix . getValue ( layer , 2 , counter ) > 2)
{
System . out . p r i n t l n ( " Item␣␣#" + counter + "␣with␣ l ay e r␣#"
+ lay e r + "␣has␣been␣ d e l i v e r e d " ) ;
bas icNetMatr ix . setValue ( layer , 2 , counter , 4 . 0 ) ;
}
}
}
done = true ;
}//end1913§ ¦
6. L’AZIENDA VIRTUALE: BASIC_JES 138
6.10.5 I parametri della simulazione
I parametri su cui si basa il modello sono contenuti nel file jesframe.scm e
durante la simulazione sono indicati nel probe del ESFrameModelSwarm e
del ESFrameObserverSwarm.
Le differenze con i parametri del caso 1 sono le seguenti:
• il diverso numero di unità, perché le Trading Company non hanno più
una divisione incaricata della consegna dei prodotti e non esistono più
BasicBiddings e BasicFactory;
• l’indicazione del mark-up, rappresentato dal parametro revenuePerCo-
stUnit, pari a 1.65, che esprime il margine di ricarico che viene applicato
a ciascun costo sostenuto da Basic_jES durante la simulazione;
• il numero inferiore di matrici di memoria;
• la mancanza dei parametri orCriterion e orMatrix;
Listing 6.6: jesframe.scm per il Caso 2¨
( l i s t
(
cons ’ eSFrameObserverSwarm
(
make−i n s t ance ’ ESFrameObserverSwarm
#:disp layFrequency 32
#:verboseChoice #f
#: pr in tMatr ixe s #f
#:checkMemorySize #f
#:unitHistogramXPos 1
#:unitHistogramYPos 600
#:endUnitHistogramXPos 578
#:endUnitHistogramYPos 1
)
6. L’AZIENDA VIRTUALE: BASIC_JES 139
)
(
cons ’ eSFrameModelSwarm
(
make−i n s t ance ’ ESFrameModelSwarm
#: u s eO rd e rD i s t i l l e r #t
#:ticksInATimeUnit 32
#:totalUnitNumber 124
#:totalEndUnitNumber 2
#:totalLayerNumber 17
#:totalMemoryMatrixNumber 37
#:sameStepLifoAssignment #t
#:assignEqualStepsToSameUnit #t
#:maxTickInAUnit 2080
#:useWarehouses #f
#:useNewses #f
#: revenuePerEachRecipeStep 0
#: revenuePerCostUnit 1 .65
#: un i tC r i t e r i o n 2
)
)
)
;§ ¦
6.11 Caso 3
Il terzo esempio di modello organizzativo mostra una BasicNet con struttura
simile a quella descritta nel caso 1 ma con una diversa origine dei ricavi, simile
al caso 2. Infatti si immagina che la produzione delle collezioni avvenga
in outsourcing e che BasicNet si occupi direttamente della loro vendita ai
licenziatari.
La struttura aziendale è simile a quella del caso 1, con le Trading Com-
6. L’AZIENDA VIRTUALE: BASIC_JES 140
pany che sono considerate unità esterne all’azienda con costi nulli. Inoltre, a
differenza del caso 2, l’aggiudicazione della produzione degli articoli avviene
tramite l’asta tra le Trading Company ed è scelta quella che propone il costo
minore di produzione; l’utilizzo dell’asta fornisce anche una buona rappre-
sentazione di quanto accade nella realtà, perché normalmente le aziende che
producono in outsourcing incaricano le imprese che garantiscono loro il minor
costo di produzione.
I ricavi vengono determinati come nel caso 2, applicando ad ogni co-
sto sostenuto durante la simulazione il margine di ricarico calcolato nel
paragrafo 6.10.3.
6.11.1 Le modifiche al modello
Le unità
Il file unitData/unitBasicData.txt è simile a quello descritto nel paragra-
fo 6.9.1, con la sola differenza che in questo caso le Trading Company sono
rappresentate da una sola unità, perché non devono consegnare le collezioni
ai licenziatari.
Le ricette
La consenga del campionario avviene nello stesso modo illustrato nel para-
grafo 6.10.1, con la ricetta mostrata in Figura 6.5, perché i ricavi derivanti
dalla vendita del campionario sono già compresi nel calcolo del margine di
ricarico.
La ricetta 800, che descrive la produzione è uguale alla corrispondente del
caso 1, perché le Trading Company sono scelte in base ai risultati dell’asta.
Per la consegna degli articoli si utilizza la ricetta 900 utilizzata anche nel
caso 2 (paragrafo 6.10.1).
6. L’AZIENDA VIRTUALE: BASIC_JES 141
6.11.2 Le modifiche al codice
Rispetto alla classe ComputationalAssembler utilizzata nel caso 1, ho elimi-
nato i passi computazionali C1911 e C1912, che si occupano della contabi-
lizzazione dei ricavi derivanti, rispettivamente, dalla vendita del campionario
e dalle royalties.
Inoltre ho modificato il metodo C1913 nello stesso modo illustrato nel
paragrafo 6.10.4.
6.11.3 I parametri della simulazione
I parametri su cui si basa la simulazione sono mostrati qui di seguito:
Listing 6.7: jesframe.scm per il Caso 2¨
( l i s t
(
cons ’ eSFrameObserverSwarm
(
make−i n s t ance ’ ESFrameObserverSwarm
#:disp layFrequency 32
#:verboseChoice #f
#: pr in tMatr ixe s #f
#:checkMemorySize #f
#:unitHistogramXPos 1
#:unitHistogramYPos 600
#:endUnitHistogramXPos 578
#:endUnitHistogramYPos 1
)
)
(
cons ’ eSFrameModelSwarm
(
make−i n s t ance ’ ESFrameModelSwarm
#: u s eO rd e rD i s t i l l e r #t
6. L’AZIENDA VIRTUALE: BASIC_JES 142
#:ticksInATimeUnit 32
#:totalUnitNumber 125
#:totalEndUnitNumber 2
#:totalLayerNumber 17
#:totalMemoryMatrixNumber 43
#:sameStepLifoAssignment #t
#:assignEqualStepsToSameUnit #t
#:maxTickInAUnit 2080
#:useWarehouses #f
#:useNewses #f
#: revenuePerEachRecipeStep 0
#: revenuePerCostUnit 1 .65
#: un i tC r i t e r i o n 2
#: o rC r i t e r i o n 5
#:orMemoryMatrix 42
)
)
)
;§ ¦
6.12 Risultati della simulazione
Ho eseguito alcune simulazioni per verificare gli effetti provocati dalle mie mo-
difiche al modello. Partendo dal modello di Basic_jES presente in Lamieri
(2002) e Merlo (2003a) ho fatto nuovi esperimenti per migliorare il funzio-
namento del modello, con l’obiettivo di ridurre il tempo di esecuzione delle
lavorazioni e renderlo pari al tempo previsto dalle ricette che le descrivono.
Primo esperimento
Ho avviato una simulazione per valutare gli effetti che il nuovo calendario
avrebbe avuto sul modello. Osservando il grafico della simulazione che in-
6. L’AZIENDA VIRTUALE: BASIC_JES 143
dica il numero di ordini presenti nella waiting list di ciascuna unità si può
notare che i licenziatari non sono in grado di eseguire nei tempi previsti
tutti gli ordini ad essi assegnati, perciò si creano lunghe code (in alcuni mo-
menti anche dell’ordine di 103) che causano problemi anche nel resto della
simulazione. Infatti, se i licenziatari non riescono ad effettuare le previsioni
per gli articoli di una collezione prima che BasicForecast le sommi, molti
di questi non sono prodotti perché il totale delle previsioni non supera la
soglia prestabilita da BasicNet. Questa tendenza è confermata se si osser-
va il file log/report.txt, mostrato in Tabella 6.4, nel quale sono indicati, per
ogni collezione, il numero dei MetaSamples creati, dei prodotti abbandonati
e di quelli effettivamente prodotti: pochi articoli delle collezioni superano la
prima verifica dei licenziatari e perciò il loro sviluppo viene abbandonato.
La Tabella 6.4 evidenzia inoltre dei problemi nel momento in cui Ba-
sic_jES deve operare nello stesso momento su più collezioni. Un esempio si
ha nel caso delle collezioni 1, 2, 3 e 4 che, secondo il calendario, devono essere
prodotte contemporaneamente; si può infatti notare che gli articoli realmen-
te prodotti sono pochi, perché per queste collezioni i licenziatari sono messi
sotto pressione da un grande numero di ordini e non riescono ad eseguirli
prima che BasicForecast sommi le previsioni.
Inoltre dal grafico di jES che indica l’andamento del rapporto tra il tempo
effettivo il tempo previsto dalle ricette produttive per l’esecuzione degli ordini
(Figura 6.6) si può notare che i tempi della simulazione sono circa 100 volte
maggiori rispetto a quelli previsti; anche il periodo medio di attesa per gli
ordini è molto alto, come si può notare in Figura 6.7 (la linea blu rappresenta
il tempo medio, quella gialla e rossa il tempo massimo e minimo).
Sulla base di questi risultati si può concludere che il modello così come
è costruito non è in grado di sostenere la reale time-table di BasicNet, e
perciò occorrono alcune modifiche che eliminino i problemi qui indicati per
6. L’AZIENDA VIRTUALE: BASIC_JES 144
migliorare l’andamento della simulazione.
Secondo esperimento
Dal momento che molti prodotti non sono realizzati a causa delle mancate
previsioni iniziali dei licenziatari, ho inserito due nuove unità per ogni licen-
ziatario a supporto delle due già esistenti; in questo modo le operazioni di
previsione e gli ordini possono essere svolte da due unità ed intuitivamente
si può concludere che le code nelle liste di attesa dei licenziatari dovrebbero
ridursi. Nel file jesframe.scm ho impostato il parametro unitCriterion pari a
2, per far sì che gli ordini siano assegnati all’unità con la lista d’attesa meno
lunga.
Inoltre ho deciso di far slittare di 10 giorni il controllo delle previsioni dei
licenziatari da parte di BasicForecast; questa modifica può essere ragionevole,
in quanto è presumibile che anche nella realtà sia concesso un certo lasso di
tempo ai licenziatari e permette così alle unità che li rappresentano di eseguire
le previsioni su un maggior numero di articoli prima che siano sommate tra
loro.
Ho anche scelto di spostare il momento in cui BasicBiddings effettua la
scelta della vincente 5 giorni dopo l’asta in cui le Trading Company offrono
i prezzi di produzione per gli articoli.
Con queste modifiche l’andamento della simulazione è notevolmente mi-
gliorato, infatti osservando il file log/report.txt si può notare che circa il 90%
degli articoli disegnati è stato prodotto.
6. L’AZIENDA VIRTUALE: BASIC_JES 145
Figura 6.6: Primo esperimento. Tempodiesecuzione
Tempoprevistodallericette
Figura 6.7: Primo esperimento. Tempi d’attesa degli ordini
6. L’AZIENDA VIRTUALE: BASIC_JES 146
Layer MetaSamples Articoli Articoli
disegnati abbandonati prodotti
1 150 109 29
2 100 99 1
3 30 29 1
4 50 49 1
5 100 73 27
6 150 149 1
7 50 49 1
8 100 99 1
9 50 22 28
10 100 71 0
11 30 2 28
12 50 20 30
13 75 46 29
14 100 68 32
15 150 104 0
16 75 46 29
Tabella 6.4: Articoli creati ed effettivamente prodotti per ogni collezione
6. L’AZIENDA VIRTUALE: BASIC_JES 147
Tuttavia permangono ancora alcuni problemi, in quanto, pur essendosi
ridotte, le code nelle waiting list delle unità che rappresentano i licenziatari
in alcune situazioni raggiungono ancora dei livelli molto elevati (dell’ordine
di 102), soprattutto nel momento in cui si effettuano gli ordini alle Trading
Company; inoltre il tempo medio di attesa per ogni ricetta (Figura 6.9) e il
rapporto tra il tempo effettivo di esecuzione e quello ipotizzato (Figura 6.8)
sono ancora alti, anche se risultano quasi dimezzati rispetto alla simulazione
precedente.
In particolare, osservando l’andamento del grafico mostrato in Figura 6.8
durante la simulazione, si può notare che le situazioni in cui il modello non è
in grado di rispettare i tempi previsti dalle ricette corrispondono ai momenti
in cui sono chiamati ad operare BasicSamples e i licenziatari. Infatti si può
notare che i ritardi maggiori si registrano nei momenti in cui BasicSamples
crea i MetaSamples della prima collezione e, in seguito, quelli delle collezioni
1, 2, 3, 4 al tick 5.000; infine l’ultimo notevole ritardo, al tick 10.000, è causato
dai licenziatari chiamati a prevedere contemporaneamente per le collezioni
5, 6, 7, 8.
Per migliorare questa situazione occorre inserire nel file unitData/unit-
BasicData.txt nuove unità per i licenziatari e per BasicSamples, affinché gli
ordini siano eseguiti nei tempi previsti dalle ricette e non si creino code
eccessive nelle waiting list delle unità produttive.
Terzo Esperimento
Ho effettuato nuove modifiche al file unitData/unitBasicData.txt inserendo
altre unità per BasicSamples e per i licenziatari.
BasicSamples è suddivisa in quattro sezioni, ciascuna delle quali si occupa
della creazione di una delle quattro possibili collezioni5; per ogni divisione ho
5vedi paragrafo 6.5
6. L’AZIENDA VIRTUALE: BASIC_JES 148
Figura 6.8: Secondo esperimento. Tempodiesecuzione
Tempoprevistodallericette
aggiunto un’unità in grado di effettuare lo stesso passo di quella già presente,
perciò ora BasicSamples è rappresentata da 8 unità produttive.
Per quanto riguarda i licenziatari ho aggiunto 2 nuove unità in grado di
effettuare le previsioni e altre 2 in grado di effettuare gli ordini, perciò ora i
licenziatari sono rappresentati complessivamente da 8 unità.
Dai risultati della simulazione mostrati in Figura 6.10 si può notare che
i ritardi nei tempi di produzione si sono dimezzati rispetto al caso preceden-
te e sono pari a 30 volte i tempi previsti dalle ricette; tuttavia persistono
i rallentamenti durante le fasi di creazione dei MetaSamples e durante la
formulazione delle previsioni e degli ordini dei licenziatari.
6.13 Considerazioni sui risultati
Dalle simulazioni precedenti si intuisce che ogni volta che raddoppia il nu-
mero delle unità produttive i tempi di esecuzione si dimezzano, pertanto,
per ottenere un buon risultato in termini di tempi di produzione, occorre
6. L’AZIENDA VIRTUALE: BASIC_JES 149
Figura 6.9: Secondo esperimento. Tempi d’attesa degli ordini
aumentare il numero delle unità che rappresentano i licenziatari e BasicSam-
ples, perché è proprio nei momenti in cui sono chiamate ad operare che si
riscontrano i maggiori ritardi nell’esecuzione delle ricette.
Occorre però fare una distinzione tra i licenziatari e BasicSamples. I
primi sono agenti esterni all’azienda e perciò un aumento delle unità che
li rappresentano non va a minare il risultato della simulazione totale, in
quanto in questa simulazione non si è interessati al funzionamento interno
dei licenziatari, bensì a quello di BasicNet.
Discorso diverso vale per BasicSamples, in quanto è una divisione interna
all’azienda e rappresenta una delle più importanti funzioni aziendali, l’idea-
zione delle collezioni e la produzione del campionario. Quindi aumentare
le unità nel modello senza particolari motivazioni potrebbe essere sbagliato
e potrebbe portare a delle conclusioni errate sui risultati della simulazione,
nascondendo un problema organizzativo dell’azienda.
Ho pertanto deciso di porre una maggiore attenzione sul funzionamento
di BasicSamples (paragrafo 6.15) e la dottoressa Bruschi mi ha informato che
6. L’AZIENDA VIRTUALE: BASIC_JES 150
Figura 6.10: Terzo esperimento. Tempodiesecuzione
Tempoprevistodallericette
i dipendenti di questa divisione sono 36. Conoscendo questo numero posso
infatti ottenere una migliore specificazione del modello e valutare con più at-
tenzione se il funzionamento di BasicSamples crea dei bottle necks all’interno
dell’azienda.
Per quanto riguarda i licenziatari, ho seguito due metodi di lavoro: in un
primo caso ho continuato ad aggiungere unità come illustrato nei precedenti
paragrafi, nel tentativo di eliminare i ritardi legati alla loro attività (paragra-
fo 6.14.1); in un secondo momento ho cambiato il mio modus operandi e ho
introdotto il tempo 0 per l’esecuzione delle ricette da parte dei licenziatari
(paragrafo 6.14.2).
6.14 Focus sui licenziatari
6.14.1 Licenziatari con tempo 1
Negli esperimenti che seguono ho raddoppiato di volta in volta il numero di
unità che nel modello rappresentano i licenziatari, con l’obiettivo di eliminare
6. L’AZIENDA VIRTUALE: BASIC_JES 151
Figura 6.11: Quarto esperimento. Tempodiesecuzione
Tempoprevistodallericette
i ritardi dovuti alla formulazione delle previsioni e degli ordini sulle collezioni.
Con una nuova simulazione ho raddoppiato il numero di unità rappre-
sentative dei licenziatari da 8 a 16, in cui 8 unità prevedono e 8 effettuano
gli ordini. I risultati evidenziano che, come ipotizzato, il ritardo nei tem-
pi di produzione mostrato in Figura 6.11 è nuovamente dimezzato rispetto
all’esperimento eseguito nel paragrafo 6.12.
In seguito ho ulteriormente aumentato il numero delle unità dei licenzia-
tari nel file unitData/unitBasicData.txt portandolo a 32, di cui 16 hanno il
compito di prevedere e le restanti effettuano gli ordini di articoli alle Trading
Company. Come si può notare nella Figura 6.12 il rapporto tra il tempo
di esecuzione e il tempo previsto per le lavorazioni si è ridotto della metà
rispetto al caso precedente (Figura 6.11).
Osservando l’andamento della simulazione, si può notare che i ‘‘picchi’’
di ritardo che si formano nel grafico della Figura 6.12 sono nei momenti in
cui BasicSamples è chiamata ad operare, in particolare:
6. L’AZIENDA VIRTUALE: BASIC_JES 152
1. all’inizio della simulazione, durante la creazione della collezione 9;
2. poco più tardi, nel momento in cui BasicSamples disegna la collezione
10;
3. prima del tick 5.000, nel momento in cui devono essere ideate contem-
poraneamente le collezioni 1, 2, 3, 4;
4. intorno al tick 7.500, quando si deve disegnare la collezione 6;
Figura 6.12: Sesto esperimento. Tempodiesecuzione
Tempoprevistodallericette
Per il resto la simulazione non accumula grandi ritardi, se non in due casi
in cui sono chiamati ad operare i licenziatari, poco prima del tick 5.000 con
la previsione delle collezioni 1, 2, 3, 4, e dopo il tick 7.500 quando devono
prevedere per la collezione numero 6.
In una nuova simulazione ho ulteriormente raddoppiato le unità dei licen-
ziatari, ma non ci sono particolari miglioramenti rispetto a quanto mostrato
in Figura 6.12, in quanto ora la maggiore fonte di ritardo è l’attività di
BasicSamples.
6. L’AZIENDA VIRTUALE: BASIC_JES 153
6.14.2 Licenziatari con tempo 0
Ho effettuato nuovi esperimenti con il modello creato in Lamieri (2002) e
Merlo (2003a) impostando i tempi di esecuzione delle ricette dei licenziatari
pari a 0. Tutti i passi a tempo 0 sono eseguiti da jES in un solo tick senza
generare code nelle liste d’attesa delle unità.
La ragione è nel fatto che ai fini della simulazione non ci interessa sapere
come operano i licenziatari al loro interno, in quanto l’importante è che essi
eseguano le previsioni e gli ordini nei tempi previsti; pertanto consideriamo
i licenziatari come ‘‘scatole nere’’.
Eseguendo una simulazione si ottiene il risultato mostrato in Figura 6.13;
i ritardi nell’esecuzione delle ricette sono dovuti soltanto a BasicSamples. È
pertanto necessaria una maggiore attenzione alla sua struttura e alla scrittura
delle ricette che la riguardano.
Figura 6.13: Licenziatari con tempo 0. Tempodiesecuzione
Tempoprevistodallericette
6. L’AZIENDA VIRTUALE: BASIC_JES 154
6.15 Approfondimento di BasicSamples
Dal momento che i ritardi nella produzione sono causati da BasicSamples,
ho deciso di ‘‘mettere la lente d’ingrandimento’’ su questa divisione.
Ho inserito nel file unitData/unitBasicData.txt 36 unità in grado di ese-
guire i passi di BasicSamples, ciascuna delle quali rappresenta un dipendente
di questa divisione nella realtà. Ho immaginato che i designers si dividano
in quattro gruppi di nove unità ciascuno e che si occupino separatamente dei
quattro tipi di collezione presenti nel modello di simulazione6.
Inoltre ho modificato i tempi delle ricette che descrivono la creazione delle
collezioni, ricalcolando i tempi di produzione secondo i dati sulla BasicNet
reale. Secondo le statistiche di BasicNet riferite al 20027, nel primo semestre
sono stati creati 3338, perciò ho supposto che nell’intero anno BasicSamples
produca 6676 articoli. In seguito ho calcolato le ore lavorative nello stesso
anno, partendo dall’ipotesi che le ore di lavoro giornaliere siano 8 e che si
lavori per 5 giorni alla settimana, dal lunedi al venerdi. Pertanto si ottiene
che:
Ore lavorative = (giorni lavorativi nel 2002 ) × (ore lavorative al giorno) =
= 260× 8 = 2080
Dopo aver calcolato le ore lavorative annuali occorre calcolare il numero
di articoli che si ipotizza siano creati da un designer nel corso di un anno,
dividendo il numero di articoli prodotti nel 2002 per il numero di dipendenti
di BasicSamples:
ArticoliPerDesigner =6676
36∼= 185
Con questi dati è possibile calcolare il numero di ore necessario ad un
designer per la creazione di un articolo nel seguente modo:6vedere paragrafo 6.57Fonte: BasicNet (2002)
6. L’AZIENDA VIRTUALE: BASIC_JES 155
h =2080
185∼= 11, 24
Perciò si può concludere che, in base a queste ipotesi molto semplicistiche,
un designer ha bisogno di 11,24 ore per creare un MetaSample o, trasforman-
dole, di 11 ore e 15 minuti circa. Traducendo le ore in minuti totali e poi
in tick della simulazione, risulta che un articolo viene creato in 675 minuti e
quindi in un numero di tick pari a:
tick =675
15= 45
dato che 1 tick = 15 minuti.
Perciò occorre riscrivere nel file recipeData/recipes.xls le ricette che de-
scrivono le lavorazioni di BasicSamples e modificare i tempi di produzione,
in modo che le unità impieghino 45 tick per lo sviluppo di ogni articolo.
Effettuando una simulazione con questo nuovo modello e mantenendo la
struttura dei licenziatari presentata nel paragrafo 6.14.2, si ottiene l’anda-
mento della simulazione mostrato in Figura 6.14. Le code legate all’atti-
vità dei licenziatari sono eliminate, pertanto i ritardi sono dovuti soltanto
all’attività di BasicSamples.
Una conclusione che si può trarre dall’analisi svolta è che BasicSamples
potrebbe rappresentare un ‘‘collo di bottiglia” nel funzionamento della Ba-
sicNet reale, dal momento che non è in grado di eseguire le operazioni nei
tempi previsti dalle ricette.
È però necessario ricordare che questi risultati hanno la base nelle as-
sunzioni fatte precedentemente, che potrebbero anche discostarsi da quanto
avviene nella realtà; infatti per eliminare i ritardi nella produzione i desi-
gners potrebbero lavorare più di 8 ore al giorno e non solo per 5 giorni alla
settimana o, ancora, potrebbero esserci articoli la cui produzione richiede un
tempo minore e altri che necessitano di tempi maggiori.
6. L’AZIENDA VIRTUALE: BASIC_JES 156
Figura 6.14: Approfondimento di Basicsamples. Tempodiesecuzione
Tempoprevistodallericette
Pertanto si può concludere che BasicSamples rappresenta un bottle neck
per BasicNet nel solo momento in cui tutte le ipotesi fatte durante la for-
mulazione del modello sono verificate anche nella realtà. In tutte le altre
situazioni sarebbe necessario specificare nuove ipotesi e considerare i nuovi
risultati della simulazione.
Da queste considerazioni si intuisce quale sia la grande importanza della
simulazione ad agenti nella formulazione delle decisioni aziendali: una volta
creato il modello dell’azienda è sufficiente cambiare alcuni particolari nella
struttura generale per poter essere in grado di valutare quali potrebbero
essere gli effetti delle scelte della direzione generale.
6.16 Analisi finale
Dopo aver costruito i tre modelli di ‘‘azienda virtuale’’ è stata fatta un’analisi
finale dei costi e dei ricavi originati dai tre esempi di Basic_jES. I dati tecnici
riferiti ad essa sono contenuti negli allegati a questa tesi.
Lo studio presentato nelle pagine che seguono è una prima analisi del
6. L’AZIENDA VIRTUALE: BASIC_JES 157
modello formalizzato e descritto nei paragrafi precedenti; l’analisi definitiva
dei tre modelli organizzativi è mostrata nell’allegato a questa tesi e contiene
le modifiche illustrate in Balla (2004). Queste modifiche sono di carattere
metodologico e riguardano il funzionamento interno di jES.
In questo modello le ricette sono eseguite indistintamente per tutti gli
articoli di una collezione perché non c’è il modo di scegliere di simulare sol-
tanto le attività riferite ai MetaSamples non abbandonati. Le modiche in
Balla (2004) consentono di eliminare questo difetto ed eseguire soltanto le
ricette riferite agli articoli che devono essere prodotti, grazie all’uso della
metodologia della ‘‘ricetta che lancia ricetta”; con questo sistema ogni volta
che deve essere svolta una fase produttiva si lancia una ricetta che controlla
lo status degli articoli e, in base ad esso, sceglie per ognuno di essi se lanciare
la ricetta.
Questa modifica comporta un importante miglioramento per il modello
dal punto di vista metodologico, ma a livello di analisi finale non dovrebbe
creare grandi cambiamenti sui costi, perché le unità di BasicNet che devono
effettuare le lavorazioni non hanno costi variabili, perciò la loro attività ri-
sulta ininfluente sul computo dei costi totali. Una variazione, anche se non
grandissima, si potrà riscontrare nel caso 2, in cui le Trading Company sono
unità interne e hanno costi variabili.
Per quanto riguarda i ricavi, l’analisi definitiva potrebbe avere alcune
differenze rispetto a questa, perché in quel caso si considereranno soltanto i
ricavi relativi agli articoli realmente venduti.
6.16.1 Caso 1
Questo modello rappresenta la BasicNet reale ricostruita al computer. I costi
imputati sono soltanto quelli relativi alle divisioni dot.com, tutti fissi con
6. L’AZIENDA VIRTUALE: BASIC_JES 158
l’esclusione di BasicSamples8, e i ricavi derivano dalla vendita dei campionari
e dalle royalties.
Per ottenere i dati relativi ai costi occorre analizzare i file della simulazione
Costs/totalDailyCosts.txt, in cui sono indicati i costi giornalieri dell’azienda,
e Costs/totalCosts.txt, dove si trova la somma cumulata dei costi giorno per
giorno.
I ricavi sono indicati nel file log/grossSales.txt. La struttura di questo
file è mostrata nella Tabella 6.5: per ogni voce sono indicati il tick della
simulazione in cui si è conseguito il ricavo e il ricavo stesso; questa struttura
risulta molto utile nel momento in cui si deve fare l’analisi di costi e ricavi,
perché grazie ad essa è possibile contabilizzare i ricavi nei giorni in cui si sono
realizzati.
tick | ricavo
Tabella 6.5: File log/grossSales
Se si osserva la Figura 6.15, si può notare che i costi crescono con un
andamento abbastanza regolare, dovuto alla forte presenza di costi fissi nelle
attività di BasicNet e al numero esiguo di unità che presentano costi varia-
bili. La curva dei ricavi cresce soltanto nei momenti in cui si consegnano i
campionari e si incassano le royalties ; in particolare, gli aumenti più grandi
si verificano intorno ai giorni 420 e 550, periodi in cui la BasicNet simulata
riceve contemporaneamente le royalties per quattro collezioni.
La Figura 6.16 mostra l’andamento dei costi e dei ricavi giorno per giorno.
I costi dal giorno 271 fino alla fine sono costanti e sono pari alla somma dei
costi fissi calcolati per ogni giorno; nei giorni precedenti i costi sono invece
incrementati dall’operatività di BasicSamples, unica divisione alla quale sono
imputati costi variabili, quando è chiamata a creare gli articoli.
8vedi paragrafo 6.9.1
6. L’AZIENDA VIRTUALE: BASIC_JES 159
Figura 6.15: Andamento di costi, ricavi e profitti totali (Caso 1)
Figura 6.16: Andamento di costi, ricavi e profitti giornalieri (Caso 1)
6. L’AZIENDA VIRTUALE: BASIC_JES 160
Le curve dei ricavi e dei profitti presentano andamenti simili e, ovviamen-
te, sono positivi nei soli giorni in cui BasicNet vende i campionari e riceve le
royalties.
I profitti totali non sono mai positivi e l’azienda chiude i due anni con
un’ingente perdita; osservando il loro andamento giornaliero, si nota che
l’azienda ottiene profitti positivi soltanto per 19 giorni della simulazione.
6.16.2 Caso 2
La BasicNet simulata in questo caso si comporta come un’azienda tradizio-
nale che produce e vende direttamente tutti i prodotti. Perciò i costi di
produzione sono rappresentati dai costi delle divisioni incrementati da quelli
relativi alle Trading Company9 e i ricavi sono calcolati in base ad un margine
di ricarico del 65%10.
I costi si ricavano nello stesso modo illustrato nel precedente paragrafo,
mentre i ricavi sono indicati nei file Revenue/dailyRevenues.txt, in cui sono
indicati i ricavi giornalieri, e Revenue/totalRevenues.txt, dove è indicata la
loro somma cumulata giorno per giorno.
L’andamento della curva dei costi totali mostrata Figura 6.17 è simile a
quella del caso precedente ma, se confrontate, si può notare che in questo
esempio la curva presenta una minore inclinazione; la causa sta nella minore
componente di costi fissi, dal momento che in questa azienda non esistono
BasicFactory e BasicBiddings.
Se si guardano soltanto i costi totali non si riesce a notare la presenza dei
costi originati dalla produzione diretta degli articoli che è più visibile nella Fi-
gura 6.18, dove la curva dei costi giornalieri ha dei ‘‘picchi” in corrispondenza
dei momenti in cui le Trading Company sono chiamate ad operare.
9vedi paragrafo 6.10.210vedi paragrafo 6.10.3
6. L’AZIENDA VIRTUALE: BASIC_JES 161
Figura 6.17: Andamento di costi, ricavi e profitti totali (Caso 2)
Figura 6.18: Andamento di costi, ricavi e profitti giornalieri (Caso 2)
6. L’AZIENDA VIRTUALE: BASIC_JES 162
Figura 6.19: Andamento di costi, ricavi e profitti totali (Caso 3)
Figura 6.20: Andamento di costi, ricavi e profitti giornalieri (Caso 3)
6. L’AZIENDA VIRTUALE: BASIC_JES 163
Dalla Figura 6.17 e dalla Figura 6.18 si nota inoltre che i ricavi crescono
di più nei primi 300 giorni per poi rimanere abbastanza stabili fino alla fine
della simulazione. La differenza con il caso 1 è motivata nella diversa origine
dei ricavi per questi due tipi di azienda; nel primo caso la BasicNet simulata,
come quella reale, contabilizza i ricavi quando vende il campionario e quando
riceve le royalties, ora invece i ricavi sono calcolati in base ad un mark-up sui
costi, perciò quando i costi sono alti lo sono anche i ricavi e viceversa, come
mostra la Figura 6.18.
In questo caso i profitti totali sono negativi, ma se si osserva l’andamen-
to dei profitti giornalieri si nota che essi risultano positivi per 51 giorni,
ottenendo un risultato migliore rispetto al caso precedente.
6.16.3 Caso 3
In questo ultimo esempio di modello organizzativo l’ipotetica BasicNet fa
produrre in outsourcing i propri prodotti e li vende direttamente al pubbli-
co. La configurazione dei costi è uguale a quella presentata nel caso della
BasicNet reale e i ricavi sono calcolati in base ad un ricarico pari al 65%11.
Se si osservano le curve dei costi e dei ricavi si può notare che questo terzo
modello organizzativo rappresenta la ‘‘miscela’’ di quelli precedenti. Infatti
nella Figura 6.19 e nella Figura 6.20 si nota che, come ipotizzato, i costi
sono uguali a quelli mostrati per il caso 1. I ricavi al contrario hanno un
andamento simile a quelli del esempio precedente.
Le differenze tra i ricavi di questa azienda e quella del caso 2 si notano
nella Figura 6.20 e sono concentrate nella seconda metà della simulazione,
probabilmente dovute alla mancanza, in questo caso, dei costi legati alla
produzione degli articoli.
L’azienda simulata chiude i due anni con una forte perdita complessiva,
11vedi paragrafo 6.10.3
6. L’AZIENDA VIRTUALE: BASIC_JES 164
come nei casi precedenti, e i profitti giornalieri risultano positivi soltanto per
30 giorni, cioè in numero minore rispetto al caso precedente.
Appendice
Si riporta il codice sorgente dei file ComputationalAssembler.java aggiornati
con le modifiche illustrate nel Capitolo 6 di questa tesi. Per ogni modello
di azienda è stata creata una classe ComputationalAssembler che contiene i
passi computazionali necessari durante la simulazione.
Caso 1
Listing 6.8: ComputationalAssembler.java Caso 1¨// ComputationalAssembler . java
import swarm . Globals ;
import swarm . de fob j . Zone ;
import swarm . ob j e c tbase . SwarmObjectImpl ;
import swarm . c o l l e c t i o n s . L i s t Impl ;
import swarm . c o l l e c t i o n s . L i s t Index ;
import swarm . random . NormalDistImpl ;
import java . lang . Float ;
import java . i o . ∗ ;
import java . u t i l . ∗ ;
/∗∗
∗ The ComputationalAssembler c lass instances make
∗ computational processes ; we have a computational assembler
∗ instance for each unit
∗
∗
∗ @author<br/>
∗ Marco Lamieri<a href="mailto : lamieri@econ . unito . i t"></a></br>
∗ Francesco Merlo<a href="mailto :merlo@econ . unito . i t"></a></br>
∗ @version 0 .9 .7 .31 . b (BasicJVE 1.0)
∗/
pub l i c c l a s s ComputationalAssembler extends ComputationalAssemblerBasic
{
//Our MemoryMatrixes
MemoryMatrix designMatrix , basicNetMatrix , tcMatrix ,
orMatrix , agentMatrix ;
165
APPENDICE 166
//A normal d i s t r i bu t ion for random numbers
NormalDistImpl normal ;
//grossSales Fi le management
pub l i c boolean grossSa lesLogFi leOpen = f a l s e ;
F i l eWr i t e r g ro s sSa l e sLog=nu l l ;
i n t samplesN=0;
f l o a t sampleSales = 0 ;
f l o a t i t emSa le s = 0 ;
pub l i c MyWriter r epor t=nu l l ;
/∗∗
∗ the constructor for ComputationalAssembler
∗/
pub l i c ComputationalAssembler ( Zone aZone , O rd e rD i s t i l l e r od , ESFrameModelSwarm mo)
{
// Call the constructor for the parent c lass .
super ( aZone , od , mo) ;
normal = new NormalDistImpl ( getZone ( ) ) ;
}
//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
// BasicJES Computational codes
//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
/∗∗ computational operations with code −1901 <br><br>
∗
∗ t h i s computational code increment 1 by 1 posi t ion 0 ,0 of
∗ the unique received matrix and set the status to done
∗/
pub l i c void c1901 ( )
{
checkMatrixes ( 1901 , 1 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
// Zeroing the counter i f empty
i f ( des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
des ignMatr ix . setValue ( layer , 0 , 0 , 0 . 0 ) ;
i n t counter = ( in t ) des ignMatr ix . getValue ( layer , 0 , 0 ) ;
counter++;
//Here we store the number of MetaSample produced
des ignMatr ix . setValue ( layer , 0 , 0 , counter ) ;
System . out . p r i n t l n ( "MetaSample␣#" + counter + "␣with␣ l ay e r␣#" + laye r
+ "␣has␣been␣drawn" ) ;
done=true ;
}// end c1901
/∗∗ computational operations with code −1902 <br><br>
∗
∗ t h i s computational code d ia l with l icensee ’ s predict ions .
∗
∗/
pub l i c void c1902 ( )
APPENDICE 167
{
checkMatrixes ( 1902 , 2 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
agentMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
l a y e r=pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
// Making predict ion for ava i lab l e MetaSample
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
//Switching to an other a r t i c l e
i n t j = getCounter ( agentMatrix , 1 ) ;
//The l icensee predict ion
i n t f o r e c a s t = ( in t ) normal . getSampleWithMean$withVariance (500 ,900000) ;
//Min value
i f ( f o r e c a s t < 10)
f o r e c a s t = 10 ;
//Max value
i f ( f o r e c a s t > 25000)
f o r e c a s t = 25000;
//Storing the predict ion
agentMatrix . setValue ( layer , 1 , j , f o r e c a s t ) ;
System . out . p r i n t l n ( " L icensee␣#" + myUnit . getUnitNumber ( ) + "␣ f o r e c a s t ed ␣"
+ f o r e c a s t + "␣ f o r ␣MetaSample␣#" + j + "␣with␣ l ay e r␣#" + laye r ) ;
// End of predict ions
done=true ;
}//Waiting for some MetaSample −> done=fa l s e
}// end c1902
/∗∗ computational operations with code −1903 <br><br>
∗
∗ t h i s computational code sums up predict ions .
∗
∗/
pub l i c void c1903 ( )
{
f l o a t sum = 0;
i n t th re sho ld = 18000;
boolean endForecast = true ;
checkMatrixes ( 1901 , 37 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
bas icNetMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 3 6 ) ;
l ay e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
// Getting the number of a r t i c l e s
i n t counter = ( in t ) des ignMatr ix . getValue ( layer , 0 , 0 ) ;
f o r ( i n t j =1 ; j <=counter ; j++)
APPENDICE 168
{
f o r ( i n t t =1 ; t <=35 ; t++)
{
MemoryMatrix agentMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( t ) ;
//Checking i f the l icensee made a predict ion for th i s MetaSample
i f ( ! ( agentMatrix . getEmpty ( layer , 1 , j ) ) )
{
sum = sum + agentMatrix . getValue ( layer , 1 , j ) ;
}
}
//Storing t o t a l predict ions in basicNet Matrix
basicNetMatr ix . setValue ( layer , 1 , j , sum ) ;
//Checking i f MetaSample can be produced
i f ( sum > thre sho ld )
{
basicNetMatr ix . setValue ( layer , 2 , j , 1 ) ;
System . out . p r i n t l n ( "MetaSample␣#" + j + "␣with␣ l ay e r␣#" + laye r +
"␣can␣be␣produced , ␣ f o r e c a s t=" + sum + "␣ s ta tu s=1" ) ;
}
e l s e
{
basicNetMatr ix . setValue ( layer , 2 , j , 0 ) ;
System . out . p r i n t l n ( "MetaSample␣#" + j + "␣with␣ l ay e r␣#" + laye r +
"␣can␣NOT␣be␣produced , ␣ f o r e c a s t=" + sum + "␣ s ta tu s=0" ) ;
}
//Waiting a l l predict ions
f o r ( i n t t =1 ; t <=35 ; t++)
{
MemoryMatrix agentMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( t ) ;
i f ( agentMatrix . getEmpty ( layer , 1 , j ) )
endForecast = f a l s e ;
}
i f ( endForecast )
{
System . out . p r i n t l n ( "MetaSample␣#" + j + "␣with␣ l ay e r␣#" + laye r
+ "␣ f o r e c a s t ed ␣by␣ a l l ␣ l i c e n s e e " ) ;
done=true ;
}
sum = 0;
}
}
// end c1903
/∗∗ computational operations with code −1904 <br><br>
∗
∗ t h i s computational code check tresho ld and i f above
∗ set 1 to row 2 matrix in pos 1 ∗ and set done=true .
∗ 1 c e l l for each number of row read in matrix in pos 0 (0 ,0) ,
∗ whit a counter in posi t ion (0 ,1)
∗/
pub l i c void c1904 ( )
{
f l o a t va l ;
APPENDICE 169
checkMatrixes ( 1904 , 2 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
bas icNetMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
//Switching to an other a r t i c l e
i n t i = getCounter ( basicNetMatrix , 1 ) ;
//check the number of items and the status
i f ( ! des ignMatr ix . getEmpty ( layer ,0 ,0 ) && ! basicNetMatr ix . getEmpty ( layer , 2 , i ) )
{
i f ( i <= designMatr ix . getValue ( layer ,0 ,0) && basicNetMatr ix . getValue ( layer , 2 , i ) == 1)
{
System . out . p r i n t l n ( "Unit␣#" + myUnit . getUnitNumber ( ) + "␣produced␣MetaSample␣#" + i
+ "␣with␣ l ay e r␣#" + laye r + " ,␣ s t a tu s=2" ) ;
bas icNetMatr ix . setValue ( layer , 2 , i , 2 ) ;
done=true ;
}
e l s e
{
System . out . p r i n t l n ( "Unit␣#" + myUnit . getUnitNumber ( ) + "␣NOT␣produced␣MetaSample␣#"
+ i + "␣with␣ l ay e r␣#" + laye r + " ,␣ s t a tu s=1" ) ;
}
}
}
// end c1904
/∗∗ computational operations with code −1905 <br><br>
∗
∗ This computational code d ia l s with TC offer−price
∗/
pub l i c void c1905 ( )
{
f l o a t o f f e rP r i c e , random ;
checkMatrixes ( 1905 , 3 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
bas icNetMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
tcMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 2 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
//Making an offer−price for ava i lab l e a r t i c l e s
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
i n t counter = ( in t ) des ignMatr ix . getValue ( layer , 0 , 0 ) ;
f o r ( i n t i =1; i<=counter ; i++)
{
i f ( ! bas icNetMatr ix . getEmpty ( layer , 2 , i ) )
APPENDICE 170
{
i f ( bas icNetMatr ix . getValue ( layer , 2 , i ) > 0)
{
//The offer−price
o f f e r P r i c e = ( in t ) normal . getSampleWithMean$withVariance ( 7 , 1 0 ) ;
//Min value
i f ( o f f e rP r i c e <1)
o f f e r P r i c e = 1 ;
//Max value
i f ( o f f e rP r i c e >20)
o f f e r P r i c e =20;
//Storing the of fer−price of the TC
tcMatrix . setValue ( layer , 1 , i , o f f e r P r i c e ) ;
System . out . p r i n t l n ( "Unit␣#" + myUnit . getUnitNumber ( )
+ "␣ o f f e r ␣ p r i c e ␣ f o r ␣MetaSample␣#" + i + "␣with␣ l ay e r␣#" + laye r + "␣ i s ␣$"
+ o f f e r P r i c e ) ;
}
e l s e
System . out . p r i n t l n ( "Unit␣#" + myUnit . getUnitNumber ( )
+ "␣can␣not␣make␣an␣ o f f e r ␣ f o r ␣Metasample␣#" + i + "␣with␣ l ay e r␣#" + laye r ) ;
}
}
done=true ;
}
// Waiting for some MetaSample −> done=fa l s e
}
// end c1905
/∗∗ computational operations with code −1906 <br><br>
∗ This computational code d ia l with the bidding phase
∗/
pub l i c void c1906 ( )
{
MemoryMatrix choiceMatr ix ;
checkMatrixes ( 1906 , 8 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
bas icNetMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 6 ) ;
orMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 7 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
// Checking MetaSamples
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
i n t counter = ( in t ) des ignMatr ix . getValue ( layer , 0 , 0 ) ;
f o r ( i n t i =1; i<=counter ; i++)
{
in t cho i c e = 0 ;
f l o a t o f f e r =0;
//Checking the status
i f ( ! bas icNetMatr ix . getEmpty ( layer , 2 , i ) )
{
APPENDICE 171
i f ( bas icNetMatr ix . getValue ( layer , 2 , i ) > 0)
{
//Here we make the bidding
f o r ( i n t t =1 ; t <=5 ; t++)
{
MemoryMatrix tcMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( t ) ;
i f ( ! tcMatrix . getEmpty ( layer , 1 , i ) )
{
i f ( tcMatrix . getValue ( layer , 1 , i ) < o f f e r | | o f f e r==0)
{
o f f e r = tcMatrix . getValue ( layer , 1 , i ) ;
cho i c e = t ;
}
}
}
//Checking the TC chosen
i f ( ! bas icNetMatr ix . getEmpty ( layer , 2 , i ) )
{
i f ( bas icNetMatr ix . getValue ( layer , 2 , i ) >0 && (!( cho i c e ==0)))
{
//Getting i t s o f f e r price . . .
choiceMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( cho i c e ) ;
f l o a t o f f e r P r i c e = choiceMatr ix . getValue ( layer , 1 , i ) ;
// . . . s toring i t in basicNet Matrix . . .
basicNetMatr ix . setValue ( layer , 3 , i , o f f e r P r i c e ) ;
// . . . and in the orMatrix
orMatrix . setValue ( layer , 1 , i , cho i c e ) ;
System . out . p r i n t l n ( "Trading␣Company␣#" + orMatrix . getValue ( layer , 1 , i ) +
"␣has␣been␣ chosen ␣ f o r ␣MetaSample␣#" + i + "␣with␣ l ay e r␣#" + laye r + "␣ p r i c e ␣"
+ basicNetMatr ix . getValue ( layer , 3 , i ) ) ;
}
}
}
}
}
done=true ;
}
// Waiting for some MetaSample −> done=fa l s e
}
// end c1906
/∗∗ computational operations with code −1907 <br><br>
∗
∗ t h i s computational code d ia l with l icensee ’ s f i r s t order .
∗
∗/
pub l i c void c1907 ( )
{
checkMatrixes ( 1907 , 3 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
agentMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
APPENDICE 172
getMemoryMatrixAddress ( 1 ) ;
bas icNetMatr ix=(MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 2 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
i n t j = getCounter ( agentMatrix , 2 ) ;
i f ( ! bas icNetMatr ix . getEmpty ( layer , 2 , j ) )
{
//Check i f the l icensee received the re la ted MetaSample
i f ( bas icNetMatr ix . getValue ( layer , 2 , j )>1)
{
in t order1 = ( in t ) normal . getSampleWithMean$withVariance (500 ,900000) ;
//Min value
i f ( order1 <10)
order1 = 10 ;
//Max value
i f ( order1 >25000)
order1 = 25000;
agentMatrix . setValue ( layer , 2 , j , order1 ) ;
i f ( bas icNetMatr ix . getEmpty ( layer , 4 , j ) )
bas icNetMatr ix . setValue ( layer , 4 , j , 0 . 0 ) ;
i n t totOrder1 = ( in t ) basicNetMatr ix . getValue ( layer , 4 , j ) + order1 ;
bas icNetMatr ix . setValue ( layer , 4 , j , totOrder1 ) ;
System . out . p r i n t l n ( "The␣1 s t ␣ order ␣ o f ␣ L icensee␣#" + myUnit . getUnitNumber ( )
+ "␣ i s ␣" + order1 + "␣ f o r ␣ item␣#" + j + "␣with␣ l ay e r␣#" + laye r + "␣ totOrder␣#"
+totOrder1 ) ;
done=true ;
}
// The a r t i c l e can not be ordered −> done=fa l s e
}
}
}
// end c1907
/∗∗ computational operations with code −1908 <br><br>
∗
∗ t h i s computational code d ia l with or branch choice .
∗
∗/
pub l i c void c1908 ( )
{
checkMatrixes ( 1908 , 3 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
bas icNetMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
orMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 2 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
APPENDICE 173
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
//Switching to another a r t i c l e
i n t i = getCounter ( orMatrix , 0 ) ;
i f ( i <= designMatr ix . getValue ( layer , 0 , 0 ) )
{
i f ( ! bas icNetMatr ix . getEmpty ( layer , 2 , i ) )
{
//Check i f the item can be produced ( status >1)
i f ( bas icNetMatr ix . getValue ( layer , 2 , i ) > 1 && ! orMatrix . getEmpty ( layer , 1 , i ) )
{
f l o a t branch = orMatrix . getValue ( layer , 1 , i ) ;
orMatrix . setValue ( layer , 1 , 0 , branch ) ;
System . out . p r i n t l n ( "Branch␣␣#" + orMatrix . getValue ( layer ,1 ,0 ) +
"␣produced␣ item␣#" + i + "␣with␣ l ay e r␣#" + laye r ) ;
bas icNetMatr ix . setValue ( layer , 2 , i , 3 . 0 ) ;
done= true ;
}
}
// The a r t i c l e can not be produced −> done=fa l s e
}
}
}
//end c1908
/∗∗ computational operations with code −1909 <br><br>
∗
∗ t h i s computational code d ia l with l icensee ’ s second order .
∗
∗/
pub l i c void c1909 ( )
{
i n t th re sho ld = 100 ;
checkMatrixes ( 1909 , 3 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
agentMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
bas icNetMatr ix=(MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 2 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
i n t j = getCounter ( agentMatrix , 3 ) ;
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
i f ( j <= designMatr ix . getValue ( layer , 0 , 0 ) )
{
//Checks i f the l icensee has already done the f i r s t order
i f ( ! agentMatrix . getEmpty ( layer , 2 , j ) )
{
i n t s e l e c t = ( in t ) normal . getSampleWithMean$withVariance (100 ,50000) ;
APPENDICE 174
//decide to do or not another order
i f ( s e l e c t > thre sho ld )
{
i n t order2 = ( in t ) normal . getSampleWithMean$withVariance (500 ,900000) ;
//Min value
i f ( order2 <10)
order2 = 10 ;
//Max value
i f ( order2 >25000)
order2 = 25000;
agentMatrix . setValue ( layer , 3 , j , order2 ) ;
i f ( bas icNetMatr ix . getEmpty ( layer , 5 , j ) )
bas icNetMatr ix . setValue ( layer , 5 , j , 0 . 0 ) ;
i n t totOrder2 = ( in t ) basicNetMatr ix . getValue ( layer , 5 , j ) + order2 ;
bas icNetMatr ix . setValue ( layer , 5 , j , totOrder2 ) ;
System . out . p r i n t l n ( "The␣2nd␣ order ␣ o f ␣ L icensee␣#" + myUnit . getUnitNumber ( )
+ "␣ i s ␣" + order2 + "␣ f o r ␣ item␣#" + j + "␣with␣ l ay e r␣#" + laye r + "␣ totOrder␣#"
+ totOrder2 ) ;
}//end i f ( s e l e c t )
e l s e
{
agentMatrix . setValue ( layer , 3 , j , 0 . 0 ) ;
i f ( bas icNetMatr ix . getEmpty ( layer , 5 , j ) )
bas icNetMatr ix . setValue ( layer , 5 , j , 0 . 0 ) ;
}//end e l se
i n t totOrder1 = ( in t ) basicNetMatr ix . getValue ( layer , 4 , j ) ;
i n t totOrder2 = ( in t ) basicNetMatr ix . getValue ( layer , 5 , j ) ;
i n t totOrder = totOrder1 + totOrder2 ;
bas icNetMatr ix . setValue ( layer , 6 , j , totOrder ) ;
}//end i f ( checking f i r s t order )
}
}
done = true ;
// The a r t i c l e can not be ordered −> done=fa l s e
}// end c1909
/∗∗ computational operations with code −1910 <br><br>
∗
∗ This computational code prints the Report and stops the simulation .
∗
∗/
APPENDICE 175
pub l i c void c1910 ( )
{
checkMatrixes ( 1910 , 2 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
bas icNetMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
t ry
{
repor t = new MyWriter ( " log / repor t . txt " ) ;
r epor t .
wr i t e ( "Layer ␣ |␣MetaSampleN ␣ |␣ Status0 ␣ |␣ Status1 ␣ |␣ Status2 ␣ |␣ Status3 ␣ |␣ Status ␣4␣␣\n" ) ;
}
catch ( IOException e )
{
System . out . p r i n t l n ( e ) ;
MyExit . e x i t ( 1 ) ;
}
f o r ( i n t ln =1; ln <=16; ln++)
{
in t metaSamplesN=0;
i n t [ ] s t a tu s ;
s t a tu s = new in t [ 5 ] ;
f o r ( i n t s =0; s <=4; s++)
s ta tu s [ s ]=0;
i f ( ! des ignMatr ix . getEmpty ( ln , 0 , 0 ) )
metaSamplesN= ( in t ) des ignMatr ix . getValue ( ln , 0 , 0 ) ;
f o r ( i n t item=1; item <=150; item++)
{
i f ( ! bas icNetMatr ix . getEmpty ( ln , 2 , item ) )
s t a tu s [ ( i n t ) basicNetMatr ix . getValue ( ln , 2 , item )]++;
}
St r ing text = ln + " ␣ |␣ " + metaSamplesN + " ␣ |␣ " + s ta tu s [ 0 ] + " ␣ |␣ " + s ta tu s [ 1 ]
+ " ␣ |␣ " + s ta tu s [ 2 ] + " ␣ |␣ " + s ta tu s [ 3 ] + " ␣ |␣ " + s ta tu s [ 4 ] + "␣\n" ;
t ry
{
repor t . wr i t e ( t ext ) ;
}
catch ( IOException e )
{
System . out . p r i n t l n ( e ) ;
MyExit . e x i t ( 1 ) ;
}
}
try
{
repor t . c l o s e ( ) ;
}
catch ( IOException e )
{
APPENDICE 176
System . out . p r i n t l n ( e ) ;
MyExit . e x i t ( 1 ) ;
}
System . out . p r i n t l n ( "∗∗∗∗∗␣THIS␣ IS␣THE␣END!␣∗∗∗∗∗ " ) ;
StartESFrame . eSFrameObserverSwarm . getContro lPanel ( ) . setStateStopped ( ) ;
done = true ;
}//end c1910
/∗∗ computational operations with code −1911 <br><br>
∗
∗ This computational code ca lcu la tes gross sa les from samples .
∗
∗/
pub l i c void c1911 ( )
{
checkMatrixes ( 1911 , 2 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
bas icNetMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
f l o a t samplePrice = ( f l o a t ) normal . getSampleWithMean$withVariance ( 3 5 , 6 ) ;
i n t counter = getCounter ( basicNetMatrix , 4 ) ;
logOpen ( true , " log / g r o s s Sa l e s . txt " ) ;
S t r ing text = Globals . env . getCurrentTime () + " ␣ |␣ " + samplePrice + "␣\n" ;
t ry
{
gros sSa l e sLog . wr i t e ( t ext ) ;
g ro s sSa l e sLog . f l u s h ( ) ;
}
catch ( IOException e )
{
System . out . p r i n t l n ( e ) ;
MyExit . e x i t ( 1 ) ;
}
done = true ;
}//end c1911
/∗∗ computational operations with code −1912 <br><br>
∗
∗ This computational code ca lcu la tes the value of roya l t i e s .
∗
∗/
pub l i c void c1912 ( )
{
checkMatrixes ( 1912 , 2 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
APPENDICE 177
basicNetMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
i n t counter = getCounter ( basicNetMatrix , 6 ) ;
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
i f ( counter <= designMatr ix . getValue ( layer , 0 , 0 ) )
{
i f ( ! bas icNetMatr ix . getEmpty ( layer , 2 , counter )
&& ! basicNetMatr ix . getEmpty ( layer , 3 , counter ) && ! basicNetMatr ix .
getEmpty ( layer , 6 , counter ) )
{
i f ( bas icNetMatr ix . getValue ( layer , 2 , counter ) > 3 .0 )
{
double i temPrice = basicNetMatr ix . getValue ( layer , 3 , counter ) ∗ 2 . 2 ;
double totRevenues = itemPrice ∗ basicNetMatr ix . getValue ( layer , 6 , counter ) ;
double i t emSa le s = ( totRevenues ∗ 0 . 1 ) ;
System . out . p r i n t l n ( " Roya l t i e s ␣ f o r ␣ item␣␣#" + counter + "␣with␣ l ay e r␣#" + laye r
+ "␣have␣been␣payed␣by␣ l i c e n s e e s " ) ;
S t r ing text = Globals . env . getCurrentTime () + " ␣ |␣ " + itemSa le s + "␣\n" ;
logOpen ( f a l s e , " log / g r o s s Sa l e s . txt " ) ;
t ry
{
gros sSa l e sLog . wr i t e ( t ext ) ;
g ro s sSa l e sLog . f l u s h ( ) ;
}
catch ( IOException e )
{
System . out . p r i n t l n ( e ) ;
MyExit . e x i t ( 1 ) ;
}
}
}
}
}
done = true ;
}//end c1912
/∗∗ computational operations with code −1913 <br><br>
∗
∗ This computational code d i s t r i bu t e s items to the l i censees .
∗
∗/
pub l i c void c1913 ( )
{
checkMatrixes ( 1913 , 3 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
bas icNetMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
APPENDICE 178
orMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 2 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
i n t counter = getCounter ( basicNetMatrix , 2 ) ;
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
i f ( counter <= designMatr ix . getValue ( layer , 0 , 0 ) )
{
//Check i f item has been produced
i f ( bas icNetMatr ix . getValue ( layer , 2 , counter ) > 2)
{
f l o a t tc = orMatrix . getValue ( layer , 1 , counter ) ;
orMatrix . setValue ( layer , 1 , 0 , tc ) ;
System . out . p r i n t l n ( " Item␣␣#" + counter + "␣with␣ l ay e r␣#" + laye r
+ "␣has␣been␣ de l i v e r ed ␣by␣Trading␣Company␣" + orMatrix . getValue ( layer , 1 , 0 ) ) ;
bas icNetMatr ix . setValue ( layer , 2 , counter , 4 . 0 ) ;
}
}
}
done = true ;
}//end c1913
//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
// Private functions
//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
//The counter i s used in some computationl code in order to take actions
// on d i f f e r en t a r t i c l e with only a recipe
pr i va t e i n t getCounter (MemoryMatrix currentMatrix , i n t row )
{
//Zeroing the counter i f empty
i f ( currentMatr ix . getEmpty ( layer , row , 0 ) )
currentMatr ix . setValue ( layer , row , 0 , 0 . 0 ) ;
//Here we increment the counter
i n t counter = ( in t ) currentMatr ix . getValue ( layer , row , 0 ) ;
counter++;
//The counter must be l e s s than the number of MetaSample
i f ( counter <= designMatr ix . getValue ( layer , 0 , 0 ) )
currentMatr ix . setValue ( layer , row , 0 , counter ) ;
r e turn counter ;
}
p r i va t e void checkMatrixes ( i n t code , i n t numberOfMatrixes )
{
i f ( pend ingComputat iona lSpec i f i ca t ionSet .
getNumberOfMemoryMatrixesToBeUsed () != numberOfMatrixes )
{
System . out . p r i n t l n ( "Code␣−"+ code + "␣ r e qu i r e s ␣" + numberOfMatrixes + "␣matrix ; ␣ "
+ pend ingComputat iona lSpec i f i ca t ionSet . getNumberOfMemoryMatrixesToBeUsed ( )
+ "␣ found␣ in ␣ order␣#␣" + pend ingComputat iona lSpec i f i ca t ionSet . getOrderNumber ( ) ) ;
APPENDICE 179
MyExit . e x i t ( 1 ) ;
}
}
p r i va t e void logOpen ( boolean e r a s eF i l e , S t r ing f i leName )
{
F i l e f i l eOut = new F i l e ( f i leName ) ;
i f ( ! t h i s . grossSa lesLogFi leOpen && e r a s eF i l e )
{
try
{
F i l eWr i t e r e ra s e = new Fi l eWr i t e r ( f i l eOut , f a l s e ) ;
e r a s e . c l o s e ( ) ;
}
catch ( IOException e )
{
System . out . p r i n t l n ( e ) ;
MyExit . e x i t ( 1 ) ;
}
}
try
{
gros sSa l e sLog = new Fi l eWr i t e r ( f i l eOut , t rue ) ;
t h i s . grossSa lesLogFi leOpen = true ;
}
catch ( IOException e )
{
System . out . p r i n t l n ( e ) ;
MyExit . e x i t ( 1 ) ;
}
}
}
§ ¦
Caso 2
Listing 6.9: ComputationalAssembler.java Caso 2¨// ComputationalAssembler . java
import swarm . Globals ;
import swarm . de fob j . Zone ;
import swarm . ob j e c tbase . SwarmObjectImpl ;
import swarm . c o l l e c t i o n s . L i s t Impl ;
import swarm . c o l l e c t i o n s . L i s t Index ;
import swarm . random . NormalDistImpl ;
import java . lang . Float ;
import java . i o . ∗ ;
import java . u t i l . ∗ ;
/∗∗
∗ The ComputationalAssembler c lass instances make
∗ computational processes ; we have a computationa assembler instance for
∗ each unit
∗
∗
∗ @author<br/>
∗ Marco Lamieri<a href="mailto : lamieri@econ . unito . i t"></a></br>
APPENDICE 180
∗ Francesco Merlo<a href="mailto :merlo@econ . unito . i t"></a></br>
∗ @version 0 .9 .7 .31 . b (BasicJVE 1.0)
∗/
pub l i c c l a s s ComputationalAssembler extends ComputationalAssemblerBasic
{
//Our MemoryMatrixes
MemoryMatrix designMatrix , basicNetMatrix , tcMatrix , orMatrix , agentMatrix ;
//A normal d i s t r i bu t ion for random numbers
NormalDistImpl normal ;
//grossSales Fi le management
pub l i c boolean grossSa lesLogFi leOpen = f a l s e ;
F i l eWr i t e r g ro s sSa l e sLog=nu l l ;
i n t samplesN=0;
f l o a t sampleSales = 0 ;
f l o a t i t emSa le s = 0 ;
pub l i c MyWriter r epor t=nu l l ;
/∗∗
∗ the constructor for ComputationalAssembler
∗/
pub l i c ComputationalAssembler ( Zone aZone , O rd e rD i s t i l l e r od , ESFrameModelSwarm mo)
{
// Call the constructor for the parent c lass .
super ( aZone , od , mo) ;
normal = new NormalDistImpl ( getZone ( ) ) ;
}
//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
// BasicJES Computational codes
//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
/∗∗ computational operations with code −1901 <br><br>
∗
∗ t h i s computational code increment 1 by 1 posi t ion 0 ,0 of the
∗ unique received matrix and set the status to done
∗/
pub l i c void c1901 ( )
{
checkMatrixes ( 1901 , 1 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
// Zeroing the counter i f empty
i f ( des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
des ignMatr ix . setValue ( layer , 0 , 0 , 0 . 0 ) ;
i n t counter = ( in t ) des ignMatr ix . getValue ( layer , 0 , 0 ) ;
counter++;
//Here we store the number of MetaSample produced
des ignMatr ix . setValue ( layer , 0 , 0 , counter ) ;
System . out . p r i n t l n ( "MetaSample␣#" + counter + "␣with␣ l ay e r␣#" + laye r
+ "␣has␣been␣drawn" ) ;
done=true ;
APPENDICE 181
}
// end c1901
/∗∗ computational operations with code −1902 <br><br>
∗
∗ t h i s computational code d ia l with l icensee ’ s predict ions .
∗
∗/
pub l i c void c1902 ( )
{
checkMatrixes ( 1902 , 2 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
agentMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
l a y e r=pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
// Making predict ion for ava i lab l e MetaSample
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
//Switching to an other a r t i c l e
i n t j = getCounter ( agentMatrix , 1 ) ;
//The l icensee predict ion
i n t f o r e c a s t = ( in t ) normal . getSampleWithMean$withVariance (500 ,900000) ;
//Min value
i f ( f o r e c a s t < 10)
f o r e c a s t = 10 ;
//Max value
i f ( f o r e c a s t > 25000)
f o r e c a s t = 25000;
//Storing the predict ion
agentMatrix . setValue ( layer , 1 , j , f o r e c a s t ) ;
System . out . p r i n t l n ( " L icensee␣#" + myUnit . getUnitNumber ( ) + "␣ f o r e c a s t ed ␣"
+ f o r e c a s t + "␣ f o r ␣MetaSample␣#" + j + "␣with␣ l ay e r␣#" + laye r ) ;
// End of predict ions
done=true ;
}
//Waiting for some MetaSample −> done=fa l s e
}
// end c1902
/∗∗ computational operations with code −1903 <br><br>
∗
∗ t h i s computational code sums up predict ions .
∗
∗/
pub l i c void c1903 ( )
{
f l o a t sum = 0;
i n t th re sho ld = 18000;
boolean endForecast = true ;
APPENDICE 182
checkMatrixes ( 1901 , 37 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
bas icNetMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 3 6 ) ;
l ay e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
// Getting the number of a r t i c l e s
i n t counter = ( in t ) des ignMatr ix . getValue ( layer , 0 , 0 ) ;
f o r ( i n t j =1 ; j <=counter ; j++)
{
f o r ( i n t t =1 ; t <=35 ; t++)
{
MemoryMatrix agentMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( t ) ;
//Checking i f the l icensee made a predict ion for th i s MetaSample
i f ( ! ( agentMatrix . getEmpty ( layer , 1 , j ) ) )
{
sum = sum + agentMatrix . getValue ( layer , 1 , j ) ;
}
}
//Storing t o t a l predict ions in basicNet Matrix
basicNetMatr ix . setValue ( layer , 1 , j , sum ) ;
//Checking i f MetaSample can be produced
i f ( sum > thre sho ld )
{
basicNetMatr ix . setValue ( layer , 2 , j , 1 ) ;
System . out . p r i n t l n ( "MetaSample␣#" + j + "␣with␣ l ay e r␣#" + laye r +
"␣can␣be␣produced , ␣ f o r e c a s t=" + sum + "␣ s ta tu s=1" ) ;
}
e l s e
{
basicNetMatr ix . setValue ( layer , 2 , j , 0 ) ;
System . out . p r i n t l n ( "MetaSample␣#" + j + "␣with␣ l ay e r␣#" + laye r
+ "␣can␣NOT␣be␣produced , ␣ f o r e c a s t=" + sum + "␣ s ta tu s=0" ) ;
}
//Waiting a l l predict ions
f o r ( i n t t =1 ; t <=35 ; t++)
{
MemoryMatrix agentMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( t ) ;
i f ( agentMatrix . getEmpty ( layer , 1 , j ) )
endForecast = f a l s e ;
}
i f ( endForecast )
{
System . out . p r i n t l n ( "MetaSample␣#" + j + "␣with␣ l ay e r␣#" + laye r
+ "␣ f o r e c a s t ed ␣by␣ a l l ␣ l i c e n s e e " ) ;
done=true ;
}
sum = 0;
}
}
// end c1903
APPENDICE 183
/∗∗ computational operations with code −1904 <br><br>
∗
∗ t h i s computational code check tresho ld and i f above
∗ set 1 to row 2 matrix in pos 1 ∗ and set done=true .
∗ 1 c e l l for each number of row read in matrix in pos 0 (0 ,0) ,
∗ whit a counter in posi t ion (0 ,1)
∗/
pub l i c void c1904 ( )
{
f l o a t va l ;
checkMatrixes ( 1904 , 2 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
bas icNetMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
//Switching to an other a r t i c l e
i n t i = getCounter ( basicNetMatrix , 1 ) ;
//check the number of items and the status
i f ( ! des ignMatr ix . getEmpty ( layer ,0 ,0 ) && ! basicNetMatr ix . getEmpty ( layer , 2 , i ) )
{
i f ( i <= designMatr ix . getValue ( layer ,0 ,0) && basicNetMatr ix . getValue ( layer , 2 , i ) == 1)
{
System . out . p r i n t l n ( "Unit␣#" + myUnit . getUnitNumber ( ) + "␣produced␣MetaSample␣#" + i
+ "␣with␣ l ay e r␣#" + laye r + " ,␣ s t a tu s=2" ) ;
bas icNetMatr ix . setValue ( layer , 2 , i , 2 ) ;
done=true ;
}
e l s e
{
System . out . p r i n t l n ( "Unit␣#" + myUnit . getUnitNumber ( ) + "␣NOT␣produced␣MetaSample␣#"
+ i + "␣with␣ l ay e r␣#" + laye r + " ,␣ s t a tu s=1" ) ;
}
}
}
// end c1904
/∗∗ computational operations with code −1907 <br><br>
∗
∗ t h i s computational code d ia l with l icensee ’ s f i r s t order .
∗
∗/
pub l i c void c1907 ( )
{
checkMatrixes ( 1907 , 3 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
agentMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
bas icNetMatr ix=(MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
APPENDICE 184
getMemoryMatrixAddress ( 2 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
i n t j = getCounter ( agentMatrix , 2 ) ;
i f ( ! bas icNetMatr ix . getEmpty ( layer , 2 , j ) )
{
//Check i f the l icensee received the re la ted MetaSample
i f ( bas icNetMatr ix . getValue ( layer , 2 , j )>1)
{
in t order1 = ( in t ) normal . getSampleWithMean$withVariance (500 ,900000) ;
//Min value
i f ( order1 <10)
order1 = 10 ;
//Max value
i f ( order1 >25000)
order1 = 25000;
agentMatrix . setValue ( layer , 2 , j , order1 ) ;
i f ( bas icNetMatr ix . getEmpty ( layer , 4 , j ) )
bas icNetMatr ix . setValue ( layer , 4 , j , 0 . 0 ) ;
i n t totOrder1 = ( in t ) basicNetMatr ix . getValue ( layer , 4 , j ) + order1 ;
bas icNetMatr ix . setValue ( layer , 4 , j , totOrder1 ) ;
System . out . p r i n t l n ( "The␣1 s t ␣ order ␣ o f ␣ L icensee␣#" + myUnit . getUnitNumber ( )
+ "␣ i s ␣" + order1 + "␣ f o r ␣ item␣#" + j + "␣with␣ l ay e r␣#" + laye r
+ "␣ totOrder␣#"+ totOrder1 ) ;
done=true ;
}
// The a r t i c l e can not be ordered −> done=fa l s e
}
}
}
// end c1907
/∗∗ computational operations with code −1909 <br><br>
∗
∗ t h i s computational code d ia l with l icensee ’ s second order .
∗
∗/
pub l i c void c1909 ( )
{
i n t th re sho ld = 100 ;
checkMatrixes ( 1909 , 3 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
agentMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
bas icNetMatr ix=(MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 2 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
APPENDICE 185
i n t j = getCounter ( agentMatrix , 3 ) ;
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
i f ( j <= designMatr ix . getValue ( layer , 0 , 0 ) )
{
//Checks i f the l icensee has already done the f i r s t order
i f ( ! agentMatrix . getEmpty ( layer , 2 , j ) )
{
i n t s e l e c t = ( in t ) normal . getSampleWithMean$withVariance (100 ,50000) ;
//decide to do or not another order
i f ( s e l e c t > thre sho ld )
{
i n t order2 = ( in t ) normal . getSampleWithMean$withVariance (500 ,900000) ;
//Min value
i f ( order2 <10)
order2 = 10 ;
//Max value
i f ( order2 >25000)
order2 = 25000;
agentMatrix . setValue ( layer , 3 , j , order2 ) ;
i f ( bas icNetMatr ix . getEmpty ( layer , 5 , j ) )
bas icNetMatr ix . setValue ( layer , 5 , j , 0 . 0 ) ;
i n t totOrder2 = ( in t ) basicNetMatr ix . getValue ( layer , 5 , j ) + order2 ;
bas icNetMatr ix . setValue ( layer , 5 , j , totOrder2 ) ;
System . out . p r i n t l n ( "The␣2nd␣ order ␣ o f ␣ L icensee␣#" + myUnit . getUnitNumber ( )
+ "␣ i s ␣" + order2 + "␣ f o r ␣ item␣#" + j + "␣with␣ l ay e r␣#" + laye r + "␣ totOrder␣#"
+ totOrder2 ) ;
}//end i f ( s e l e c t )
e l s e
{
agentMatrix . setValue ( layer , 3 , j , 0 . 0 ) ;
i f ( bas icNetMatr ix . getEmpty ( layer , 5 , j ) )
bas icNetMatr ix . setValue ( layer , 5 , j , 0 . 0 ) ;
}//end
i n t totOrder1 = ( in t ) basicNetMatr ix . getValue ( layer , 4 , j ) ;
i n t totOrder2 = ( in t ) basicNetMatr ix . getValue ( layer , 5 , j ) ;
i n t totOrder = totOrder1 + totOrder2 ;
bas icNetMatr ix . setValue ( layer , 6 , j , totOrder ) ;
}//end i f ( checking f i r s t order )
}
}
done = true ;
// The a r t i c l e can not be ordered −> done=fa l s e
APPENDICE 186
}// end c1909
/∗∗ computational operations with code −1910 <br><br>
∗
∗ This computational code prints the Report and stops the simulation .
∗
∗/
pub l i c void c1910 ( )
{
checkMatrixes ( 1910 , 2 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
bas icNetMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
t ry
{
repor t = new MyWriter ( " log / repor t . txt " ) ;
r epor t .
wr i t e ( "Layer ␣ |␣MetaSampleN ␣ |␣ Status0 ␣ |␣ Status1 ␣ |␣ Status2 ␣ |␣ Status3 ␣ |␣ Status ␣4␣␣␣\n" ) ;
}
catch ( IOException e )
{
System . out . p r i n t l n ( e ) ;
MyExit . e x i t ( 1 ) ;
}
f o r ( i n t ln =1; ln <=16; ln++)
{
in t metaSamplesN=0;
i n t [ ] s t a tu s ;
s t a tu s = new in t [ 5 ] ;
f o r ( i n t s =0; s <=4; s++)
s ta tu s [ s ]=0;
i f ( ! des ignMatr ix . getEmpty ( ln , 0 , 0 ) )
metaSamplesN= ( in t ) des ignMatr ix . getValue ( ln , 0 , 0 ) ;
f o r ( i n t item=1; item <=150; item++)
{
i f ( ! bas icNetMatr ix . getEmpty ( ln , 2 , item ) )
s t a tu s [ ( i n t ) basicNetMatr ix . getValue ( ln , 2 , item )]++;
}
St r ing text = ln + " ␣ |␣ " + metaSamplesN + " ␣ |␣ " + s ta tu s [ 0 ] + " ␣ |␣ " + s ta tu s [ 1 ]
+ " ␣ |␣ " + s ta tu s [ 2 ] + " ␣ |␣ " + s ta tu s [ 3 ] + " ␣ |␣ " + s ta tu s [ 4 ] + "␣\n" ;
t ry
{
repor t . wr i t e ( t ext ) ;
}
catch ( IOException e )
{
System . out . p r i n t l n ( e ) ;
MyExit . e x i t ( 1 ) ;
APPENDICE 187
}
}
try
{
repor t . c l o s e ( ) ;
}
catch ( IOException e )
{
System . out . p r i n t l n ( e ) ;
MyExit . e x i t ( 1 ) ;
}
System . out . p r i n t l n ( "∗∗∗∗∗␣THIS␣ IS␣THE␣END!␣∗∗∗∗∗ " ) ;
StartESFrame . eSFrameObserverSwarm . getContro lPanel ( ) . setStateStopped ( ) ;
done = true ;
}//end c1910
/∗∗ computational operations with code −1913 <br><br>
∗
∗ This computational code d i s t r i bu t e s items to the l i censees .
∗
∗/
pub l i c void c1913 ( )
{
checkMatrixes ( 1913 , 2 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
bas icNetMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
i n t counter = getCounter ( basicNetMatrix , 2 ) ;
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
i f ( counter <= designMatr ix . getValue ( layer , 0 , 0 ) )
{
//Check i f item has been produced
i f ( bas icNetMatr ix . getValue ( layer , 2 , counter ) > 2)
{
System . out . p r i n t l n ( " Item␣␣#" + counter + "␣with␣ l ay e r␣#" + laye r
+ "␣has␣been␣ de l i v e r ed " ) ;
bas icNetMatr ix . setValue ( layer , 2 , counter , 4 . 0 ) ;
}
}
}
done = true ;
}//end c1913
//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
// Private functions
//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
APPENDICE 188
//The counter i s used in some computationl code in order to take actions
// on d i f f e r en t a r t i c l e with only a recipe
pr i va t e i n t getCounter (MemoryMatrix currentMatrix , i n t row )
{
//Zeroing the counter i f empty
i f ( currentMatr ix . getEmpty ( layer , row , 0 ) )
currentMatr ix . setValue ( layer , row , 0 , 0 . 0 ) ;
//Here we increment the counter
i n t counter = ( in t ) currentMatr ix . getValue ( layer , row , 0 ) ;
counter++;
//The counter must be l e s s than the number of MetaSample
i f ( counter <= designMatr ix . getValue ( layer , 0 , 0 ) )
currentMatr ix . setValue ( layer , row , 0 , counter ) ;
r e turn counter ;
}
p r i va t e void checkMatrixes ( i n t code , i n t numberOfMatrixes )
{
i f ( pend ingComputat iona lSpec i f i ca t ionSet .
getNumberOfMemoryMatrixesToBeUsed () != numberOfMatrixes )
{
System . out . p r i n t l n ( "Code␣−"+ code + "␣ r e qu i r e s ␣" + numberOfMatrixes + "␣matrix ; ␣ "
+ pend ingComputat iona lSpec i f i ca t ionSet . getNumberOfMemoryMatrixesToBeUsed ( )
+ "␣ found␣ in ␣ order␣#␣" + pend ingComputat iona lSpec i f i ca t ionSet . getOrderNumber ( ) ) ;
MyExit . e x i t ( 1 ) ;
}
}
p r i va t e void logOpen ( boolean e r a s eF i l e , S t r ing f i leName )
{
F i l e f i l eOut = new F i l e ( f i leName ) ;
i f ( ! t h i s . grossSa lesLogFi leOpen && e r a s eF i l e )
{
try
{
F i l eWr i t e r e ra s e = new Fi l eWr i t e r ( f i l eOut , f a l s e ) ;
e r a s e . c l o s e ( ) ;
}
catch ( IOException e )
{
System . out . p r i n t l n ( e ) ;
MyExit . e x i t ( 1 ) ;
}
}
try
{
gros sSa l e sLog = new Fi l eWr i t e r ( f i l eOut , t rue ) ;
t h i s . grossSa lesLogFi leOpen = true ;
}
catch ( IOException e )
{
System . out . p r i n t l n ( e ) ;
MyExit . e x i t ( 1 ) ;
}
}
}
§ ¦
APPENDICE 189
Caso 3
Listing 6.10: ComputationalAssembler.java Caso 3¨// ComputationalAssembler . java
import swarm . Globals ;
import swarm . de fob j . Zone ;
import swarm . ob j e c tbase . SwarmObjectImpl ;
import swarm . c o l l e c t i o n s . L i s t Impl ;
import swarm . c o l l e c t i o n s . L i s t Index ;
import swarm . random . NormalDistImpl ;
import java . lang . Float ;
import java . i o . ∗ ;
import java . u t i l . ∗ ;
/∗∗
∗ The ComputationalAssembler c lass instances make
∗ computational processes ; we have a computationa assembler instance for
∗ each unit
∗
∗
∗ @author<br/>
∗ Marco Lamieri<a href="mailto : lamieri@econ . unito . i t"></a></br>
∗ Francesco Merlo<a href="mailto :merlo@econ . unito . i t"></a></br>
∗ @version 0 .9 .7 .31 . b (BasicJVE 1.0)
∗/
pub l i c c l a s s ComputationalAssembler extends ComputationalAssemblerBasic
{
//Our MemoryMatrixes
MemoryMatrix designMatrix , basicNetMatrix , tcMatrix , orMatrix , agentMatrix ;
//A normal d i s t r i bu t ion for random numbers
NormalDistImpl normal ;
//grossSales Fi le management
pub l i c boolean grossSa lesLogFi leOpen = f a l s e ;
F i l eWr i t e r g ro s sSa l e sLog=nu l l ;
i n t samplesN=0;
f l o a t sampleSales = 0 ;
f l o a t i t emSa le s = 0 ;
pub l i c MyWriter r epor t=nu l l ;
/∗∗
∗ the constructor for ComputationalAssembler
∗/
pub l i c ComputationalAssembler ( Zone aZone , O rd e rD i s t i l l e r od , ESFrameModelSwarm mo)
{
// Call the constructor for the parent c lass .
super ( aZone , od , mo) ;
normal = new NormalDistImpl ( getZone ( ) ) ;
}
//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
// BasicJES Computational codes
//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
/∗∗ computational operations with code −1901 <br><br>
∗
∗ t h i s computational code increment 1 by 1 posi t ion 0 ,0 of the
∗ unique received matrix and set the status to done
APPENDICE 190
∗/
pub l i c void c1901 ( )
{
checkMatrixes ( 1901 , 1 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
// Zeroing the counter i f empty
i f ( des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
des ignMatr ix . setValue ( layer , 0 , 0 , 0 . 0 ) ;
i n t counter = ( in t ) des ignMatr ix . getValue ( layer , 0 , 0 ) ;
counter++;
//Here we store the number of MetaSample produced
des ignMatr ix . setValue ( layer , 0 , 0 , counter ) ;
System . out . p r i n t l n ( "MetaSample␣#" + counter + "␣with␣ l ay e r␣#" + laye r
+ "␣has␣been␣drawn" ) ;
done=true ;
}
// end c1901
/∗∗ computational operations with code −1902 <br><br>
∗
∗ t h i s computational code d ia l with l icensee ’ s predict ions .
∗
∗/
pub l i c void c1902 ( )
{
checkMatrixes ( 1902 , 2 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
agentMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
l a y e r=pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
// Making predict ion for ava i lab l e MetaSample
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
//Switching to an other a r t i c l e
i n t j = getCounter ( agentMatrix , 1 ) ;
//The l icensee predict ion
i n t f o r e c a s t = ( in t ) normal . getSampleWithMean$withVariance (500 ,900000) ;
//Min value
i f ( f o r e c a s t < 10)
f o r e c a s t = 10 ;
//Max value
i f ( f o r e c a s t > 25000)
f o r e c a s t = 25000;
//Storing the predict ion
APPENDICE 191
agentMatrix . setValue ( layer , 1 , j , f o r e c a s t ) ;
System . out . p r i n t l n ( " L icensee␣#" + myUnit . getUnitNumber ( ) + "␣ f o r e c a s t ed ␣" + f o r e c a s t
+ "␣ f o r ␣MetaSample␣#" + j + "␣with␣ l ay e r␣#" + laye r ) ;
// End of predict ions
done=true ;
}
//Waiting for some MetaSample −> done=fa l s e
}
// end c1902
/∗∗ computational operations with code −1903 <br><br>
∗
∗ t h i s computational code sums up predict ions .
∗
∗/
pub l i c void c1903 ( )
{
f l o a t sum = 0;
i n t th re sho ld = 18000;
boolean endForecast = true ;
checkMatrixes ( 1901 , 37 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
bas icNetMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 3 6 ) ;
l ay e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
// Getting the number of a r t i c l e s
i n t counter = ( in t ) des ignMatr ix . getValue ( layer , 0 , 0 ) ;
f o r ( i n t j =1 ; j <=counter ; j++)
{
f o r ( i n t t =1 ; t <=35 ; t++)
{
MemoryMatrix agentMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( t ) ;
//Checking i f the l icensee made a predict ion for th i s MetaSample
i f ( ! ( agentMatrix . getEmpty ( layer , 1 , j ) ) )
{
sum = sum + agentMatrix . getValue ( layer , 1 , j ) ;
}
}
//Storing t o t a l predict ions in basicNet Matrix
basicNetMatr ix . setValue ( layer , 1 , j , sum ) ;
//Checking i f MetaSample can be produced
i f ( sum > thre sho ld )
{
basicNetMatr ix . setValue ( layer , 2 , j , 1 ) ;
System . out . p r i n t l n ( "MetaSample␣#" + j + "␣with␣ l ay e r␣#" + laye r
+ "␣can␣be␣produced , ␣ f o r e c a s t=" + sum + "␣ s ta tu s=1" ) ;
}
e l s e
{
basicNetMatr ix . setValue ( layer , 2 , j , 0 ) ;
APPENDICE 192
System . out . p r i n t l n ( "MetaSample␣#" + j + "␣with␣ l ay e r␣#" + laye r
+ "␣can␣NOT␣be␣produced , ␣ f o r e c a s t=" + sum + "␣ s ta tu s=0" ) ;
}
//Waiting a l l predict ions
f o r ( i n t t =1 ; t <=35 ; t++)
{
MemoryMatrix agentMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( t ) ;
i f ( agentMatrix . getEmpty ( layer , 1 , j ) )
endForecast = f a l s e ;
}
i f ( endForecast )
{
System . out . p r i n t l n ( "MetaSample␣#" + j + "␣with␣ l ay e r␣#" + laye r
+ "␣ f o r e c a s t ed ␣by␣ a l l ␣ l i c e n s e e " ) ;
done=true ;
}
sum = 0;
}
}
// end c1903
/∗∗ computational operations with code −1904 <br><br>
∗
∗ t h i s computational code check tresho ld and i f above
∗ set 1 to row 2 matrix in pos 1 ∗ and set done=true .
∗ 1 c e l l for each number of row read in matrix in pos 0 (0 ,0) ,
∗ whit a counter in posi t ion (0 ,1)
∗/
pub l i c void c1904 ( )
{
f l o a t va l ;
checkMatrixes ( 1904 , 2 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
bas icNetMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
//Switching to an other a r t i c l e
i n t i = getCounter ( basicNetMatrix , 1 ) ;
//check the number of items and the status
i f ( ! des ignMatr ix . getEmpty ( layer ,0 ,0 ) && ! basicNetMatr ix . getEmpty ( layer , 2 , i ) )
{
i f ( i <= designMatr ix . getValue ( layer ,0 ,0) && basicNetMatr ix . getValue ( layer , 2 , i ) == 1)
{
System . out . p r i n t l n ( "Unit␣#" + myUnit . getUnitNumber ( ) + "␣produced␣MetaSample␣#"
+ i + "␣with␣ l ay e r␣#" + laye r + " ,␣ s t a tu s=2" ) ;
bas icNetMatr ix . setValue ( layer , 2 , i , 2 ) ;
done=true ;
}
APPENDICE 193
e l s e
{
System . out . p r i n t l n ( "Unit␣#" + myUnit . getUnitNumber ( ) + "␣NOT␣produced␣MetaSample␣#"
+ i + "␣with␣ l ay e r␣#" + laye r + " ,␣ s t a tu s=1" ) ;
}
}
}
// end c1904
/∗∗ computational operations with code −1905 <br><br>
∗
∗ This computational code d ia l s with TC offer−price
∗/
pub l i c void c1905 ( )
{
f l o a t o f f e rP r i c e , random ;
checkMatrixes ( 1905 , 3 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
bas icNetMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
tcMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 2 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
//Making an offer−price for ava i lab l e a r t i c l e s
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
i n t counter = ( in t ) des ignMatr ix . getValue ( layer , 0 , 0 ) ;
f o r ( i n t i =1; i<=counter ; i++)
{
i f ( ! bas icNetMatr ix . getEmpty ( layer , 2 , i ) )
{
i f ( bas icNetMatr ix . getValue ( layer , 2 , i ) > 0)
{
//The offer−price
o f f e r P r i c e = ( in t ) normal . getSampleWithMean$withVariance ( 7 , 1 0 ) ;
//Min value
i f ( o f f e rP r i c e <1)
o f f e r P r i c e = 1 ;
//Max value
i f ( o f f e rP r i c e >20)
o f f e r P r i c e =20;
//Storing the of fer−price of the TC
tcMatrix . setValue ( layer , 1 , i , o f f e r P r i c e ) ;
System . out . p r i n t l n ( "Unit␣#" + myUnit . getUnitNumber ( )
+ "␣ o f f e r ␣ p r i c e ␣ f o r ␣MetaSample␣#" + i + "␣with␣ l ay e r␣#" + laye r + "␣ i s ␣$"
+ o f f e r P r i c e ) ;
}
e l s e
System . out . p r i n t l n ( "Unit␣#" + myUnit . getUnitNumber ( )
+ "␣can␣not␣make␣an␣ o f f e r ␣ f o r ␣Metasample␣#" + i + "␣with␣ l ay e r␣#" + laye r ) ;
}
}
APPENDICE 194
done=true ;
}
// Waiting for some MetaSample −> done=fa l s e
}
// end c1905
/∗∗ computational operations with code −1906 <br><br>
∗ This computational code d ia l with the bidding phase
∗/
pub l i c void c1906 ( )
{
MemoryMatrix choiceMatr ix ;
checkMatrixes ( 1906 , 8 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
bas icNetMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 6 ) ;
orMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 7 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
// Checking MetaSamples
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
i n t counter = ( in t ) des ignMatr ix . getValue ( layer , 0 , 0 ) ;
f o r ( i n t i =1; i<=counter ; i++)
{
in t cho i c e = 0 ;
f l o a t o f f e r =0;
//Checking the status
i f ( ! bas icNetMatr ix . getEmpty ( layer , 2 , i ) )
{
i f ( bas icNetMatr ix . getValue ( layer , 2 , i ) > 0)
{
//Here we make the bidding
f o r ( i n t t =1 ; t <=5 ; t++)
{
MemoryMatrix tcMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( t ) ;
i f ( ! tcMatrix . getEmpty ( layer , 1 , i ) )
{
i f ( tcMatrix . getValue ( layer , 1 , i ) < o f f e r | | o f f e r==0)
{
o f f e r = tcMatrix . getValue ( layer , 1 , i ) ;
cho i c e = t ;
}
}
}
//Checking the TC chosen
i f ( ! bas icNetMatr ix . getEmpty ( layer , 2 , i ) )
{
i f ( bas icNetMatr ix . getValue ( layer , 2 , i ) >0 && (!( cho i c e ==0)))
{
//Getting i t s o f f e r price . . .
APPENDICE 195
choiceMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( cho i c e ) ;
f l o a t o f f e r P r i c e = choiceMatr ix . getValue ( layer , 1 , i ) ;
// . . . s toring i t in basicNet Matrix . . .
basicNetMatr ix . setValue ( layer , 3 , i , o f f e r P r i c e ) ;
// . . . and in the orMatrix
orMatrix . setValue ( layer , 1 , i , cho i c e ) ;
System . out . p r i n t l n ( "Trading␣Company␣#" + orMatrix . getValue ( layer , 1 , i )
+ "␣has␣been␣ chosen ␣ f o r ␣MetaSample␣#" + i + "␣with␣ l ay e r␣#" + laye r + "␣ p r i c e ␣"
+ basicNetMatr ix . getValue ( layer , 3 , i ) ) ;
}
}
}
}
}
done=true ;
}
// Waiting for some MetaSample −> done=fa l s e
}
// end c1906
/∗∗ computational operations with code −1907 <br><br>
∗
∗ t h i s computational code d ia l with l icensee ’ s f i r s t order .
∗
∗/
pub l i c void c1907 ( )
{
checkMatrixes ( 1907 , 3 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
agentMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
bas icNetMatr ix=(MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 2 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
i n t j = getCounter ( agentMatrix , 2 ) ;
i f ( ! bas icNetMatr ix . getEmpty ( layer , 2 , j ) )
{
//Check i f the l icensee received the re la ted MetaSample
i f ( bas icNetMatr ix . getValue ( layer , 2 , j )>1)
{
in t order1 = ( in t ) normal . getSampleWithMean$withVariance (500 ,900000) ;
//Min value
i f ( order1 <10)
order1 = 10 ;
//Max value
i f ( order1 >25000)
order1 = 25000;
agentMatrix . setValue ( layer , 2 , j , order1 ) ;
APPENDICE 196
i f ( bas icNetMatr ix . getEmpty ( layer , 4 , j ) )
bas icNetMatr ix . setValue ( layer , 4 , j , 0 . 0 ) ;
i n t totOrder1 = ( in t ) basicNetMatr ix . getValue ( layer , 4 , j ) + order1 ;
bas icNetMatr ix . setValue ( layer , 4 , j , totOrder1 ) ;
System . out . p r i n t l n ( "The␣1 s t ␣ order ␣ o f ␣ L icensee␣#" + myUnit . getUnitNumber ( ) + "␣ i s ␣"
+ order1 + "␣ f o r ␣ item␣#" + j + "␣with␣ l ay e r␣#" + laye r + "␣ totOrder␣#"+totOrder1 ) ;
done=true ;
}
// The a r t i c l e can not be ordered −> done=fa l s e
}
}
}
// end c1907
/∗∗ computational operations with code −1908 <br><br>
∗
∗ t h i s computational code d ia l with or branch choice .
∗
∗/
pub l i c void c1908 ( )
{
checkMatrixes ( 1908 , 3 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
bas icNetMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
orMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 2 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
//Switching to another a r t i c l e
i n t i = getCounter ( orMatrix , 0 ) ;
i f ( i <= designMatr ix . getValue ( layer , 0 , 0 ) )
{
i f ( ! bas icNetMatr ix . getEmpty ( layer , 2 , i ) )
{
//Check i f the item can be produced ( status >1)
i f ( bas icNetMatr ix . getValue ( layer , 2 , i ) > 1 && ! orMatrix . getEmpty ( layer , 1 , i ) )
{
f l o a t branch = orMatrix . getValue ( layer , 1 , i ) ;
orMatrix . setValue ( layer , 1 , 0 , branch ) ;
System . out . p r i n t l n ( "Branch␣␣#" + orMatrix . getValue ( layer , 1 , 0 )
+ "␣produced␣ item␣#" + i + "␣with␣ l ay e r␣#" + laye r ) ;
bas icNetMatr ix . setValue ( layer , 2 , i , 3 . 0 ) ;
done= true ;
}
}
// The a r t i c l e can not be produced −> done=fa l s e
APPENDICE 197
}
}
}
//end c1908
/∗∗ computational operations with code −1909 <br><br>
∗
∗ t h i s computational code d ia l with l icensee ’ s second order .
∗
∗/
pub l i c void c1909 ( )
{
i n t th re sho ld = 100 ;
checkMatrixes ( 1909 , 3 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
agentMatrix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
bas icNetMatr ix=(MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 2 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
i n t j = getCounter ( agentMatrix , 3 ) ;
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
i f ( j <= designMatr ix . getValue ( layer , 0 , 0 ) )
{
//Checks i f the l icensee has already done the f i r s t order
i f ( ! agentMatrix . getEmpty ( layer , 2 , j ) )
{
i n t s e l e c t = ( in t ) normal . getSampleWithMean$withVariance (100 ,50000) ;
//decide to do or not another order
i f ( s e l e c t > thre sho ld )
{
i n t order2 = ( in t ) normal . getSampleWithMean$withVariance (500 ,900000) ;
//Min value
i f ( order2 <10)
order2 = 10 ;
//Max value
i f ( order2 >25000)
order2 = 25000;
agentMatrix . setValue ( layer , 3 , j , order2 ) ;
i f ( bas icNetMatr ix . getEmpty ( layer , 5 , j ) )
bas icNetMatr ix . setValue ( layer , 5 , j , 0 . 0 ) ;
i n t totOrder2 = ( in t ) basicNetMatr ix . getValue ( layer , 5 , j ) + order2 ;
bas icNetMatr ix . setValue ( layer , 5 , j , totOrder2 ) ;
System . out . p r i n t l n ( "The␣2nd␣ order ␣ o f ␣ L icensee␣#" + myUnit . getUnitNumber ( )
APPENDICE 198
+ "␣ i s ␣" + order2 + "␣ f o r ␣ item␣#" + j + "␣with␣ l ay e r␣#" + laye r + "␣ totOrder␣#"
+ totOrder2 ) ;
}//end i f ( s e l e c t )
e l s e
{
agentMatrix . setValue ( layer , 3 , j , 0 . 0 ) ;
i f ( bas icNetMatr ix . getEmpty ( layer , 5 , j ) )
bas icNetMatr ix . setValue ( layer , 5 , j , 0 . 0 ) ;
}//end e l se
i n t totOrder1 = ( in t ) basicNetMatr ix . getValue ( layer , 4 , j ) ;
i n t totOrder2 = ( in t ) basicNetMatr ix . getValue ( layer , 5 , j ) ;
i n t totOrder = totOrder1 + totOrder2 ;
bas icNetMatr ix . setValue ( layer , 6 , j , totOrder ) ;
}//end i f ( checking f i r s t order )
}
}
done = true ;
// The a r t i c l e can not be ordered −> done=fa l s e
}// end c1909
/∗∗ computational operations with code −1910 <br><br>
∗
∗ This computational code prints the Report and stops the simulation .
∗
∗/
pub l i c void c1910 ( )
{
checkMatrixes ( 1910 , 2 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
bas icNetMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 1 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
t ry
{
repor t = new MyWriter ( " log / repor t . txt " ) ;
r epor t .
wr i t e ( "Layer ␣ |␣MetaSampleN ␣ |␣ Status0 ␣ |␣ Status1 ␣ |␣ Status2 ␣ |␣ Status3 ␣ |␣ Status ␣4␣␣\n" ) ;
}
catch ( IOException e )
{
System . out . p r i n t l n ( e ) ;
MyExit . e x i t ( 1 ) ;
}
f o r ( i n t ln =1; ln <=16; ln++)
{
APPENDICE 199
i n t metaSamplesN=0;
i n t [ ] s t a tu s ;
s t a tu s = new in t [ 5 ] ;
f o r ( i n t s =0; s <=4; s++)
s ta tu s [ s ]=0;
i f ( ! des ignMatr ix . getEmpty ( ln , 0 , 0 ) )
metaSamplesN= ( in t ) des ignMatr ix . getValue ( ln , 0 , 0 ) ;
f o r ( i n t item=1; item <=150; item++)
{
i f ( ! bas icNetMatr ix . getEmpty ( ln , 2 , item ) )
s t a tu s [ ( i n t ) basicNetMatr ix . getValue ( ln , 2 , item )]++;
}
St r ing text = ln + " ␣ |␣ " + metaSamplesN + " ␣ |␣ " + s ta tu s [ 0 ] + " ␣ |␣ " + s ta tu s [ 1 ]
+ " ␣ |␣ " + s ta tu s [ 2 ] + " ␣ |␣ " + s ta tu s [ 3 ] + " ␣ |␣ " + s ta tu s [ 4 ] + "␣\n" ;
t ry
{
repor t . wr i t e ( t ext ) ;
}
catch ( IOException e )
{
System . out . p r i n t l n ( e ) ;
MyExit . e x i t ( 1 ) ;
}
}
try
{
repor t . c l o s e ( ) ;
}
catch ( IOException e )
{
System . out . p r i n t l n ( e ) ;
MyExit . e x i t ( 1 ) ;
}
System . out . p r i n t l n ( "∗∗∗∗∗␣THIS␣ IS␣THE␣END!␣∗∗∗∗∗ " ) ;
StartESFrame . eSFrameObserverSwarm . getContro lPanel ( ) . setStateStopped ( ) ;
done = true ;
}//end c1910
/∗∗ computational operations with code −1913 <br><br>
∗
∗ This computational code d i s t r i bu t e s items to the l i censees .
∗
∗/
pub l i c void c1913 ( )
{
checkMatrixes ( 1913 , 2 ) ;
des ignMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
getMemoryMatrixAddress ( 0 ) ;
bas icNetMatr ix = (MemoryMatrix ) pend ingComputat iona lSpec i f i ca t ionSet .
APPENDICE 200
getMemoryMatrixAddress ( 1 ) ;
l a y e r = pend ingComputat iona lSpec i f i ca t ionSet . getOrderLayer ( ) ;
i n t counter = getCounter ( basicNetMatrix , 2 ) ;
i f ( ! des ignMatr ix . getEmpty ( layer , 0 , 0 ) )
{
i f ( counter <= designMatr ix . getValue ( layer , 0 , 0 ) )
{
//Check i f item has been produced
i f ( bas icNetMatr ix . getValue ( layer , 2 , counter ) > 2)
{
System . out . p r i n t l n ( " Item␣␣#" + counter + "␣with␣ l ay e r␣#" + laye r
+ "␣has␣been␣ de l i v e r ed " ) ;
bas icNetMatr ix . setValue ( layer , 2 , counter , 4 . 0 ) ;
}
}
}
done = true ;
}//end c1913
//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
// Private functions
//∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
//The counter i s used in some computationl code in order to take actions
// on d i f f e r en t a r t i c l e with only a recipe
pr i va t e i n t getCounter (MemoryMatrix currentMatrix , i n t row )
{
//Zeroing the counter i f empty
i f ( currentMatr ix . getEmpty ( layer , row , 0 ) )
currentMatr ix . setValue ( layer , row , 0 , 0 . 0 ) ;
//Here we increment the counter
i n t counter = ( in t ) currentMatr ix . getValue ( layer , row , 0 ) ;
counter++;
//The counter must be l e s s than the number of MetaSample
i f ( counter <= designMatr ix . getValue ( layer , 0 , 0 ) )
currentMatr ix . setValue ( layer , row , 0 , counter ) ;
r e turn counter ;
}
p r i va t e void checkMatrixes ( i n t code , i n t numberOfMatrixes )
{
i f ( pend ingComputat iona lSpec i f i ca t ionSet .
getNumberOfMemoryMatrixesToBeUsed () != numberOfMatrixes )
{
System . out . p r i n t l n ( "Code␣−"+ code + "␣ r e qu i r e s ␣" + numberOfMatrixes + "␣matrix ; ␣ "
+ pend ingComputat iona lSpec i f i ca t ionSet . getNumberOfMemoryMatrixesToBeUsed ( )
+ "␣ found␣ in ␣ order␣#␣" + pend ingComputat iona lSpec i f i ca t ionSet . getOrderNumber ( ) ) ;
MyExit . e x i t ( 1 ) ;
}
}
APPENDICE 201
pr i va t e void logOpen ( boolean e r a s eF i l e , S t r ing f i leName )
{
F i l e f i l eOut = new F i l e ( f i leName ) ;
i f ( ! t h i s . grossSa lesLogFi leOpen && e r a s eF i l e )
{
try
{
F i l eWr i t e r e ra s e = new Fi l eWr i t e r ( f i l eOut , f a l s e ) ;
e r a s e . c l o s e ( ) ;
}
catch ( IOException e )
{
System . out . p r i n t l n ( e ) ;
MyExit . e x i t ( 1 ) ;
}
}
try
{
gros sSa l e sLog = new Fi l eWr i t e r ( f i l eOut , t rue ) ;
t h i s . grossSa lesLogFi leOpen = true ;
}
catch ( IOException e )
{
System . out . p r i n t l n ( e ) ;
MyExit . e x i t ( 1 ) ;
}
}
}
§ ¦
Bibliografia
[1] Avvisati F., (2003), Herbert A. Simon. Una microeconomia
empiricamente fondata, Università di Pisa.
[2] Axtell R., (2000), Why agents? On the varied motivations for
agent computing in the social sciences, Center on Social and Economic
Dynamics, Working Paper no. 17.
[3] Axtell R. L., Epstein J. M., (1994), Agent-Based Modeling: under-
standing our creations, The Bulletin of the Santa Fe Institute, Winter
1994, pp. 28-32.
[4] Balla A., (2004), Le decisioni delle organizzazioni e la complessità.
Applicazione al caso BasicNet, Tesi di laurea in Economia e Commercio,
Università di Torino.
[5] BasicNet, http://www.basicnet.com.
[6] BasicNet, divisione Menestrello (2004), BasicNet, (documento
ad accesso riservato).
[7] BasicNet, divisione Menestrello (2002), BasicSamples.com,
(documento ad accesso riservato).
[8] BasicPress, http://www.basicpress.com.
202
BIBLIOGRAFIA 203
[9] Collier N., (2003), RePast: An Extensible Framework for Agent
Simulation, Social Science Research Computing, Università di Chicago.
[10] Colombatto E., (2001), Dall’impresa dei neoclassici all’imprenditore
di Kirzner, Economia Politica, XVIII, no. 2.
[11] Conte R., (1998), Il metodo simulativo, in La Ricerca Qualitativa (a
cura di Luca Ricolfi), Roma, Carocci Editore.
[12] Edmonds B., (2003), Simulation and Complexity. How they can relate,
presentato al workshop su ‘‘Virtual Worlds of Precision − Computer-
based Simulations in the Natural and Social Sciences’’, Oxford, Gennaio
2003.
[13] Egidi M., (2003), Razionalità limitata, Sistemi intelligenti, XV, no. 1,
pp. 67-72.
[14] Ferraris G., (1999), Algoritmi genetici per l’economia, Tesi di laurea
in Economia e Commercio, Università di Torino.
[15] Fraquelli G., (2001), Elementi di Economia Manageriale, Torino,
UTET.
[16] Gilbert N., Terna P. (2000), How to build and use agent-based
models in social science, Mind & Society, no. 1, pp. 57-72.
[17] Huerta De Soto J., (2003), La Scuola Austriaca. Mercato e creati-
vità imprenditoriale (a cura di Paolo Zanotto), Soveria Mannelli (CZ),
Rubbettino.
[18] Johnson P., Lancaster A., (2000), Swarm User Guide.
[19] Kilpatrick H. E. Jr., (2001), Complexity, spontaneous order, and
Friedrich Hayek: are spontaneous order and complexity essentially the
same thing?, Complexity, vol. 6, no. 4, John Willey & Sons.
BIBLIOGRAFIA 204
[20] Kirzner I. M., (1997), Entrepreneurial Discovery and the Competitive
Market Process: an Austrian Approach, Journal of Economic Literature,
vol. 35, no. 1, pp. 60-85.
[21] Lamieri M. (2002), Simulazione Agent Based in contesti d’impresa. Ap-
plicazione del modello Virtual Enterprise in JavaSwarm ad un’azienda
reale, Tesi di laurea in Economia e Commercio, Università di Torino.
[22] Langton C. G., (1992), Vita Artificiale (traduzione di Maurizio
Riccucci), Sistemi intelligenti, IV, no. 2, pp. 189-246.
[23] Merlo F. (2003a), L’impresa rifatta nel computer: Applicazione del
modello jES al caso BasicNet, Tesi di laurea in Economia e Commercio,
Università di Torino.
[24] Merlo F. (2003b), BasicJes: esperimenti finali e considerazioni,
http://web.econ.unito.it/terna/jes_files/jesframe-0.9.9.20.tar.gz.
[25] Minar N., Burkhart R., Langton C., Askenazi M., (1996),
The SWARM Simulation System: a toolkit for building multi-agent
simulations, Santa Fe Institute, Working Paper.
[26] NetLogo, Home Page: http://ccl.northwestern.edu/netlogo.
[27] Ormerod P., (2003), L’economia della farfalla: società, mercato e
comportamento, Torino, Instar Libri.
[28] Parisi D., (1999), Se laboratorio è nel computer le scienze hanno
un’arma in più, Telèma, 5, pp. 28-30.
[29] RePast, Home Page: http://repast.sourceforge.net/index.php.
[30] Rosser J. B. Jr., (1999), On the complexities of complex economic
dynamics, Journal of Economic Perspective, vol. 13, no. 4, pp. 169-192.
BIBLIOGRAFIA 205
[31] Sanders I. T., McCabe J. A., (2003), The use of Complexity Science,
Washington Center for Complexity & Public Policy.
[32] Sciabarrà M., (2003) Il libro di CorsoJava.it, Versione 2.7.
[33] Simon H. A., (1985), Causalità, razionalità, organizzazione, Bologna,
Il Mulino.
[34] Simon H. A., (1958), Il comportamento amministrativo, Bologna, Il
Mulino.
[35] Swarm, Home Page: http://www.swarm.org e http://wiki.swarm.org.
[36] Terna P., (2004b), How to Use the Java Enterprise Simula-
tor (jES) Program, http://web.econ.unito.it/terna/jes_files/jesframe-
0.9.9.20.tar.gz.
[37] Terna P., (2003a), La simulazione come strumento di indagine per
l’economia, Sistemi Intelligenti, XV, no. 2, pp. 347-376.
[38] Terna P., (1998), Simulation Tools for Social Scien-
tists: Building Agent Based Models with SWARM, Journal
of Artificial Societies and Social Simulation vol. 1, no. 2,
http://www.soc.surrey.ac.uk/JASSS/1/2/4.html
[39] Terna P., (2002), Simulazione ad agenti in contesti di impresa, Sistemi
intelligenti, XIV, no. 1, pp. 33-51.
[40] Terna P., (2004a), Simulazione di scelte complesse nelle organizzazio-
ni, Ivrea, II Convegno Nazionale (2004) dell’AISC.
[41] Terna P., (2003b), The quest for the enterprise: jES, a Java Enterprise
Simulator, http://web.econ.unito.it/terna/jes.
BIBLIOGRAFIA 206
[42] Tinti T., (1998), La ‘‘sfida della complessità’’ verso il Terzo Millennio,
Novecento, anno 18, no. 12, pp. 7-12.
[43] Tisue S., Wilensky U., (2004), NetLogo: Design and Implementation
of a Multi-Agent Modeling Environment, Center for Connected Learning
and Computer-Based Modeling, Northwestern University (presented at
the International Conference on Complex Systems, Boston, May 16-21).
[44] Wilensky U., (1999), NetLogo 2.0.0 User Manual, Center for Connec-
ted Learning and Computer-Based Modeling, Northwestern University,
Evanston, IL.
[45] Wooldridge M., Jennings N. R., (1995), Intelligent Agents: Theory
and Practice, Knowledge Engineering Review, vol. 10, no. 2, pp. 115-152.