Un linguaggio di modellazione (modeling language in inglese) è un linguaggio formale che può essere utilizzato per descrivere (modellare) un sistema di qualche natura.
Il concetto trova applicazione soprattutto nell’ingegneria del software; un modello di un sistema software, o di qualche suo aspetto, prende il nome di modello software (software model in inglese)
In ingegneria del software, UML (Unified Modeling Language, “linguaggio di modellazione unificato”) è un linguaggio di modellazione specifica basato sul paradigma object-oriented.
Il nucleo del linguaggio fu definito nel 1996 da Grady Booch, Jim Rumbaugh e Ivar Jacobson (detti “i tre amigos”) sotto l’egida dello OMG, che tuttora gestisce lo standard di UML. Il linguaggio nacque con l’intento di unificare approcci precedenti (dovuti ai tre padri di UML e altri), raccogliendo le best practices nel settore e definendo così uno standard industriale unificato. UML svolge un’importantissima funzione di lingua franca nella comunità della progettazione e programmazione a oggetti Gran parte della letteratura di settore usa UML per descrivere soluzioni analitiche e progettuali in modo sintetico e comprensibile a un vasto pubblico.
I linguaggi di modellazione descritti in letteratura o utilizzati nella pratica dello sviluppo del software si possono classificare secondo numerosi criteri:
– grafici o testuali. I linguaggi di modellazione grafici sono basati su uno o più tipi di diagrammi, costruiti a partire da simboli grafici con una semantica chiaramente definita. I linguaggi non grafici usano un linguaggio formale testuale, spesso paragonabile per struttura a un linguaggio di programmazione
– interpretabili o non interpretabili. Alcuni linguaggi di modellazione hanno una sintassi e una semantica tali da consentire l’interpretazione e l’elaborazione dei modelli da parte di specifiche applicazioni software. L’elaborazione può avere diversi scopi: un modello può essere per esempio eseguito (in tal modo fornendo una simulazione più o meno completa del comportamento del sistema modellato) o tradotto (per esempio generando codice sorgente utilizzabile nell’implementazione del sistema, o altri artefatti).
– oggetto della modellazione. Diversi linguaggi consentono la modellazione di diversi aspetti di un sistema software. I linguaggi di data modeling sono orientati alla descrizione delle strutture dati utilizzate dal sistema; altri linguaggi possono enfatizzare le caratteristiche funzionali, il comportamento dinamico, gli aspetti di concorrenza, le performance o altro. I linguaggi non orientati alla modellazione di sistemi software possono essere classificati in funzione del particolare contesto in cui si applicano (per esempio modellazione dei processi di business).
1.1 Definizione di un processo
Il Processo di Business descrive la rete di relazioni tra agenti che devono cooperare per raggiungere un fine predefinito. Quando il fine è lo sviluppo di un prodotto software allora esso si dice Processo Software.
Un processo è:
• L’insieme delle operazioni finalizzate a trasformare un input in un output (attività)
• L’insieme delle decisioni assunte ai diversi stadi di realizzazione di un risultato (control flow)
• Rete di relazioni tra agenti (applicazioni/tool/uomini) attivate dal flusso delle informazioni e delle comunicazioni (object flow) per realizzare in cooperazione un prodotto
Definire un processo significa descrivere, in maniera comprensibile, corretta, completa e non ambigua, le sue numerose caratteristiche e variabili di processo:
• Attività da eseguire per raggiungere gli obiettivi del processo (analisi, progetto, codifica, test ecc.); [Obbligatorio]
• Ruoli che le persone rivestono nell’esecuzione del processo (analista, progettista, programmatore, tester ecc.); tra i ruoli deve esserci un responsabile che assicura l’esecuzione conforme dell’attività utilizzando risorse minori o uguali a quelle assegnate
• Competenze possedute da coloro che sono coinvolti nell’esecuzione del processo (conoscenza specifica di linguaggi e tools, grado di esperienza del dominio applicativo ecc.)
• Contesto, caratteristiche dell’ambiente e dell’organizzazione esecutrice (standard adottati, qualità target dei prodotti ecc.)
• Struttura e natura dei Manufatti che devono essere prodotti e manutenuti (requisiti di analisi, documenti di progetto, codice, insieme dei casi di test ecc.)
• Tools che devono essere utilizzati (Case tools e compilatori)
• Scenario procedurale che specifica i passi elementari da eseguire per coordinare gli agenti disponibili all’attività, assicurando la corretta e completa esecuzione dell’attività
1.2 Linguaggi di Modellazione
I linguaggi di rappresentazione di un processo (Process Modeling Languages) sono utili per molteplici obiettivi tra cui:
– Comprensione del processo: l’adozione di un PML può essere utilizzata per rappresentare in maniera precisa e concisa come un processo, già esistente, è strutturato e organizzato. Ciò consente una comprensione profonda dello stesso, priva di ambiguità, e permette di eliminare le inconsistenze presenti nella specifica grazie ad opportuni controlli;
– Progettazione del processo: i linguaggi di descrizione del processo consentono di creare un nuovo processo non ancora formalizzato, definendo la sua struttura ed organizzazione;
– Aspetti didattici: la descrizione precisa e non ambigua del processo lo rende trasferibile e facilmente comprensibile dagli addetti ai lavori;
– Simulazione del processo e ottimizzazione: un processo descritto formalmente può essere simulato al fine di verificarne il funzionamento, eliminare difetti e individuare punti da migliorare;
– Supporto al processo: una descrizione precisa e dettagliata del processo, può essere interpretata e utilizzata per fornire supporto (a differenti livelli di profondità) al personale coinvolto nella sua esecuzione.
In letteratura sono disponibili numerosi linguaggi e formalismi di rappresentazione di un processo, ognuno dei quali presenta delle proprie caratteristiche. Alcuni tra i più noti sono:
• BPMN
• Multi View Process Language
• UML
• OIKOS
• SADT
• SPELL – EPOS
• Formal Structured Planning
1.2.1 BPMN
Con l’acronimo BPMN indichiamo Business Process Model and Notation, precedentemente intesa come Business Process Modelling Notation.
Si tratta di un PML che fornisce le primitive per rappresentare graficamente la specifica di processi di business, ovvero della rete di agenti e relazioni che devono cooperare per realizzare un processo.
La notazione utilizzata per creare diagrammi dei processi di business (BPD) è basata sulle tecniche dei flowchart, similarmente ai diagrammi di attività dell’UML; non a caso, BPMN è stato creato dall’OMG group, la stessa equipe scientifica che ha curato lo sviluppo di UML.
La finalità del BPMN è supportare la gestione dei processi di business, fornendo una notazione standard comprensibile da tutti gli stakeholders, siano essi tecnici oppure esperti della logica di business dei processi da rappresentare; le specifiche BPMN forniscono anche una mappatura tra la notazione grafica e i costrutti del linguaggio di esecuzione BPEL, in modo che i processi rappresentati possano essere simulati, al fine di rilevarne i difetti ed eseguirne l’ottimizzazione, ed effettuare test dinamici sul processo simulato.
BPMN può essere visto come un linguaggio che va a colmare le ambiguità e le lacune che si creano fra la fase di progettazione dei processi di business e la loro successiva implementazione.
La versione 2.0 di BPMN ha introdotto diverse novità, ovvero ha cercato di unificare il linguaggio che definisce la notazione, il metamodello e il formato di interscambio, permettendo in questo modo l’interscambio dei modelli del processo di business e dei loro diagrammi tra gli strumenti di modellazione dei processi, per preservare l’integrità semantica.
Poiché la modellazione dei processi di business è usata per comunicare una varietà informazioni destinate ad una varietà di utilizzatori, BMPN ha sviluppato tre tipologie di sottomodelli: Privato (interno), Astratto (pubblico), e di Collaborazione(globale).
I processi di business di tipo privato sono quelli interni alla specifica organizzazione in questione, e sono quelli comunemente chiamati workflow oppure processi BPM; se utilizziamo le swim lanes, allora un processo privato di business sarà contenuto all’interno di un singolo Pool. Il flusso di sequenza del process sarà contenuto all’interno del Pool e non potrà oltrepassare i confini di esso, mentre i flussi di messaggi potranno oltrepassare tale confine per mostrare le interazioni che esistono tra i vari processi privati di business.
I processi di business pubblici (detti abstract) rappresentano le interazioni fra un processo di business privato ed un altro, oppure un partecipante; quindi mostreremo le attività che comunicano con l’esterno, non quelle interne. La rappresentazione di queste tipologie di processi mostreranno la sequenza di messaggi necessaria per interagire con un processo di business; i processi astratti sono contenuti in un Pool, e possono essere modellati separatamente, oppure all’interno di un singolo diagramma più grande; se il processo abstract è nello stesso diagramma di quello privato corrispondente, allora le attività comuni ai due processi possono essere associate.
I processi globali, oppure di collaborazione rappresentano le interazioni fra due o più entità di business; esse saranno una sequenza di attività che rappresentano lo schema di scambio di messaggi tra le entità coinvolte. I processi di collaborazione possono essere contenuti all’interno di un Pool, e le differenti interazioni di business partecipanti mostrate come corsie del Pool, oppure come due oppure più processi abstract che interagiscono attraverso lo scambio di messaggi.
1.2.2 MULTIVIEW PROCESS LANGUAGE
Si indica comunemente con la sigla MVP-L, ovvero linguaggio per la modellazione dei processi multi vista. Èstato sviluppato negli anni ‘80 dall’Università del Maryland e in seguito perfezionato da quella di Kaiserslautern. MVP-L nasce dal progetto di modellazione multi vista, che si concentra sui modelli di processo, la loro rappresentazione, la loro modularizzazione, in accordo con le viste, il loro uso nel contesto dello sviluppo di software per supportate la creazione di modelli descrittivi di processi, l’impacchettamento per il loro riuso, l’integrazione dei modelli all’interno di piani di progetto, l’analisi di essi, e il loro utilizzo al fine di gestire e guidare i progetti futuri. Il principale ambito di applicazione del linguaggio MVP-L è la modellazione “in-the-large”, considerando che la capacità di comprendere, guidare e supportare l’interazione tra processi offre più benefici rispetto all’automazione completa delle singole attività a basso livello. L’MVP-L supporta il miglioramento dei processi poiché li modella, pianifica, li interpreta e ne misura le qualità; i costrutti del linguaggio sono i seguenti:
I modelli (Types), tramite i quali possiamo descrivere:
gli artefatti, come i documenti (product_model);
le attività, come ad esempio la revisione di un documento (process_model);
le risorse, ovvero le persone e gli strumenti (resource_model);
gli aspetti relativi alla qualità, ad esempio i modelli provvisionali dello sforzo(quality model);
Gli attributi, definiti in modo tale che
Ciascun tipo di modello abbia attributi propri;
Essi corrispondano alle misure;
I valori degli attributi corrispondano ai dati delle misurazioni.
I modelli sono adattati al contesto attraverso l’istanziazione di oggetti, e gli oggetti eseguibili vengono assemblati tramite project_plans).
Le relazioni tra oggetti sono di tipo Product flow (consuma, produce, consuma e produce), Control flow, definibili implicitamente tramite pre e post-condizioni e invarianti, oppure tramite costrutti come i criteri d’entrata e d’uscita. Il linguaggio prevede processi di raffinamento e aggregazione e supporta l’Information Hiding, visto che prevede Modelli basati sulla separazione fra Interfaccia (visibile dagli altri modelli) ed il Body (visibile internamente), e i modelli possono essere progettati in maniera tale che i cambiamenti potenziali siano locali, e non riverberino su altri oggetti. I processi, i prodotti e le risorse possono essere usati per modellare gli elementi di base di un progetto software; gli attributi possono essere usati per definire le proprietà specifiche di questi tre elementi di base. Il product model comprenderà il prodotto software, gli artefatti, i documenti ottenuti durante lo sviluppo e la manutenzione, i sottoprodotti e la documentazione; a titolo di esempio, presentiamo un documento dei requisiti:
1.2.3 UML
Lo Unified Modeling Language è un linguaggio di modellazione utilizzato nel campo dell’ingegneria del software. Include un insieme di notazioni grafiche tramite le quali creiamo modelli visuali di sistemi software realizzati utilizzando la metodologia object-oriented. UML è stato sviluppato negli anni ‘90, e allo stato attuale è giunto alla versione 2.4.1, curata dall’OMG group. Esso combina tecniche derivate dalla modellazione dei dati (diagrammi entità-relazione), dalla modellazione dei processi di business (es. workflows-attività) e dalla modellazione delle componenti; può essere utilizzata per modellare tutte le fasi che caratterizzano il ciclo di vita del software, e per utilizzare differenti tecnologie implementative.
Grazie all’UML possiamo individuare una metodologia per visualizzare l’architettura di sistema, in termini di elementi quali:
• Attività
• Attori
• Processi di business
• Schemi di database
• Componenti logici
• Enunciati espressi tramite linguaggi di programmazione
• Componenti software riusabili
L’UML è estendibile essenzialmente utilizzando due meccanismi, profili e stereotipi; si tratta di uno strumento che non è un vero e proprio metodo di sviluppo software, ma la cui massiccia diffusione ha portato alla modifica di metodi che prevedono l’adozione di UML e ne sfruttano i vantaggi, come il RUP (Rational Unified Process).
I diagrammi forniscono una rappresentazione grafica di una porzione del sistema, ma la modellazione comprende anche una documentazione testuale che completa i diagrammi, ad esempio la descrizione dei casi d’uso e gli scenari. Attraverso i diagrammi UML possiamo mostrare due differenti prospettive del sistema:
• Vista statica strutturale, che enfatizza la struttura del sistema in termini di oggetti, attributi, operazioni e relazioni, rappresentata tramite diagrammi delle classi e diagrammi dei componenti;
• Vista dinamica comportamentale, che mette a fuoco il comportamento del sistema mostrando la collaborazione tra gli oggetti che lo compongono ed i cambiamenti nello stato interno degli oggetti stessi, ovvero i valori assunti dalle proprietà; questa vista include i diagrammi di sequenza, di attività e state-chart.
Alcune critiche mosse all’UML sono che applica dei criteri di astrazione del sistema a un livello errato; infatti, esso tende a generare schemi di comprensione non immediata per adeguarsi ai design patterns. Inoltre, poiché i modelli UML non possono essere direttamente compilati, eseguiti ed interpretati, sono considerati mera documentazione. Dunque, spesso è inefficiente sincronizzare il codice e la documentazione UML, e risulta troppo dispendioso farlo in situazioni in cui l’UML non fornisce alcun valore aggiunto. Ulteriori critiche si concentrano sul concetto che UML non abbia sufficientemente elevato il livello di astrazione; ad esempio, il passaggio dall’assembler al C permise un notevole incremento in produttività conseguente all’aumento di astrazione, cosa che con l’UML e la programmazione Object-Oriented non sempre è stata assicurata.
1.2.4 OIKOS
LIMBO e PATE sono due linguaggi di modellazione dei processi per OIKOS. Poiché entrambi sfruttano l’idea della coordinazione come supporto per un processo software come ispirato dal linguaggio Linda, di cui è opportuno descrivere alcuni concetti comuni di base. Nel linguaggio Linda, la coordinazione è basata su tuple e spazi di tuple; una tupla consiste in un set di variabili e valori, mentre uno spazio di tuple può essere visto come una memoria distribuita condivisa, in cui le tuple possono essere inserite o rimosse. Ciascuna tupla in uno spazio di tuple è prodotta da alcuni processi in esecuzione, e permane nello spazio di tuple fin quando un altro processo la consuma. Quando un processo richiede specifiche tuple che non esistono, il processo può essere sospeso fin quando queste tuple vengono rese disponibili.
Essendo stati fortemente influenzati da Linda, Limbo e Pate supportano la modellazione di un processo software sfruttando un sistema di processi reattivi (chiamati agenti) che comunicano usando spazi di tupla condivisi chiamati blackboards(“lavagne”). Limbo e Pate hanno origine dal prolog, e adottano un approccio basato sulle regole per supportare la modellazione e l’attivazione dei processi software. volendo effettuare una classificazione, Limbo è il linguaggio di specifica, mentre Pate quello di implementazione; infatti, è possibile ottenere un modello di processo in Pate attraverso raffinamenti successivi di una specifica descritta in Limbo.
Il modello di processo è costruito in Pate in termini di una gerarchia di agenti, ciascuno dei quali connesso alla propria lavagna quando l’agente è attivato; gli agenti reagiscono alla presenza di tuple (principalmente fatti in Prolog) sulla loro lavagna attraverso la rimozione di tuple, e l’inserimento di tuple nelle loro lavagne o su lavagne di altri agenti di cui sono a conoscenza. Il comportamento di un agente è definito attraverso una teoria consistente in uno schema di azioni e reazioni, oltre che di un programma sequenziale in Prolog (chiamato base di conoscenza); ciascuno schema definisce una coppia stimolo-risposta; lo stimolo consiste in una Read guard ed una In guard, mentre la risposta consiste di un Body e di un Success Set; opzionalmente, anche di un Failure Set.
Uno schema può attivarsi quando le tuple presenti sulla lavagna dell’agente soddisfano le Read e In Guards; queste tuple saranno consumate e rimosse dalla lavagna in questione. Nella situazione in cui parecchi schemi possano essere attivati contemporaneamente, uno è scelto in maniera non deterministica, e lo schema ed il programma sequenziale prolog sono eseguite; tuttavia, tale esecuzione non deve prevedere effetti collaterali su lavagne di agenti il cui schema è contemporaneamente attivato.
In termini di supporto alla modellazione, le attività e i loro vincoli sono supportati indirettamente specificando la teoria di ciascun agente (ad esempio gli schemi di azione e reazione e la base di conoscenza). Questo può essere ottenuto sia tramite le specifiche Limbo , successivamente raffinate dal linguaggio implementativo, sia direttamente nel linguaggio implementativo. Non è chiaro come sia supportata la rappresentazione dei ruoli in Pate; gli strumenti possono essere invocati nel body degli schemi oppure nella base di conoscenza; si accede agli artefatti, grazie agli identificatori, attraverso alcuni servizi standard. Le attività parallele possono essere supportate perché gli agenti stanno eseguendo effettivamente le attività, comunicando l’utilizzo di molteplici spazi di tuple. Tuttavia, la modularizzazione e l’astrazione dei modelli di processo non sono supportate. In termini di supporto all’esecuzione, un modello di processo espresso in Pate può essere eseguito in un ambiente distribuito; tuttavia, Pate non supporta l’allocazione dinamica di risorse. Inoltre, in termini di supporto all’evoluzione dei processi, Pate non supporta la reflection; nessun supporto è fornito per le collezioni di dati provenienti dall’esecuzione di attività.
1.2.5 SADT
Structured Analysis and Design Technique (SADT) è una metodologia di ingegneria del software finalizzata a descrivere il sistema come una gerarchia di funzioni.
Structured Analysis and Design Technique (SADT) è una rappresentazione schematica, progettata specificamente per aiutare le persone a descrivere e comprendere i sistemi. Offre blocchi per rappresentare le entità e le attività, e una serie di frecce per le relazioni. A queste scatole e frecce è associata una semantica informale. SADT può essere usato come strumento di analisi funzionale di un dato processo, utilizzando livelli successivi di dettagli. Il metodo SADT permette non solo di definire le esigenze degli utenti per gli sviluppi IT, che viene spesso utilizzata nei sistemi informativi industriali, ma anche per spiegare e presentare i processi e le procedure di produzione di una attività. La SADT fornisce una specifica vista funzionale di qualsiasi impresa descrivendo le funzioni e le loro relazioni in una società. Queste funzioni soddisfano gli obiettivi di una società, come la vendita, la pianificazione degli ordini, la progettazione, la produzione e la gestione delle risorse umane. SADT è stata utilizzata fin dalla metà degli anni ‘70, e ha ispirato numerosi strumenti commerciali; è disponibile come prodotto commerciale sotto il nome di IDEF0. Le primitive sono things, ossia gli oggetti, i dati, i nomi, le informazioni, le sostanze, che hanno un ruolo passivo, mentre happenings sono le operazioni, le attività, i verbi, ciò che deve essere processato, gli eventi, e hanno un ruolo attivo. Abbiamo a disposizione due tipi di scatole: data boxes ed activity boxes, interconnesse attraverso frecce per formare un diagramma; ciascun diagramma include sei scatole, ciascuna delle quali ha il proprio diagramma, in modo tale che si crei un modello gerarchico di attività e dati.
Analizziamo la semantica delle frecce che compongono il modello SADT:
• Riguardo un’attività, gli input sono i dati che devono essere consumati, gli output quelli prodotti, i controlli influenzano l’esecuzione di un’attività ma non sono consumati;
• Riguardo un dato, gli input sono attività che producono il dato, gli output quelle che lo consumano, ed i controlli influenzano lo stato interno dei dati.
Ai diagrammi creati in SADT si applica una decomposizione di tipo top-down, in cui a ciascuna scatola viene associato un diagramma con una propria struttura interna; la decomposizione dei diagrammi è il principale strumento per effettuare il raffinamento. Gli aspetti che vengono modellati sono technical assessment, che riguardano l’architettura, operational assesment, che riguardano le performance del sistema, ed economic assesment, che modellano il costo e l’impatto dell’implementazione e dell’uso del sistema. Alcuni ruoli definiti nei processi modellati con SADT sono l’autore, il commentatore, il reader (ovvero l’utente dei diagrammi), l’esperto del dominio, il tecnico committente, il project manager.
1.2.6 SPELL
SPELL è il process modelling language di EPOS; è di tipo object-oriented, derivato dal linguaggio di programmazione prolog. In SPELL, il supporto principale al processo software è fornito da due classi predefinite, ovvero TaskEntity e DataEntity.
TaskEntity rappresenta la radice della gerarchia delle attività, mentre DataEntity è la radice della gerarchia dei dati, ovvero degli artefatti. I tipi di attività di SPELL devono essere una sottoclasse di TaskEntity, che prevede un numero di attributi predefiniti che possono essere individuati su misura delle esigenze del modello di processo. Alcuni degli attributi più importanti dei task sono:
• Pre/Post condizioni: divisibili in Pre/Post condizioni statiche e dinamiche, sono specificati dalla logica del primo ordine (come nel Prolog). Le condizioni statiche sono usate principalmente per costruire una rete di attività connesse attraverso il pianificatore di esecuzioni, utilizzando la concatenazione in avanti oppure all’indietro; le pre-condizioni e post-condizioni dinamiche sono vincoli stabiliti prima o dopo l’esecuzione di un task, e sono utilizzati per innescare attività in maniera dinamica.
• Codice: l’attributo codice definisce i passi che sono effettuati quando un’attività è eseguita. Il codice di un’attività è responsabile del soddisfacimento delle post-condizioni dinamiche; quando l’attributo Codice è vuoto, ad esempio non specificato, l’attività deve essere necessariamente composta, dunque l’attività non è eseguita da un pezzo specifico di codice, ma piuttosto dall’esecuzione delle sottoattività, come ora dettaglieremo.
• Decomposizione: questo attributo è in relazione a quello codice appena descritto, poiché permette di specificare le sottoattività. In SPELL, le sottoattività possono anche essere una rete di attività; come l’attività genitore, la rete di sottoattività è creata dal pianificatore di esecuzioni usando le condizioni statiche.
• Formal: l’attributo formal permette la specifica degli artefatti di input e di output richiesti dalle attitivà.
• Esecutore: questo attributo permette di specificare gli strumenti utilizzati nelle attività.
• Ruolo: l’attributo che rappresenta il ruolo svolto dall’attività.
In aggiunta a questi attributi la classe TaskEntity definisce un numero di attributi dei meta-livelli e dei metodi, per permettere modifiche successive all’esecuzione di tale classe. Gli attributi dei meta livelli e dei metodi sono stati progettati per fornire il supporto per la reflection in SPELL. Tuttavia, un importante aspetto che può essere specificato a questo livello sono i triggers, ovvero operazioni speciali invocate prima o dopo l’esecuzione di un metodo. Itrigger specificano i vincoli specificando quando il codice del trigger può essere eseguito in funzione della chiamata del metodo; attraverso essi, si possono acquisire e modificare i valori dei vari stati interni dell’esecuzione dei task, se necessario. SPELL definisce anche una famiglia di tipi derivati dalla classe DataEntity che specifica gli artefatti; tipicamente si tratta dei tipi di dato utilizzati nei processi software, come il tipo testo e binario, che possono essere specializzati ulteriormente in altri tipi, come sorgente C ed object-file.
Per l’esecuzione dei processi in SPELL, il sistema di supporto all’esecuzione consiste di due parti: il pianificatore delle esecuzioni, e il manager delle esecuzioni; il pianificatore genera una rete di attività dalle pre-post condizioni statiche, utilizzando la concatenazione in avanti oppure all’indietro; la rete di attività a livello più alto deve essere generato dal pianificatore d’esecuzione prima che il flusso d’esecuzione abbia inizio, ma le reti di attività ai sottolivelli possono essere generate incrementalmente. Il gestore delle esecuzioni esegue la rete deitask in questione, e lavora in combinazione con il pianificatore di esecuzione in modo che, quando un’attività composta è incontrata, il manager di esecuzione invoca il pianificatore per dettagliare l’attività composta basata sulle sue pre e post condizioni; in questo modo, SPELL permette la generazione del dettaglio delle reti di sotto-attività solo quando necessario.
Volendo effettuare un’analisi di SPELL, possiamo affermare che il supporto per la modellazione delle attività è fornito dalla classe TaskEntity e dalla specifica delle proprietà elencate precedentemente. Le attività in parallelo sono supportate, e vengono gestite automaticamente dal pianificatore di esecuzione e dal manager di esecuzione. I vincoli delle attività vengono definiti tramite entrambi i tipi di Pre/Post condizioni, e l’astrazione dei ruoli e degli strumenti è supportata attraverso gli appositi attributi della classe TaskEntity; gli artefatti sono tipizzati, e memorizzati in un database chiamato EPOS-DB; la modularizzazione e l’astrazione sono supportati attraverso la decomposizione degli attributi e del codice della classe TaskEntity. Dal punto di vista del supporto al flusso di esecuzione, il modello espresso da SPELL può essere eseguito in un sistema distribuito; SPELL non sopporta l’allocazione dinamica delle risorse, ma il modello del processo, ed il relativo consumo di risorse, può evolversi durante l’esecuzione tramite la reflection; non c’è supporto per la raccolta dei dati estrapolati dalle esecuzioni.
1.2.7 Formal Structured Planning (FSP) – Software Process Engineering Metamodel (SPEM)
Formal Structured Planning: è un modello che rappresenta un processo mediante
1. Definizione e descrizione dei manufatti
Descrizione dei prodotti/documenti, finiti e semi finiti, che compongono gli input e gli output. Ogni manufatto, usato o prodotto, è univocamente identificato da un’etichetta ed i manufatti etichettati formano una gerarchia descrivibile con operatori strutturati.
2. Definizione e descrizione del Work Flow Diagram (WFD)
Le fasi e le attività previste nel processo (e le relazioni tra loro intercorrenti) attraverso i manufatti. Il WFD descrive una modalità di decomposizione gerarchica del sistema per livelli d’astrazione (WFD, Fasi, Attività Elementari ed Attività di Base).
3. Definizione degli scenari procedurali
Descrivono un’attività elementare presente nel WF System, attraverso le attività di base di cui si compone.
4. Descrizione degli attributi specificanti le variabili di processo
Descrivono l’insieme di proprietà caratteristiche di una componente e specificano le variabili di processo per ogni attività ed ogni manufatto.
5. Verifica del modello di processo
Controlla che nel processo non vi siano inconsistenze. Le verifiche sono statiche (eseguite sulla descrizione del modello di processo) o dinamiche (eseguite su un modello di simulazione dell’esecuzione del modello descritto; consistenza comportamentale). Manufatti: consistenza globale; WFD: consistenza globale e consistenza strutturale; Scenari Procedurali: consistenza dei manufatti e consistenza isomorfica.
Caratteristiche: attività (da eseguire per raggiungere gli obiettivi del processo), ruoli, competenze (di coloro che sono coinvolti), contesto (caratteristiche dell’ambiente e dell’organizzazione esecutrice), struttura e natura dei manufatti, tools, scenario procedurale (passi elementari da eseguire per coordinare gli agenti assicurando correttezza e completezza).
Software Process Engineering Metamodel (SPEM) è un meta-modello ovvero un linguaggio di modellazione di processi che adotta l’approccio object-oriented. SPEM supporta gli stessi elementi strutturali previsti da FSP.
FSP-SPEM based è un linguaggio che nasce dalla fusione di FSP e di SPEM. È un linguaggio di modellazione dei processi secondo il paradigma FSP fondato sull’utilizzo di UML opportunamente stereotipato nel profilo SPEM.
FSP-SPEM based estende dunque FSP secondo i principi della programmazione Object Oriented per aumentarne la potenza espressiva, al fine di poter descrivere tutte le componenti e caratteristiche tipiche di un processo.
Per meglio rappresentare tutte le soluzioni delle diverse aziende coinvolte nel progetto si è scelto di utilizzare come linguaggio il Formal Structured Planning e come meta-modello Software Process Engineering Metamodel (SPEM).
Un processo descritto in FSP-SPEM based è identificato da un package Process che ha lo stesso nome del processo e contiene al suo interno altri package di tipo ProcessComponent che realizzano la ripartizione della descrizione del processo in parti autonome rendendo possibile il loro riutilizzo.
In FSP-SPEM based possiamo distinguere tre componenti fondamentali del modello di processo:
• il ProcessComponent “Manufatti”;
• il ProcessComponent “Attori”;
• il Package “Workflow System”.
Il ProcessComponent “Manufatti” contiene l’insieme dei manufatti che fanno parte del modello di processo; per ogni manufatto T descrivibile come composizione di altri sotto-manufatti esiste un diagramma di dipendenza che indica tutti i sotto-manufatti che lo compongono.
Il ProcessComponent “Attori” è costituito dall’insieme degli attori che interagiscono col processo e dunque dai ProcessRole responsabili dell’esecuzione delle fasi e delle attività che compongono il modello di processo.
Il Package “Workflow System” contiene l’insieme delle WorkDefinition, delle Activity e degli Step presenti nel processo e l’insieme dei Workflow Diagram ovvero dei diagrammi di attività che determinano il comportamento del processo. Il package è costituito da:
• un diagramma di attività principale, che ha il nome del processo e rappresenta il livello di astrazione zero;
• per ogni WorkDefinition un diagramma di attività che la dettaglia;
• per ogni Activity un diagramma di attività degli Step che la descrivono.