Questo articolo molto particolare presenta un esempio reale di come sia possibile applicare i principi dell‘Object Oriented e dell‘UML a un ambito diverso dall‘ingegneria del software. Un‘opera teatrale è stata programmata e gestita secondo tali principi, con interessanti risvolti.
Introduzione
I lettori del presente articolo, verosimilmente, avranno intravisto, almeno una volta, diagrammi prodotti attraverso il formalismo del linguaggio di modellazione unificato (UML, Unified Modeling Language). Altrettanto probabilmente, alcuni avranno utilizzato lo UML per il proprio lavoro e saranno a conoscenza del fatto che lo UML si presta ad essere utilizzato per le più svariate discipline: dall‘economia all‘elettronica, dalla matematica alla medicina, ecc. Tuttavia, quasi certamente, nessuno avrà immaginato che lo UML potesse essere utilizzato anche nel dominio strettamente artistico del Teatro. sì… Proprio nel dominio del teatro!
In quest‘articolo illustriamo un esperimento unico nel suo genere: l‘applicazione dello UML per analizzare il testo drammatico.
Sperimentazioni interdisciplinari e ibridazioni sono all‘ordine del giorno tra le differenti discipline artistiche contemporanee; l‘incontro tra teatro e nuove tecnologie è sempre più frequente e complesso; e come logica conseguenza si pone il problema di individuare nuovi strumenti necessari al drammaturgo e/o regista per analizzare un testo che preveda, o meno, la presenza in scena di nuove tecnologie. Tra questi strumenti, assume un‘importanza fondamentale la selezione della notazione da utilizzare per facilitare la condivisione del progetto tra i diversi partecipanti (regista, drammaturgo, attori, ecc.). Ecco, quindi, che una valida soluzione al problema può essere attinta proprio dal mondo dell‘informatica, dove problemi paragonabili sono spesso risolti attraverso il ricordo alla notazione dell‘UML.
Il testo teatrale
Come modulo progettuale abbiamo selezionato l‘episodio “Ecuador” dell‘equadoregno Aristides Vargas, tratto dall‘opera teatrale “La Cruzada de los Nià±os de la Calle” ([CRZLNDL]). Una creazione di sei autori latinoamericani coordinati dal drammaturgo spagnolo Josà© Sanchis Sinisterra. Il lavoro ha come scopo quello di sollecitare le coscienze sul problema delle migliaia di bambini abbandonati che ogni giorno vagano per le strade delle grandi metropoli del Terzo Mondo, costretti a vivere un‘esistenza predestinata, senza futuro… Vittime indifese del mercato della prostituzione, della droga e del traffico degli organi.
Ecco un breve riassunto del testo [CRZLNDL], che ci servirà a comprendere meglio il seguito dell‘articolo.
Un medico, con l‘aiuto di un infermiere suo complice, tratta organi umani, estratti, prevalentemente da bambini innocenti portati a lui da madri e padri disperati. Il medico, dopo aver concluso l‘affare e passa immediatamente agli bisturi. Egli si è rifugiato in una sua filosofia secondo la quale il mondo è un enorme libero mercato popolato da venditori e acquirenti e null‘altro; il mondo è quindi un enorme terreno di caccia, la strada “è” il terreno di caccia e, dunque, i bambini della strada sono “prede” alla mercà© di chi li cattura. Egli ha ridotto la sua scienza medica ad un lavoro di cacciatore che cattura e smembra le prede per rivenderle a peso d‘oro. I bambini sono “prede”, “merce”, un cuore è il “pezzo grosso” mentre le cornee sono richiestissime sul mercato americano o europeo. La sua gelida semantica è simile a quella dei contabili nazisti di fronte ai denti e ai capelli dei deportati; soldi e filosofia sono le fondamenta su cui ha edificato le sue azioni: i soldi fanno girare il mondo e il suo bisturi non è altro che un piccolo ingranaggio in un meccanismo più vasto e complesso… Questa auto-giustificazione sembrerebbe salvargli la coscienza.
Ma l‘infermiere non possiede la sua capacità di astrazione filosofica, è un povero sciagurato, ma con un briciolo di coscienza rimasta… Quindi l‘inevitabile accade: ad un certo punto un misto di paura ed irrefrenabile rimorso finiscono per riaccendere nella sua mente lo sguardo triste dei bambini-lepre che egli tiene immobilizzati sul lettino prima di essere crudelmente sbranati dal bisturi, sente il canto gioioso delle lepri emergere dalle fogne, avverte che qualcosa sta cambiando, che presto, forse, arriverà la resa dei conti. L‘infermiere, così, racconta tutto alla moglie del medico che, ignara fino a quel momento, volutamente accecata dal benessere, chiede conto al marito del suo ignobile lavoro. Questi le confida di aver già provveduto nei confronti dell‘infermiere, poiché o si è “cacciatori” o si è “preda” e se si finisce di essere cacciatori, automaticamente, si diviene prede.
Alla fine, questa legge, per contrappasso, trova applicazione anche con il medico stesso. Questi finisce per divenire preda a sua volta. Di fronte al tribunale dei bambini, le sue disquisizioni e speculazioni filosofico-scientifiche con le quali vuole giustificare il suo operato, servono a ben poco.
L‘analisi del testo e la progettazione: semiotica e UML
Trattandosi di un testo drammatico è necessario che esso sia prima analizzato con gli strumenti della semiotica poiché, senza la determinazione e l‘individuazione del soggetto e delle azioni principali, non è possibile effettuare il suo trattamento con lo UML. Lo scopo di questa prima analisi limitata alla sola struttura profonda del testo, è individuare tutti gli elementi del dramma ritenuti significativi per l‘analisi delle strutture di superficie e discorsive del testo che consentiranno sia la stesura del quaderno di regia, quale punto di riferimento per la direzione degli attori, sia per l‘ideazione e modellazione della piattaforma architetturale della installazione L‘applicazione dello UML ad un testo teatrale diventa quindi lo studio delle possibilità di interazione drammaturgica possibile tra apparato scenico e apparato tecnologico, tra linguaggio naturale e linguaggio non-naturale e tra azione scenica e sistema.
Il problema principale che emerge durante il lavoro di pianificazione può essere indicato nella distinzione logica tra testo drammatico, inteso come racconto di vita reale o meno, e progettazione della piattaforma architetturale della messinscena. Bisognava, dunque, per prima cosa distinguere tra il fare ricorso ad un metodo informatico quale lo UML, applicato al solo contenuto del testo per analizzare il rapporto di forze ed interazione tra i personaggi del dramma di Vargas e UML usato per descrivere la piattaforma architetturale della messinscena in dettaglio.
Onde evitare di limitare la discussione e la riflessione dei temi contenuti nel testo all‘ambito circoscritto dallo spazio della messinscena, Carlo Caloro ha realizzato un‘installazione unica nel suo genere. In particolare, Il testo di Vargas è lasciato interagire con internet e, partendo dagli argomenti trattati nel testo, si creano nessi con altri file di testo, immagini, suoni e video esistenti nella rete. La navigazione in internet è attivata dall‘attore ogniqualvolta inizia a camminare su di un tappeto mobile, simile a quelli che sono soliti arredare i fitness center.
Un cenno sull‘analisi dei requisiti
Ripartendo da quanto detto nel libro “UML e ingegneria del software” [LVTUML], l‘ingegneria del software è una particolare disciplina dell‘ingegneria che si occupa dell‘analisi, disegno, sviluppo e gestione di sistemi atti ad elaborare automaticamente informazioni. In particolare, attraverso l‘applicazione di determinati processi di sviluppo del software, consente, a partire da un complesso di specifiche iniziali, di produrre un sistema automatico (software) in grado di soddisfarle. I più formali processi di sviluppo del software attuali sono composti da una serie prestabilita di discipline (quali per esempio: analisi dei requisiti, analisi e disegno del sistema, implementazione, test, deployment, ecc.) eseguite predeterminate fasi, quali per esempio: inzio (inception), elaborazione (elaboration), costruzione (construction) e transizione (transitction). Ognuna delle varie discipline, come lecito attendersi, coinvolge diverse figure professionali e prevede determinati manufatti di input e di output. Per esempio, (semplificando in maniera considerevole) la fase di disegno del sistema, è, tipicamente, affidata ad un team di architetti, eventualmente coadiuvati da qualche programmatore esperto. Un fondamentale manufatto di ingresso è il modello dei requisiti, mentre uno dei principali manufatti prodotti è il disegno dell‘architettura, la pianificazione della fase di costruzione, la relativa consegna (l‘architettura non è un mero documento, bensì corrisponde ad una milestone in cui si consegna l‘infrastruttura del sistema…I famosi 20% dei requisiti che permettono di investigare l‘80% dell‘architettura), ecc.
Una delle iniziali discipline di ciascun processo di sviluppo del software, è l‘analisi dei requisiti. Le principali attività di questa fase consistono nell‘analizzare le reali necessità del cliente/utente, le vigenti regolamentazioni vigenti esistenti nel dominio oggetto di studio, eventuali vincoli aziendali, ecc. al fine di produrre un iniziale modello del sistema, denominato modello dei requisiti, necessario per eseguire il disegno ed implementazione del sistema. Questo modello, a sua volta, è composto da una serie di altri (sotto) modelli, come, per esempio:
- la descrizione dei servizi richiesti, tipicamente foggiati attraverso la notazione UML dei casi d‘uso (use case);
- la rappresentazione delle principali entità business coinvolte, corredate dalle mutue relazioni (modello ad oggetti del dominio, domain object model), disegnate attraverso la notazione UML dei diagrammi delle classi;
- il vocabolario del dominio oggetto di studio;
- il documento dei requisiti non funzionali: performance richieste, livelli di sicurezza, procedure di backup e restore, ecc. ecc.
Il modello dei requisiti è, tipicamente, prodotto da una figura professionale, l‘analizzatore del business (business analyst), ed è utilizzato dall‘architetto software per progettare il sistema.
L‘analisi dei requisiti e l‘analisi del testo teatrale
Da un‘attenta analisi dei processi di sviluppo del software più formali, è possibile evidenziare interessanti similitudini tra la fase dell‘analisi dei requisiti utente, e l‘analisi del testo teatrale: entrambi si occupano di trasformare una serie di specifiche, spesso comunicate in modo (molto) informale, in un documento utilizzabile dall‘architetto/regista per poter progettare un sistema che poi altre persone, sviluppatori/attori, implementeranno.
In teatro i requisiti di partenza sono, solitamente, rappresentati dal testo dell‘autore corredato da una serie di didascalie e dialoghi. Il ruolo dell‘analizzatore del business è svolto, inizialmente, dal drammaturgo, e dal regista poi; il loro compito consiste nell‘analizzare il testo drammatico in funzione o in prospettiva della messinscena.
L‘UML: non solo processi di sviluppo del software
Secondo le specifiche [UMLSPEC] lo UML è un linguaggio per specificare, costruire, visualizzare e documentare manufatti sia di sistemi software, sia di processi produttivi e di altri sistemi non strettamente software. Lo UML permette di visualizzare, per mezzo di un formalismo rigoroso, “manufatti” dell‘ingegneria, consentendo di illustrare idee, decisioni prese, e soluzioni adottate. Tale linguaggio favorisce, inoltre, la divulgazione delle informazioni, in quanto standard internazionale non legato alle singole imprese. In teoria, un qualunque tecnico, di qualsivoglia nazionalità , dipendente della più ignota delle organizzazioni produttrici di software (software house), con un minimo di conoscenza dell‘UML dovrebbe essere in grado di leggere il modello di un progetto e di comprenderne ogni dettaglio senza troppa fatica e, soprattutto, senza le ambiguità tipiche del linguaggio naturale.
Tuttavia, lo UML è un linguaggio di progettazione e, come tale, è “solo” parte di metodi più generali per lo sviluppo del software: lo UML è un formalismo utilizzato dai processi per realizzare, organizzare, documentare i prodotti generati dalle fasi di cui il processo si compone. Un processo, tra i vari principi, è formato dalle direttive che indicano al progettista cosa fare, quando farlo, dove e perché. Un linguaggio è, ovviamente, carente di questo aspetto. Va da sà© che i processi svolgono un ruolo assolutamente fondamentale nella realizzazione di progetti di successo, e non solo in campo informatico. Talvolta, nonostante tutti i migliori prerequisiti, si assiste al fallimento di un progetto perché lo sviluppo non è stato guidato da un processo ben definito o perché non è stato ben gestito: spesso i processi costituiscono la differenza tra progetti iperproduttivi e progetti fallimentari.
Individuazione degli attori principali
Dopo un attento studio dell‘insieme iniziale dei requisiti, l‘episodio Ecuador dell‘equadoregno Aristides Vargas, si è passati ad eseguire un vero e proprio processo di analisi delle specifiche. In particolare, il primo passo è consistito nell‘individuare gli attori principali del sistema (attori in senso “UML” e non ancora nel senso di interpreti umani di una rappresentazione teatrale), che come tali usufruiranno dei “servizi” dei casi d‘uso identificati successivamente. Nella notazione dei casi d‘uso “un attore definisce un insieme coerente di ruoli che un “utente” di un caso d‘uso “recita” quando interagisce con esso”. Un attore (UML) non è necessariamente una persona, può essere un sistema automatizzato o un qualsiasi dispositivo fisico, sebbene nel contesto del testo preso in esame, l‘interesse è limitato alle sole persone. In generale, un attore (UML), è un‘entità esterna al sistema che interagisce con esso. Si tratta dell‘idealizzazione di un persona, di un processo, o di qualsiasi cosa che interagisca con il sistema stesso inviando e/o ricevendo messaggi: scambiando informazioni. Gli attori vengono rappresentati graficamente nello UML attraverso sagome di omini stilizzati (stick man), con il relativo nome riportato alla base, quantunque sia possibile utilizzare apposite icone atte ad enfatizzarne il ruolo/comportamento dell‘attore (stereotipi).
Gli attori individuati durante questo processo di analisi sono stati catalogati attraverso opportune schede che permettono di iniziare a delinearne le principali responsabilità .ÃÂ
Di seguito sono riportate alcune schede relative al alcuni personaggi dell‘episodio preso oggetto di studio.
Per poter realizzare la vista dei casi d‘uso, è necessario definire precisamente il sistema (in termine dei suoi “confini”), identificare correttamente gli attori, definire le funzioni dei vari diagrammi, determinare le relazioni tra use case e validare il sistema stesso. Si tratta di un‘attività spesso complessa, che richiede un attento studio del materiale a disposizione, un‘elevata interazione con il cliente, e, spesso, anche con le persone che rappresentano gli attori del sistema stesso. In particolare, l‘analisi degli attori, così come proposto in precedenza, ha permesso di neutralizzare l‘iniziale disordine delle idee consueto nelle primissime fasi di studio dei requisiti utente.
Quest‘attività dell‘analisi dei requisiti, presenta diverse similitudini, soprattutto se si considera la semiotica generativa di Greimas, a un‘importante fase della generazione del senso denominata grammatica narrativa “di superficie” dove si parla di attanti che sono entità narrative di carattere sintattico, a differenza degli attori che sono, invece, entità discorsive in cui è importante l‘aspetto semantico. L‘attante nel modello di Greimas assume diversi ruoli attanziali: Soggetto, Oggetto, Destinatore, Destinatario, Oppositore, Aiutante. [GRMDSN]. Pertanto vi è un‘evidente equivalenza tra l‘attore dei casi d‘uso (ambito UML), con il ruolo attanziale teorizzato da Greimas, così come, il caso d‘uso equivale ad una casella attanziale. Entrambi possono essere considerate funzioni logiche. Un attore possiede un ruolo specifico per ogni caso d‘uso con il quale interagisce e scambia messaggi, allo stesso modo un attante riveste un ruolo attanziale specifico per ogni casella attanziale con la quale interagisce. Entrambi appartengono alla struttura profonda del testo ed entrambi possono esserne una conveniente astrazione (per esempio, il denaro, un personaggio collettivo come i bambini della strada, possono trattarsi di una persona fisica ma anche di un oggetto). Sia l‘attante che l‘attore dei casi d‘uso, possono essere scenicamente assenti (ad esempio, la clinica “Yankee” o i bambini della strada o la madre del bambino). Possono, altresì, successivamente assumere funzioni attanziali differenti (ad esempio, l‘infermiere e il medico occupano sia la casella attanziale del destinatore e contemporaneamente quella dell‘oppositore, così come l‘attore di un caso d‘uso modifica il proprio ruolo e posizione interagendo con un altro caso d‘uso). In questa fase dell‘analisi del testo o del sistema aziendale descritto nel testo, sia il modello attanziale che il diagramma dei casi d‘uso e delle classi, focalizzano l‘attenzione sullo stesso punto e cioè, sono importanti le azioni, e non chi le compie.
I principali casi d‘uso
Il diagramma di figura 2 mostra i principali casi d‘uso individuati dall‘analisi del testo organizzati in package. In questo contesto, i package sono utilizzati per raggruppare “aree funzionali”, senza alcun legame con il fattore tempo. Per esempio, la Moglie del Dottore viene “cacciata” (dallo stesso) solo dopo essere divenuta al corrente dei loschi traffici del marito (Infermiere confessa malefatte).
Il tutto ha inizio con il Responsabile Clinica (nel testo denominata clinica Yankee) che per soddisfare le richieste di un facoltoso cliente, contatta il Medico per ricevere la fornitura della merce (gli organi): effettua un ordine. Questo verrà successivamente modificato, per via della richiesta di ulteriore merce.
L‘Infermiere, vero aguzzino di strada, ricerca possibili prede, tipicamente, aggirandosi per i sobborghi malfamati della città e contattando madri disperati (Caccia bambini). A lui spettano i compiti di stipulare, per conto del Medico, gli accordi per l‘acquisto degli organi (Contratta cessione organi), di effettuare il pagamento della somma pattuita e quindi della presa in consegna delle prede (bambini disperati, Consegna Preda). Una volta ottenuto il materiale, l‘Infermiere e il Medico predispongono la sala operatoria e quindi danno luogo all‘espianto degli organi desiderati (Espianta organi) da inviare alla clinica Yankee, per soddisfare le esigenze di facoltose persone senza scrupoli.
Il losco business comincia a traballare quando l‘Infermiere comincia ad essere tormentato dal rimorso (Diviene preda del rimorso). A questo punto, si confida con la Moglie del Medico. Ciò innesca la reazione di quest‘ultimo che termina con l‘eliminazione (caccia) dei due personaggi: la Moglie e l‘Infermiere. Infine, il tutto termina con la crociata, con i bambini che marciano felici (Partecipa crociata) e catturano il cacciatore: il Medico che viene processato e ritenuto colpevole (Processa “cacciatore/preda”).
Descrizione dei casi d‘uso
Limitare il modello dei requisiti del sistema, e più precisamente i requisiti funzionali, ai soli diagrammi dei casi d‘uso (cfr. figura 2) sarebbe una pratica assolutamente azzardata. In effetti, questi ellissi (singoli casi d‘uso) sono un troppo “leggeri” per poter fornire all‘architetto e sviluppatori direttive precise circa i servizi da dover implementare. Non vi sono, per esempio, la descrizione del flusso delle azioni, delle condizioni propedeutiche all‘esecuzione degli stessi, possibili anomalie corredata dalle relative procedure di gestione, ecc. Per ovviare a questo problema è possibile ricorrere a due soluzioni:
- utilizzare appositi diagrammi, come per esempio quelli di attività e di sequenza;
- ricorrere ad un apposito template.
La prima soluzione, sebbene presenti diversi vantaggi, tipici della rappresentazione di informazioni attraverso notazioni grafica, in questo contesto, risente di severi problemi; per esempio:
- elevata manutenzione. I diagrammi richiedono diverso tempo per essere prodotti e (in questo contesto) tendono a diventare confusi e quindi difficili da gestire. Qualora, per evitare questo problema, si ricorra a diversi digrammi per descrivere ciascun caso d‘uso, il lavoro richiesto per sincronizzarli a seguito di una variazione è, tipicamente, molto elevato;
- difficoltà di standardizzare informazioni supplementari, come per esempio, condizioni propedeutiche, condizioni di successo, etc.
Al fine di risolvere i problemi succitati, nella pratica lavorativa, si preferisce definire la descrizione dei casi d‘uso attraverso un apposito template (per una descrizione dettagliata cfr. [LVTUML]), come quello mostrato di seguito.
Template dei casi d‘uso
Varianti al modello
L‘adozione del template dei casi d‘uso nel contesto teatrale ha richiesto una serie di varianti: le più importanti sono illustrate di seguito.
Dall‘analisi della descrizione dei casi d‘uso è possibile notare che non sono presenti scenari alternativi e di errore. Ciò perché nel sistema testuale teatrale a differenza degli altri sistemi software tutto è prestabilito dall‘autore e non vi sono possibilità che un attore presenti un comportamento diverso (non ci sono eccezioni business) nà© tanto meno che il sistema presenti degli errori (non è possibile avere eccezioni di sistema). Il drammaturgo e il regista effettuano tagli, modifiche varie, ma alla fine tutto è stabilito, fissato nella nuova versione del testo. Gli stessi scenari alternativi sono predeterminati dall‘autore e nell‘economia del testo drammatico occupano un posto ed un tempo preciso, prefissato.ÃÂ La durata della vicenda drammatica è fittizia e preordinata al testo e a differenza del tempo e mondo reale, si sviluppa secondo una progressione lineare e irreversibile degli avvenimenti.
Il testo che compone la descrizione del caso d‘uso è stato integrato con le relative parti del testo. Questo è stato necessario sia per inquadrare il caso d‘uso nel suo contesto teatrale, sia per agevolarne la fruizione enfatizzandone gli aspetti drammatici dettati dagli stessi autori del testo.
Modello ad oggetto del dominio
Una volta identificati anche i principali servizi (casi d‘uso) del “sistema”, e descritti i vari l‘attività successiva consistite nel produrre il modello ad oggetti del dominio (Domain Object Model). Questo è un manufatto fondamentale nei processi di sviluppo del software, non solo perché è essenziale per l‘esecuzione di altre attività come la realizzazione del modello di analisi e disegno, la progettazione del prototipo della GUI, la progettazione dello schema della base di dati, il disegno degli eventuali messaggi, e così via, ma anche perché permette di analizzare il sistema, compresi i servizi richiesti, dal punto di vista dei “dati”. Ciò, tra l‘altro, permette di verificare e rifinire il modello dei casi d‘uso. Il modello ad oggetti del dominio è prodotto durante la fase di analisi dei requisiti utente e come ne suggerisce il nome, rappresenta un modello che ha a che fare con entità “realmente esistenti” nell‘area oggetto di studio che il sistema software, in qualche misura, dovrà automatizzare. Uno degli scopi primari del modello è contribuire alla piena comprensione del contesto (spazio del problema) del sistema focalizzando l‘attenzione sulla struttura statica dei dati trattati. Si tratta di un modello statico (in quanto proiezione indipendente dal fattore tempo) dello spazio del problema che ne rappresenta un‘astrazione in termini delle varie entità presenti corredate dalle relative interconnessioni. Chiaramente le classi entità individuate in questa fase sono in uno stato embrionale, quindi necessitano di ulteriori elaborazioni per assumere la forma finale utilizzata nel modello di disegno, pronta per essere implementata. Secondo le conclusioni dei Tres Amigos (riportate nel libro [5]), le entità presenti nel modello del dominio dovrebbero appartenere essenzialmente alle seguenti categorie:
- entità “business”, ossia oggetti rappresentanti entità (più o meno tangibili) manipolati nell‘area business oggetto di studio. In un sistema per il commercio elettronico, queste entità rappresentano oggetti come: articoli, carrelli della spesa, cataloghi, ecc.;
- oggetti e concetti appartenenti al mondo concettuale che il sistema necessita di manipolare. Sempre nel caso del sistema per il commercio elettronico: regole di sconto, segnalazioni del verificarsi di condizioni richieste dall‘utente (prodotto in sconto, prezzo dimezzato, ecc.);
- eventi che possono verificarsi, come aggiunta di un prodotto al carrello della spesa, notifica di una promozione relativa ad uno specifico articolo ad un utente, ecc.
Una caratteristica tipica dei modelli ad oggetti del dominio consiste nello specificare poche o nessuna operazione nelle varie classi. In questa fase, l‘attenzione è focalizzata sui dati e sulle relative interrelazioni.
Il diagramma di figura illustra, attraverso il formalismo dei diagrammi delle classi, alcune entità operanti nel dominio oggetto di studio, corredate dalle principali relazioni. In particolare, ogni Attore interpreta uno o più istanze di Personaggio. Questa entità è una classe astratta (per questo motivo il relativo nome è mostrato con caratteri italici), pertanto non prevede istanze dirette: non può avere una vita propria. Classi astratte devono essere necessariamente specializzate da altre classi, dette figlie, come per esempio: Medico, Infermiere, Madre, ecc., che, invece, possono avere vita propria. Ciascun Personaggio, come lecito attendersi, è costituito da un insieme di elementi Organo (altra classe astratta), e pertanto è una potenziale preda. Nel diagramma delle classi (riportato di seguito), l‘entità Organo, è specializzata (relazione di eredità ) negli organi oggetto di interesse, parte fondamentale dei macabri listini prezzi.
Ogni personaggio, poi, ha una propria indole: un Ruolo intrinseco. Per esempio, i bambini sono intrinsecamente delle prede, mentre l‘infermiere è naturalmente un cacciatore. Tuttavia, ogni Personaggio incarna un ruolo effettivo solo quando si relaziona con gli altri. Nel diagramma questo aspetto è modellato attraverso la classe Relazione. In particolare, ogni Personaggio è coinvolto in una serie di relazioni con altri, e, in ogni relazione, può incarnare un diverso ruolo (questa parte del modello è illustrata, attraverso un esempio, nel diagramma successivo). Inoltre, il ruolo assunto da un Personaggio nei confronti di un altro, non è immutabile, bensì è a sua volta un‘entità variabile nel tempo. L‘esempio più eclatante è dato dal rapporto Medico/Bambini. Il Medico cacciatore, diviene inesorabilmente Preda dei bambini da lui lungamente cacciati. Questo elemento è descritto dagli attributi, presenti nella classe Relazione, che specificano, la durata temporale della stessa, il tipo della relazione stessa: genitore, figlio, affari, caccia, ecc.
Per illustrare in dettaglio la porzione del modello delle classi relativo ai personaggi coinvolti nelle varie relazioni che si intrecciano nella trama del libro, si è ricorsi alla notazione dei diagrammi degli oggetti propriamente detti.
Una delle caratteristiche molto apprezzate dello UML è la cosiddetta dicotomia tipo-istanza. Si tratta di un meccanismo che permette di rappresentare sia aspetti generici, sia esempi di elementi concreti derivanti dai primi. I casi classici di dicotomia tipo-istanza sono dati dalle coppie classi?oggetti, parametri?valori, ecc. I diagrammi degli oggetti (object diagram) propriamente detti rappresentano una variante dei diagrammi delle classi, o meglio ne sono istanze, e ne condividono gran parte della notazione. Rappresentano la famosa istantanea del sistema eseguita in preciso istante di tempo di un‘ipotetica esecuzione. Quindi, a differenza dei diagrammi delle classi, popolati di elementi astratti come classi e interface, nei diagrammi degli oggetti è possibile trovare oggetti (nella notazione UML sono evidenziati attraverso il nome ed il tipo scritti con testo sottolineato) sospesi in un particolare stato. Si tratta di un concetto dinamico che, in un preciso istante, è dato dal valore di tutti i suoi attributi e dalle relazioni instaurate con altri oggetti (che alla fine sono ancora particolari valori, indirizzi di memoria, posseduti da precisi attributi).
Il diagramma di figura 4 descrive due personaggi: Medico e Bambino, i quali, intrinsecamente, sono, rispettivamente Cacciatore e Preda (ha indole) Nella parte di sinistra del diagramma, è visualizzata una prima relazione che coinvolge entrambi i personaggi. In questa, che avviene prima della crociata, il Medico ed il Bambino obbediscono alla propria indole, quindi il primo è il cacciatore ed il secondo è preda. La relazioneÃÂ che si sviluppa alla destra, invece, ha luogo dopo la ribellione dei bambini, pertanto i valori in campo sono diametralmente opposti: i bambini diventano cacciatori, mentre il medico finisce per essere la preda.
Il diagramma di figura 5 illustra la modellazione dei macabri listini prezzi utilizzati (più o meno direttamente) dalla clinica. In particolare, ogni oggetto ListinoPrezzi contiene la descrizione e, ovviamente, il prezzo, di una serie di articoli, ciascuno dei quali è relativo ad un determinato Organo.
Il Medico del testo è specializzato nell‘espianto di cornee, tuttavia, lo stesso testo fa riferimento al “pezzo madre”: il cuore. Inoltre, è plausibile considerare il Medico come un tassello, un fornitore, del macabro mosaico del listino prezzi della clinica.
Il diagramma di figura 6 presenta l‘entità Ordine. Si tratta di una classe astratta, formata da una serie di elementi LineaOrdine. Ciascuna di questi riporta alcune informazioni e il prezzo concordato per ciascun Organo richiesto. L‘entità Ordine è rappresentata da una classe astratta in quanto vi sono due specializzazioni: OrdineVendita e OrdineAcquisto. Il primo tipo sancisce accordi effettuati dalla clinica con entità Yankee (ossia facoltosi soggetti senza scrupoli convinti di poter acquistare tutto con i soldi… anche la salute). I secondi, invece, sono il risultato degli accordi che il ResponsabileClinica prende con il Medico. Il ResponsabileClinica contatta diverse volte il Medico per ottenere gli organi necessari con le caratteristiche volute. Ogni ordine di acquisto, poi, dà luogo ad uno o più interventi chirurgici, eseguiti dal Medico con l‘assistenza dell‘Infermiere, necessari per espiantare uno o più organi alla preda di turno, che, tipicamente è un bambino… Ma ogni persona è o un cacciatore o una preda!
Diagrammi delle macchine di stato
Nel contesto dell‘analisi dei requisiti, è spesso utile descrivere il ciclo di vita di determinate entità : questo permette di visualizzare i vari stati in cui tale entità può transitare durante la sua esistenza, e gli eventi che ne forzano il passaggio di stato. Il ciclo di vita degli oggetti si presta ad essere modellato in UML attraverso la notazione dei diagrammi delle macchine di stato (State machine diagram). Per esempio, uno sportello bancomat, potrebbe prevedere i seguenti stati: fuori servizio, inizializzazione, attesa carta, acquisizione PIN, attesa selezione, ecc. ecc.
Nel contesto del testo preso in esame, per esempio, potrebbe essere utile modellare il ciclo di vita di alcuni personaggio, come per esempio, il medico e l‘infermiere come mostrato nelle seguenti figure.
Ogni personaggio possiede un suo ruolo personale, quando però instaura una relazione con un altro personaggio, il gioco di forze porta a variare la natura. Per esempio, l‘infermiere che appartiene alla cerchia dei cacciatore, finisce per essere cacciato da un cacciatore più forte: il medico!
Conclusioni
Questa sperimentazione è stata senza dubbio un‘esperienza assolutamente unica nel suo genere… Sebbene lo UML, fin dalla sua ideazione, sia stato disegnato per poter essere utilizzato nei più svariati domini, probabilmente neanche gli stessi “Three Amigos” (Grady Booch, James Rumbaugh e Ivar Jacobson, ideatori della prima versione dello UML), avrebbero mai potuto immaginarne un‘applicazione squisitamente artistica, come quella proposta dal presente studio.
La sperimentazione, per quanto entusiasmante, avvincente e proficua, ha presentato non poche problematiche, spesso presenti anche nei classici progetti software. Il cammino è risultato irto di ostacoli, principalmente dovuti a due diversi universi che si avvicinavano, alla necessità di incanalare percorsi prettamente artistici, intrinsecamente e volutamente ribelli a schemi, in piattaforme formali e precise proprie delle discipline dell‘ingegneria. Oltre a dover incastrare creatività negli elementi propri dell‘UML, era necessario che tutto si sviluppasse in funzione delle leggi dell‘Object Oriented.
Tuttavia, l‘esuberante flusso artistico ha fatto sì che, dopo iniziali sperimentazioni non sempre luminose, seguisse tutto un fiorire di diagrammi. Questi hanno il pregio di alludere ai luoghi, persone e fatti narrati nel testo e contemporaneamente alle migliaia di varianti della realtà di tutti i giorni, invitando chi guarda, ognuno in base alle proprie conoscenze personali sul tema trattato nel testo, a riflettere e a interpretare i diagrammi in grado di rivelare sinteticamente l‘infallibile efficienza del sistema criminoso. I diagrammi sono in grado di descrivere determinate situazioni nel loro insieme o, precisi istanti del fatto, fornendo allo spettatore/fruitore gli elementi necessari per ricostruire da sà© l‘andamento drammaturgico del testo fittizio o reale.
L‘analisi formale del testo per mezzo del formalismo dell‘UML, quindi, non si limita a mere produzioni di aridi diagrammi e moduli, fini a sà© stessi, in grado solo di alimentare sterili elucubrazioni mentali; tutt‘altro… Questa sperimentazione ha permesso di evidenziare come molti aspetti dell‘utilizzo dello UML, analogamente a quanto avviene con la semiologia del teatro, facilitano il trattamento del testo teatrale favorendone una comprensione più approfondita, libera da dogmatismi, al riparo da qualsiasi coinvolgimento emozionale e, al tempo stesso, sufficientemente flessibile da lasciare libero spazio all‘espressione creativa delle persone che prendono parte allo sviluppo del progetto. I due metodi, UML/OO e semiologia, permettono di analizzare il testo drammatico procedendo attraverso diverse fasi di astrazioni, che possono procedere dal più profondo al più superficiale e/o viceversa. Ciò facilita l‘individuazione del discorso dominante attraverso il quale è possibile stabilire il sistema di segni testuali necessari al drammaturgo e al regista per costruire un sistema significante. Inoltre, gettano le fondamenta per lo studio della presenza di eventuali sistemi informatici utilizzati come parti integranti della messainscena. Carlo Caloro ha sperimentato questa possibilità realizzando un‘installazione in cui lo spettatore è lasciato libero di interagire con la parte drammatica del testo attraverso l‘utilizzo di appositi sistemi informatici. Scenario innovativo, che ovviamente ha fornito per fornire nuovi stimoli e sollecitazioni per i metodi tradizionali dell‘analisi dei testi teatrali… Questo argomento, tuttavia, è oggetto di un altro articolo.
I casi d‘uso, corredati dalla relativa descrizione, prodotti durante la prima fase dell‘analisi testuale, analisi, limitata alla sola struttura profonda del testo, forniscono un eccezionale riferimento a coloro che, successivamente, si occupano di curare la regia dell‘opera teatrale. L‘utilizzo di queste informazioni per analizzare le strutture di superficie e discorsive del testo agevola la redazione del necessario copione, quale punto di riferimento per la direzione degli attori. Questo, quindi, contiene l‘insieme delle indicazioni/istruzioni desunte dalla modellazione statica e dinamica della piattaforma architetturale del testo, generando una distinzione tra la lista delle indicazioni relative e necessarie agli attori in fase di interazione tra gli stessi e quella con gli altri codici che comporranno l‘evento performativo.
La formalità dei vari modelli, come per esempio quello ad oggetti del dominio, se da una parte pone il grosso vincolo dovuto alla formalità intrinseca e alle nozioni dell‘O.O. celate all‘interno di ogni elemento grafico, dall‘altro permette di investigare in dettaglio entità esistenti nel testo, personaggi, relative relazioni, ecc. Quindi, si tratta di ottimi strumenti di investigazione, sebbene siano spesso non banali e richiedano un iniziale investimento di tempo non trascurabile… Tuttavia, si tratta di un lasso temporale che sarebbe comunque necessario spendere, magari in forme meno formali e meno facilmente riutilizzabili, per approfondire la cognizione del testo. E, probabilmente finirebbe per richiedere un maggiore dispendio di tempo , come spesso accade nel caso di progetti di sistemi software, dove approfondimenti errati o tardivi finiscono per amplificare l‘intervallo richiesto. I vari modelli, tendono a richiedere diverso tempo per la relativa produzione, ma una volta realizzati, permettono di evidenziare chiaramente ed in maniera non ambigua, le diverse proiezioni con cui è possibile esaminare uno stesso oggetto.
Riferimenti
[CRZLNDL] Claudia Barrionuevo – Dolores Espinoza – Christiane Jatahy – Ivà¡n Nogales – Josà© Sanchis Sinisterra – Aràstides Vargas -ÃÂ Vàctor Viviescas, “La Cruzada de los Nià±os de la Calle”, Sociedad General de Autores, Madrid 2001
[UMLSPEC] Sito Omg
http://www.uml.org/#UML2.0
[LVTUML] Luca Vetti Tagliati, “UML e ingegneria del software: dalla teoria alla pratica”, HOPS/Tecniche Nuove
[GRMDSN] Algirdas Julien Greimas, “Del Senso”, Bompiani, Milano 2001
Carlo Caloro collabora, come attore e assistente alla regia con diverse compagnie teatrali, e come docente con diverse istituzioni in Italia e all?estero. Nel 2001 si diploma in media audiovisivi presso la KHM, Accademia di Arti Mediali di Colonia (Germania). Nel 2004, si diploma in regia presso l?Accademia d?Arte Drammatica ?Silvio D?Amico? di Roma, dove attualmente collabora al corso di Regia tenuto dal Maestro Domenico Polidoro, svolgendo attività di ricerca nel campo delle nuove tecnologie applicate allo spettacolo teatrale.
Luca Vetti Tagliati ha conseguito il PhD presso il Birkbeck College (University of London) e, negli anni, ha applicato la progettazione/programmazione OO, Component Based e SOA in diversi settori che variano dal mondo delle smart card a quello del trading bancario, prevalentemente in ambienti Java EE. Dopo aver lavorato a lungo nella City di Londra per le più importanti banche di investimento (Goldman Sachs, Lehman, Deutsche Bank, UBS, HSBC) ricopre attualmente l'incarico di Senior Lead Global Architect per importanti gruppi bancari nel sud della Svizzera. Ha collaborato attivamente con John Daniels (coautore del libro "UML components") e Frank Armour (coautore del libro "Advanced Use Case Modeling"). È autore del libro "UML e ingegneria del software", pubblicato nel 2003 da HOPS/Tecniche Nuove, di "Java Best Practice: i migliori consigli per scrivere codice di qualità", pubblicato nel 2008 dal medesimo editore, e dell'ebook "Verso Java 8. Appunti per lo sviluppatore in Java SE 7" pubblicato da MokaByte e scaricabile dal nostro sito. È stato invitato a Los Angeles e Boston per presentare i suoi paper in convegni inerenti Software Engineering & Architecture. Nel 2015 ha ricevuto il prestigioso ICMG Award.