UNIVERSITÀ DEGLI STUDI DI BARI FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI CORSO DI LAUREA IN INFORMATICA E TECNOLOGIE PER LA PRODUZIONE DEL SOFTWARE Tesi di laurea in Gestione della conoscenza di impresa ORCHESTRAZIONE DI RISORSE UMANE NEL BPM Gestione dinamica feature-based delle organizzazioni nella piattaforma openwork® Relatore: Prof. Giovanni Semeraro Correlatore: Dott. Gianpiero Bongallino Candidato: Michele Filannino Anno accademico 2007-2008
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
UNIVERSITÀ DEGLI STUDI DI BARI
FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI
CORSO DI LAUREA IN INFORMATICA E TECNOLOGIE PER LA
PRODUZIONE DEL SOFTWARE
Tesi di laurea in
Gestione della conoscenza di impresa
ORCHESTRAZIONE DI RISORSE UMANE NEL BPM Gestione dinamica feature-based delle organizzazioni nella
piattaforma openwork®
Relatore:
Prof. Giovanni Semeraro
Correlatore:
Dott. Gianpiero Bongallino
Candidato:
Michele Filannino
Anno accademico 2007-2008
2
3
Indice
Indice delle figure .......................................................................... 6
Mapping ........................................................................................................................................ 56 Diagramma dei casi d’uso..................................................................................................... 58
6.2.2 Dettaglio casi d’uso .................................................................... 59
1. Show Dynamic Groups ...................................................................................................... 59 2. Delete Unused Dynamic Groups ................................................................................... 60 3. Create Dynamic Group ...................................................................................................... 61 4. Update Dynamic Group .................................................................................................... 62 5. Link Dynamic Group to Activity ................................................................................... 63 6. Formal Control of Accuracy ............................................................................................ 64 7. Publish Model ........................................................................................................................ 65
5
8. Request Access ..................................................................................................................... 66 9. Verify affiliations of dynamic group ........................................................................... 67 10. Affiliated Users of a Dynamic Group ....................................................................... 68
documentale, componenti aggiuntive e Business Process
Management Tools (BPM Tools®).
Figura 5: Architettura del framework openwork®
Le openwork® business components, l'openwork® manager e
openwork® job engine formano il core della piattaforma
denominata: openwork® engine.
32
Tutti i moduli possono essere configurati in differenti modalità a
seconda dell'architettura prescelta e dei requisiti di performance,
ridondanza e sicurezza richiesti al sistema.
Ogni singolo modulo può essere installato su un solo server o
scalato su più server e presenta caratteristiche di scalabilità
derivanti dalla particolare tecnologia software utilizzata: i
componenti possono essere installati su un array di server, vi
possono essere più web server che utilizzano gli stessi componenti,
etc.
Poiché il sistema nel suo complesso (configurazione e dati) è
costituito da uno o più database relazionali e da un insieme di file,
esso è compatibile con le più diffuse soluzioni di backup, protezione
dati e monitoraggio disponibili sul mercato.
È possibile configurare i diversi moduli in modo da gestire con un
unico engine, database diversi e repository diversi ovvero
organizzazioni diverse. Tale configurazione prende il nome di
modalità ASP.
Non si pretende in questo documento di coprire tutti gli aspetti
del framework, per questa ragione di seguito si approfondiranno
esclusivamente gli aspetti coinvolti nel lavoro di ricerca.
3.3.1 BPM Tools®
Una delle principali componenti del framework openwork® è il
BPM Tools®. È un’applicazione proprietaria Windows che mette a
disposizione degli utilizzatori di openwork® un insieme di
strumenti grafici attraverso i quali costruire applicazioni di BPM
web-based.
I principali strumenti dell'openwork® Business Process
Management Tools sono:
Organization Designer per la gestione dell’organigramma / funzionigramma;
Form Editor per il disegno del layout delle form;
Business Flow Designer per la modellazione dei processi che si intendono gestire.
33
L'utilizzo del BPM Tools® favorisce la costruzione di applicazioni
che fanno riferimento al “linguaggio” ed ai contenuti
dell’organizzazione aziendale, in modo da rendere il più naturale
possibile la traduzione delle operazioni in una forma processabile a
livello informatico.
Gli strumenti di classificazione e numerazione documentale sono
strutturati sulla base di archivi totalmente associabili agli archivi
cartacei usuali e si conformano anche alle normative che regolano il
protocollo informatico.
I processi vengono configurati mediante appositi diagrammi di
flusso in cui è possibile rappresentare un’ampia gamma di attivit{
(semilavorati) che richiamano le usuali mansioni di gestione
documentale ed operativa.
L'organigramma degli operatori di sistema è composto da aree
organizzative, gruppi di lavoro e ruoli che in generale rispecchiano la
reale organizzazione aziendale, in altri casi invece è necessario
adattare l'organigramma alle esigenze del processo.
Un’interfaccia grafica particolarmente intuitiva e user-friendly
consente di velocizzare i tempi del design-time: inoltre,
conformemente alla flessibilità che contraddistingue la piattaforma,
le mutue relazioni tra documentazione, flusso operativo ed organico
delle risorse vengono gestite autonomamente in maniera dinamica e
coerente.
Questo rende openwork® BPM Tools® non solo il principale
strumento per configurare il sistema, ma anche un valido supporto
per l’analisi ed il re-engineering organizzativo.
Figura 6: Architettura del BPM Tools®
34
3.3.1.1 Organization Designer
L'organizzazione è l'insieme di operatori, ruoli, unità
organizzative che concorrono alla gestione delle informazioni e
all'avanzamento dei processi. Attraverso l’Organization Designer è
possibile definire relazioni gerarchiche tra i vari elementi
dell'organizzazione, ovvero definire l'organigramma. E' possibile
raggruppare i diversi elementi dell'organizzazione in base a
competenze, abilità, autorizzazioni specifiche, ovvero definire gruppi
o insiemi di operatori, ruoli e unità organizzative. Combinando
elementi dell’organigramma e gruppi è possibile definire regole
organizzative (formule) che dipendono da come un operatore è
posizionato nella gerarchia (ruolo) e/o dalla sua appartenenza a un
determinato gruppo (regole a matrice). I risultati delle
formule possono essere utilizzati da altre applicazioni per la
risoluzione di autorizzazioni oppure per stabilire l’accesso alle
informazioni e assegnare le attivit{ all’interno della piattaforma
openwork®.
Un operatore è identificato da un individuo (o risorsa) interno
all'organizzazione aziendale e definito nell'anagrafica degli
operatori; ad ogni operatore possono essere assegnati uno o più
ruoli.
3.3.1.2 Form Designer
Con il Form Designer è possibile disegnare form per la
rappresentazione dei dati utilizzando, oltre ad oggetti standard web
(controlli standard HTML) anche una collezione completa di
controlli openwork® che permettono di creare facilmente interfacce
evolute per la gestione dei dati nell’ambito dei processi di
un’organizzazione.
3.3.1.3 Business Flow Designer
Il Business Flow Designer fornisce strumenti grafici con i quali è
possibile definire la sequenza logica e temporale di attività,
35
stabilendo chi può fare cosa, come, con quali documenti,
autorizzazioni, etc.
Il Business Flow Designer integra un ambiente di
programmazione in linguaggio VB Script con il quale è possibile far
eseguire, dal motore di workflow, codice custom (lato server) al
verificarsi di determinati eventi (avvio, esecuzione o completamento
di un’attivit{, etc.) o condizionare il completamento di un’attivit{ al
verificarsi di determinate condizioni.
Questa funzionalità, unitamente alle API di openwork®, permette
di interagire con applicazioni esterne, realizzando un'unica
infrastruttura di workflow.
3.3.2 Web Client
L’applicazione Web è costituita da una applicazione lato server e
da librerie lato client in XSL, Java Script e CSS (thick client).
L’applicazione Web lato server è una delle possibili applicazioni
client basate sui Web Services di openwork®.
L' architettura segue rigorosamente il principio della separazione
tra dati e presentazione; il flusso di seguito descritto semplifica
quello che normalmente accade quando il client inoltra una richiesta
al Web Server:
Il client richiede al Web Server l’apertura di una form;
Il Web Server chiede ad un opportuno Web Service i dati con
cui la form deve essere riempita per mezzo di una chiamata
SOAP;
Il Web Service restituisce i dati al Web Server;
Nei dati è presente il riferimento a un foglio di stile in cui sono
codificate le regole per la rappresentazione dei dati richiesti
(tali regole vengono definite tramite openwork® BPM Tools®
durante la modellazione del processo e delle form in esso
coinvolte); il Web Server verifica se il foglio di stile è presente
nella directory dell’applicazione e, qualora non lo fosse, lo
richiede tramite chiamata ad altro Web Service;
Il Web Server invia al client i dati e il foglio di stile, che
vengono presentati sotto-forma di pagina web nel browser.
36
Nel momento in cui si effettuano delle modifiche nella form e
queste vengono salvate, il percorso è il seguente:
Il client invia al Web Server un messaggio SOAP contenente i
dati modificati unitamente ad eventuali allegati in formato
DIME da salvare nel repository documentale.
Il Web Server provvede a instradarli, tramite ws-addressing e
ws-referral, al Web Service.
I dati indicizzati (contenuti nei vari campi della form) vengono
memorizzati nel database, gli eventuali allegati vengono
memorizzati nel repository.
Quando il client richiede la stampa di una form o di un elenco,
viene invece eseguita una trasformazione lato server con l' utilizzo di
Formatting Objects per la produzione di documenti in formato PDF
secondo regole definite con openwork® BPM Tools®. Tramite il
meccanismo delle trasformazioni è possibile convertire i documenti
di openwork® in diversi altri formati come Microsoft Word® o
Microsoft Excel® (cfr. openwork® Export).
L’applicazione web lato server è attualmente realizzata in
tecnologia Microsoft .NET per server Microsoft IIS versione 5 o
successiva. È inoltre possibile, con estrema facilità, estendere i
moduli Java Script lato client con codice custom ed anche modificare,
attraverso fogli di stile, il layout grafico dell'applicazione. La
disposizione delle directory sul Web Server è studiata in modo da
separare i moduli proprietari da eventuali personalizzazioni (CSS,
codice Java Script, etc.) per semplificare le operazioni di
manutenzione dell’applicazione. Il protocollo utilizzato nelle
comunicazioni può essere HTTP o HTTPS.
Possono essere installati diversi Web Server sulla stessa
Application che espongono anche politiche di autenticazione diverse;
i web server comunicano con i web service tramite HTTP o HTTPS e
possono essere impostati meccanismi di Load Balancing come NLB.
È possibile quindi multi-istanziare sia l' interfaccia applicativa (Web
Services), sia il motore (in modalità separazione di carico).
37
Capitolo 4:
Analisi del problema
“Un’idea, un concetto, un’idea
finché resta un’idea è soltanto un’astrazione”
Giorgio Gaber
Si introduce, con questo capitolo, il problema aziendale oggetto di
questa tesi. Quello che segue è un documento che presenta diversi
scenari e soluzioni assieme ad una discussione delle scelte adoperate
considerando i diversi fattori critici: costo, tempo, benefici, numero
di risorse impiegate.
4.1 Modello di processo
La piattaforma openwork® adotta, come standard per il disegno
di modelli di processo, il BPMN (7). Per questa ragione, un modello
di processo altro non è che l’insieme di oggetti di flusso (flow
objects), oggetti di connessione (connecting objects), artefatti
(artifacts) e corsie (swimlanes).
Per disegnare un nuovo modello di processo, la piattaforma
openwork®, mette a disposizione lo strumento Business Flow
Designer.
38
L’utente modellatore, utilizzando una apposita palette di
strumenti, disegna graficamente un modello di processo
arricchendolo delle opportune informazioni correlate (alle attività
assocer{ gli opportuni partecipanti) e salvandolo. Quello che l’utente
salva è l’insieme di tutte le informazioni necessarie a mantenere
consistente il modello di processo: quando l’utente decide di caricare
un modello di processo precedentemente salvato, la piattaforma
deve essere in grado di visualizzarlo così come era sto costruito
dall’utente modellatore.
Nella nuova generazione di openwork® viene enfatizzata la
dicotomia esistente tra le tipologie di informazioni, quali:
1 Informazioni che servono e sono inserite a design-time (es. posizione di un nodo grafico).
2 Informazioni inserite a design-time che servono a run-time (es. URL di un servizio web da consumare).
3 Informazioni inserite a design-time che possono essere modificate a run-time (es. descrizione di un’attivit{).
4 Informazioni di istanza (es. stato di una attività). Dalla diversa natura di tali informazioni si definiscono le seguenti
entità:
Process Model: modello di processo contenente tutte quelle informazioni inserite a design-time, dalle proprietà di un nodo grafico ad informazioni di esecuzione.
Executable Model: modello di processo eseguibile. Contiene tutte quelle informazioni necessarie all’esecuzione di un modello di processo (per esempio le informazioni di disegno non sono necessarie alla esecuzione e quindi non saranno contenute). Tale modello sarà istanziato per essere eseguito. Un Executable Model è infatti una sorta di modello di processo compilato.
Process Instance: modello eseguibile istanziato. Ai parametri formali caratterizzanti il modello di processo vengono sostituiti quelli attuali.
La suddetta divisione ha come fine ultimo il miglioramento delle
performance relative all’esecuzione dei processi.
Il modello descritto imita quello dei linguaggi di programmazione
object-oriented e sarà parte integrante della nuova generazione di
openwork®.
39
4.2 Organizzazione
openwork® consente di definire il concetto di partecipante in
molteplici modi. In particolare esso introduce una lista di tipologie di
elementi dell’organizzazione ognuno con una semantica ben precisa.
La piattaforma, nella sua versione attuale, mette a disposizione
dell’utente responsabile della gestione dell’organigramma i seguenti
elementi:
Unità Organizzativa: Questa componente corrisponde ad
un’area o divisione aziendale (es. Area Marketing). Essa
può contenere a sua volta delle altre Aree Organizzative o
dei Ruoli oppure entrambe le cose;
Ruolo: Rappresenta la figura professionale e può essere
inserita solo in un’Area Organizzativa (es. responsabile,
direttore, sviluppatore, operaio). Ogni Ruolo può contenere
a sua volta solo elementi di tipo Operatore;
Operatore: Questa componente indica la persona fisica (es.
Mario Rossi) che ricopre un Ruolo in una Unità
Organizzativa;
Gruppo: È un contenitore di tutti i precedenti elementi
descritti.
Il problema fondamentale di questa suddivisione è la natura
statica di ogni entità organizzativa.
L’organizzazione viene rappresentata da un albero n-ario avente
per radice un nodo fittizio: l’azienda. L’utilizzo di questo tipo di
struttura conferisce un indubbio beneficio in termini di lettura della
organizzazione, a scapito, tuttavia, della flessibilità della struttura
stessa.
In una organizzazione estremamente dinamica, sovente capita
che un operatore (persona fisica) rivesta più ruoli anche in differenti
unità organizzative. Con la struttura ad albero per adempiere a
questa incombenza è necessario introdurre ridondanza informativa.
In definitiva, la struttura ad albero rivela tutta la sua rigidità in
contesti aziendali dinamici come le Banche, le Holding etc…
Il problema della rigidità si riflette direttamente nel disegno di un
modello di processo, poiché nell’associare le singole attivit{ ad un
entit{ organizzativa, l’utente modellatore potr{ incorrere più
facilmente in errore a causa dell’eccessiva ridondanza informativa.
40
Egli potrebbe non essere in grado di cogliere la giusta differenza tra i
diversi tipi di entit{ organizzative da coinvolgere per l’esecuzione di
un’attivit{.
4.3 Cos’è un gruppo dinamico
Prima di introdurre la definizione di Gruppo Dinamico è doveroso
illustrare l’assunto teorico di partenza.
Nella realizzazione di questo sistema si è assunto che l’atto di
assegnazione di una qualsivoglia attività ad una persona (o un
gruppo di persone) avviene sulla base delle capacità e competenze di
quella persona (o gruppo di persone).
Quando un manager assegna l’attivit{ X all’operatore Y,
implicitamente sta analizzando le capacità di Y per capire se è in
grado di eseguire l’attivit{ X. Se l’assegnazione viene effettuata
significa che il manager ritiene l’operatore Y capace di eseguire
l’attivit{ X.
Un gruppo dinamico è un particolare contenitore di entità
organizzative eterogenee. Esso corrisponde ad una regola formale.
Tutte le entit{ organizzative che sono contenute all’interno di un
particolare gruppo dinamico devono soddisfare la regola formale.
Una regola formale è una espressione che utilizza gli operatori logici,
aritmetici e di confronto per la concatenazione di condizioni,
espresse sulle caratteristiche informative di ciascun entità
organizzativa (gli operandi).
All’utente (che utilizza il Business Flow Designer) deve essere
data la possibilit{ di associare ad un’attivit{ di un modello di
processo, un gruppo dinamico. In particolare, l’utente potr{
esprimere la volont{ di assegnare una particolare attivit{ ad “un
partecipante che soddisfi determinate caratteristiche”; vale a dire
“un partecipante che osservi una precisa regola”; in altri termini “un
gruppo dinamico”.
Quando l’utente disegner{, utilizzando il Business Flow Designer,
un’attivit{ (in un modello di processo) potr{ scegliere di associare ad
essa una delle formule già inserite, oppure definirne una nuova ad
hoc. A questo scopo, sar{ messo a disposizione dell’utente
modellatore, un repository di formule. Il repository conterrà tutte le
formule in precedenza inserite in tutti i modelli di processo. Nel caso
in cui l’utente modellatore abbia la necessit{ di esprimere una nuova
41
espressione, egli potr{ farlo utilizzando l’apposita interfaccia guidata
di creazione di una nuova espressione.
L’utente (che utilizza il Business Flow Designer) potrà modificare
la definizione di un gruppo dinamico. In questo caso all’utente verr{
chiesto se sovrascrivere le modifiche sullo stesso modello di
processo oppure creare un nuovo modello di processo. Questa scelta
trova il suo fondamento, nel fatto che “cambiare i partecipanti
assegnati ad un’attivit{”, concettualmente significa stravolgere la
semantica del modello di processo.
Il modello di processo, su qualsiasi piattaforma venga disegnato,
conterrà la definizione dei gruppi dinamici coinvolti. Ogni
piattaforma mette a disposizione una serie di informazioni che
possono essere utilizzate (sulle entità organizzative) nella
definizione di una espressione di gruppo dinamico. A tal proposito
non è detto che la definizione di un gruppo dinamico in un modello
di processo importato (da qualsivoglia piattaforma) possa essere
valido nella piattaforma ospite. All’atto dell’importazione il modello
di processo viene importato senza alcun controllo sulla correttezza
del gruppo dinamico. Questo perché l’importazione di un modello di
processo ha come fine ultimo la visualizzazione del processo e non la
sua esecuzione.
La volontà di eseguire un processo (modello di) si palesa nel
momento in cui l’utente decide di pubblicarlo. Prima della
pubblicazione effettiva, il sistema controllerà la correttezza formale
dell’espressione che rappresenta il gruppo dinamico e potranno
presentarsi i seguenti scenari:
Il sistema (Application Server) controlla l’espressione e restituisce esito positivo. Il sistema pubblica il processo correttamente.
Il sistema (Application Server) controlla l’espressione e restituisce esito negativo poiché essa contiene degli errori. Il sistema comunica la sospensione della pubblicazione imputandola ad un errore nella espressione e non pubblicando il processo.
Condizione necessaria e sufficiente, affinché un modello di
processo (che coinvolge un gruppo dinamico) possa essere
pubblicato regolarmente, è che il modello di processo sia
consistente. Tutte le informazioni che servono al modello di
42
processo per la sua pubblicazione devono essere disponibili; pena: la
mancata pubblicazione dello stesso.
Nel caso in cui sia rilevato un errore, l’utente dovr{ essere
guidato nell’associazione dei partecipanti alle attivit{, attraverso un
wizard che permetta di reimpostare i punti errati di definizione, in
base alle entità organizzative ed alla lista di informazioni utilizzabili
su ciascun entità organizzativa presente sulla piattaforma di
destinazione. A discrezione dell’utente, le regole di associazione
devono essere disponibili anche nell’importazione dei successivi
processi. Dovrà essere possibile salvare le scelte intraprese per una
singola importazione ed applicarle ad una successiva importazione.
Altri esempi di definizione dei gruppi basati sulle caratteristiche
dei partecipanti sono specificati nel documento (8) in cui un
partecipante associato ad un’attivit{ è concepito come risorsa.
Gruppo dinamico in un Process Model
Il Process Model dovrà contenere tutte le informazioni necessarie
per eseguire ma anche manipolare un gruppo dinamico.
In particolare è necessario che un Process Model contenga il
nome del gruppo, una descrizione testuale e l’espressione che lo
definisce (formalizzata in XML).
Gruppo dinamico in un Executable Model
L’Executable Model conterrà le stesse informazioni del Process
Model, tuttavia l’espressione contenuta in questo modello non sar{
formalizzata in XML ma convertita nel formalismo utilizzato dal
processore di espressioni della generazione futura di openwork®.
Gruppo dinamico in una Process Instance
L’unica informazione circa il gruppo dinamico che deve essere
disponibile in una Process Instance è l’espressione che definisce il
gruppo. Tuttavia questa informazione deve poter essere ereditata
dall’Executable Model. Se così non fosse mentre la definizione del
gruppo cambia, tutti le attività che hanno come partecipante quel
gruppo, continuerebbero ad essere assegnate ad un gruppo
Resource abstraction – fornisce una interfaccia commune
per il trattamento di InputStream da un file e da un URL in
maniera polimorfica ed indipendente da protocollo.
4.5 Riflessioni
Valutazione dell’espressione
In generale la valutazione dell’espressione di un gruppo dinamico
va fatta in late binding (il più tardi possibile) per evitare che
un’attivit{ venga assegnata ad un insieme di partecipanti attivi che
non soddisfa più le condizioni del gruppo dinamico. Più
45
specificatamente, la collezione di partecipanti (potenziali o reali)
deve essere risolta all’atto dell’esecuzione di una attività e
modificabile all’intervento dell’Amministratore.
Figura 7: Eventi per un'attività openwork®
Nella Fig. 7 sono indicati gli eventi di un’attivit{ nei quali è
possibile intervenire. L’evento ultimo nel quale poter intervenire
utilmente al fine di valutare l’espressione di un gruppo dinamico è
l’After Activate, poiché nella fase di After Booking è già stata
assegnata l’attivit{ ad un insieme di partecipanti attivi. Il problema
della scelta, tuttavia, non è risolvibile in questo modo.
Un’attivit{ può rimanere in stato di prenotazione anche per tempi
lunghi (a volte anche per mesi!). In questi casi il sistema
prenoterebbe l’attivit{ ad una serie di partecipanti attivi che in quel
momento soddisfano il gruppo dinamico. Dopodiché l’attivit{ rimane
in prenotazione per N mesi. Dopo questo lungo periodo, un
partecipante attivo prende in carico l’attivit{ e la esegue e
successivamente la completa. Dopo N mesi non è detto che quel
partecipante attivo che la prende in carico soddisfi ancora i requisiti
del gruppo dinamico.
Una possibile soluzione consiste nel valutare l’espressione del
gruppo dinamico nel momento in cui il singolo partecipante attivo
richiede la propria To-Do List al Web Server. In questo caso il sistema
dovrà preoccuparsi di estrarre il sottoinsieme delle istanze di
processo attive che coinvolgono gruppi dinamici. Di questi estrarre il
sottoinsieme di quelle istanze di processo che hanno attività in fase
di After Activate che coinvolgono gruppi dinamici. Valutare ogni
gruppo dinamico e verificare che il partecipante attivo “richiedente”
non sia coinvolto in una di quelle attività.
46
Malgrado si vada ad appesantire il carico computazione, questa
risulta essere l’unica soluzione ragionevole per garantire che la
coerenza di ogni singolo gruppo dinamico.
Eliminazione di un gruppo dinamico
L’eliminazione di un gruppo dinamico non è consentita. L’unica
eliminazione possibile è quella relativa all’associazione tra attivit{ e
gruppo dinamico. L’utente modellatore ha la possibilit{ di
disassociare un’attivit{ da un particolare gruppo dinamico ed
associarlo con un altro o nessuno.
Quantunque ciò avvenisse, tutte le attività modificate si
aggiornerebbero in automatico senza alcun problema.
In nessun modo l’utente modellatore ha facolt{ di cancellare un
gruppo dinamico dal repository della piattaforma.
Gruppo dinamico privo di elementi
Può succedere che la definizione di un gruppo dinamico non
contenga effettivamente alcun’entità organizzativa. Questo accade,
ad esempio, quando nessun’entit{ risponde alle caratteristiche
descritte in fase di definizione del gruppo. In questo caso, essendo il
gruppo “dinamico”, non ci sono problemi. L’attivit{ che ha come
partecipante quel gruppo, non sarà eseguita da nessuno e rimarrà in
attesa di un partecipante attivo in eterno a meno che durante l’attesa
qualche entità organizzativa soddisfi i requisiti del gruppo dinamico
o l’amministratore del processo modifichi l’istanza di processo.
In questo caso, si nota subito, l’importanza che la definizione di
gruppo dinamico venga risolta il più tardi possibile: in late-binding.
Cambiamento del set di attributi utilizzabili
Cambiare l’insieme di attributi utilizzabili all’interno di una
piattaforma openwork® significa aggiungere e/o rimuovere uno o
più attributi dalla lista di quelli consentiti. Questo tipo di operazione
impatta, inevitabilmente, sul meccanismo di valutazione
dell’espressione dei gruppi dinamici. Se in un dato momento,
cambiassimo il set di attributi, le ripercussioni potrebbero essere:
47
La definizione di taluni gruppi dinamici diverrebbe sintatticamente errata (negli attributi o negli operatori), generando errori. Si potrebbe rilanciare il controllo di correttezza formale per ogni gruppo dinamico, dopo la modifica del set di attributi.
La definizione di taluni gruppi dinamici rimarrebbe sintatticamente valida. Non verrebbero generati errori.
48
Capitolo 5:
Analisi dei requisiti
Dopo aver analizzato a fondo la problematica in maniera astratta
con uno studio di fattibilit{, si passa ora all’analisi dei requisiti.
Obiettivo di questo documento è quello di identificare e descrivere i
requisiti, ossia le caratteristiche del sistema.
In questo documento è opportuno cogliere le esigenze del
committente senza ignorare quelle del progettista. Il documento
deve essere facilmente comprensibile, preciso, completo coerente e
non ambiguo inoltre facilmente modificabile.
La caratteristica di questo documento è il suo duplice indirizzo.
L’analisi dei requisiti di solito viene sottoposta all’approvazione del
committente e successivamente consegnato al progettista per
avviare la fase di progettazione software.
Nel caso specifico, la problematica analizzata è talmente
innovativa e priva di riferimenti esterni che è stato necessario
rielaborare il documento più volte del previsto. Quello che trovate di
seguito, è pertanto, il documento finale frutto di numerose iterazioni
revisionali.
Il modello documentale utilizzato per la redazione dell’analisi dei
requisiti è il frutto di una fusione tra il modello accademico e gli
standard interni della Net Sistemi srl. Tutti i codici presenti nel
documento trovano una loro precisa semantica negli standard
aziendali.
49
5.1 Requisiti
Di seguito si espongono i diversi requisiti che la futura
applicazione software deve osservare.
Concordemente agli standard aziendali, i requisiti sono stati
classificati in nove diverse categorie:
Requisiti Funzionali: Descrivono le funzionalità ed i servizi
offerti dal prodotto software;
Requisiti Informativi: Descrivono le informazioni che il
prodotto software deve essere in grado di gestire;
Requisiti di Interfaccia: Descrivono le caratteristiche
richieste per la realizzazione delle interfacce utente;
Requisiti di Manutenzione: Descrivono eventuali vincoli di
manutenzione da segnalare immediatamente in fase di
analisi;
Requisiti di Prestazione: Descrivono alcuni vincoli sulla
definizione del sistema software che impattano sulle
prestazioni dello stesso;
Requisiti di Piattaforma: Descrivono eventuali
accorgimenti, evidenziabili già in fase di analisi, derivanti
dall’utilizzo di una particolare piattaforma;
Requisiti di Sicurezza: Descrivono i vincoli relativi alla
sicurezza del futuro sistema software;
Requisiti di Integrazione: Descrivono i vincoli che
dovrebbero poter essere imposti in fase di integrazione
del prodotto software con un sistema software.
Requisiti Tecnici: Descrivono eventuali altri requisiti.
Funzionali [FUN]
OWK-FUN-0001
Creare Gruppi Dinamici
L’utente (utilizzatore di BPM Tools®) avrà la possibilità di creare
nuovi gruppi detti “gruppi dinamici” specificando nome,
descrizione ed un insieme di condizioni (attributo-operatore-
valore). Le condizioni devono essere composte con operatori logici
AND e OR. Il set di attributi utilizzabili può cambiare nel tempo.
OWK-FUN-0002 Eliminare Gruppo Dinamico
Il server, allo scatenarsi di un particolare evento (ad es. la
50
pubblicazione di un processo) provvederà ad eliminare i gruppi
dinamici inutilizzati.
OWK-FUN-0003
Associare Gruppo ad un’Attività
L’utente (utilizzatore di BPM Tools®) avrà la possibilità di
associare ad un gruppo dinamico precedentemente creato
un’attivit{.
OWK-FUN-0004
Visualizzare Elenco Gruppi Dinamici
L’utente (utilizzatore di BPM Tools®) avrà la possibilità di
visualizzare l’elenco di tutti i gruppi dinamici definiti.
OWK-FUN-0005
Modificare Gruppo Dinamico
L’utente (utilizzatore di BPM Tools®) avrà la possibilità di
modificare i gruppi dinamici precedentemente inseriti. L’utente
potrà modificare nome, descrizione ed espressione. Per “modifica
della espressione” si intende la cancellazione, e la modifica di ogni
singola condizione e l’inserimento di nuove condizioni.
OWK-FUN-0006
Controllo formale di correttezza
Prima della pubblicazione, il Server deve essere in grado di
controllare la correttezza della definizione di un gruppo dinamico.
Un gruppo dinamico si dirà corretto quando gli operatori logici
saranno ben bilanciati e quando tutti gli attributi coinvolti saranno
validi per la piattaforma in uso. Un attributo si dirà valido rispetto
alla piattaforma, quando il suo uso è ammesso in quella
piattaforma.
OWK-FUN-0007
Richiedere informazioni sulle attività che coinvolgono
l’utente nei gruppi dinamici
L’utente (utilizzatore dell’interfaccia Web Client) all’atto della
richiesta di accesso al sistema, dovrà poter conoscere quali sono le
attività in carico (da svolgere) che lo coinvolgono in un gruppo
dinamico.
Informativi [INF]
OWK-INF-0001
Gruppo Dinamico
È la rappresentazione di tutte le informazioni che caratterizzano il
gruppo dinamico.
STRUTTURA:
- identificativo, nome, descrizione, espressione;
RELAZIONI:
- Attività(1 .. 1)
OWK-INF-0002
Attività
È l’insieme delle informazioni che caratterizzano una singola
attività.
STRUTTURA:
- identificativo, …
RELAZIONI:
- Attività (1 .. )
51
Interfaccia [IFC]
OWK-IFC-0001
Gruppi Dinamici
L’interfaccia per la gestione dei Gruppi Dinamici deve essere
integrata nel Business Flow Designer.
OWK-IFC-0002 HCI Guidelines
L’interfaccia dovr{ essere compatibile con gli standard di HCI.
OWK-IFC-0003
Binding Attività-Gruppo Dinamico
L’interfaccia utente per l’assegnazione di un’attivit{ ad un gruppo
di persone dovrà essere integrata a quella già esistente per non
disorientare l’utente.
Manutenzione [MAN]
Nessuno
Prestazioni [PER]
Nessuno
Piattaforma [PLF]
OWK-PLF-0001
Modello di gruppo dinamico
È necessario scindere la definizione di un gruppo dinamico nelle tre
versioni del modello di processo: Model, Instance, Executable.
Sicurezza [SEC]
Nessuno
Integrazione [INT]
52
OWK-INT-0001
Eredità della localizzazione
Si deve essere in grado di adattare la lingua utilizzando le relative
componenti di localizzazione già realizzate.
OWK-INT-0002
Accesso alle entità organizzative
Si deve essere in grado di accedere alle entità organizzative definite
in BPM Tools®.
OWK-INT-0003
Visibilità della verifica di correttezza formale
Si dovrà esporre la funzionalità di verifica di correttezza formale
all’esterno.
OWK-INT-0004
Estensione del modulo di controllo
È necessario estendere il modulo di “ispezione errori” pre-
pubblicazione nel Business Flow Designer anche al controllo dei
gruppi dinamici.
OWK-INT-0005
Estensione del Business Flow Designer
È necessario estendere il Business Flow Designer anche
all’associazione di un’attivit{ al Gruppo Dinamico.
Tecnici [TEC]
OWK-TEC-0001
Framework di sviluppo
Il sistema dovrà essere realizzato utilizzando Microsoft Framework
2.0
OWK-TEC-0002
Lista degli attributi
La lista degli attributi sarà contenuta in un file XML con relativo
schema.
53
Capitolo 6:
Specifiche dei requisiti
6.1 Classi
In questa sezione si illustreranno i requisiti funzionali
precedentemente individuati e da questi si estrarrà un elenco di
classi candidate. Da queste si ricaverà un sotto-insieme proprio di
classi definitive.
6.1.1 Diagrammi
Mapping
Requisiti Funzionali Classi candidate
OWK-
FUN-
0001
Creare Gruppi Dinamici
L’utente (utilizzatore di BPM Tools®) avr{ la
possibilità di creare nuovi gruppi detti “gruppi
dinamici” specificando nome, descrizione ed un
insieme di condizioni (attributo-operatore-
valore). Le condizioni devono essere composte
con operatori logici AND e OR. Il set di attributi
utilizzabili può cambiare nel tempo.
- Gruppo Dinamico
- Attributo
OWK- Eliminare Gruppo Dinamico - Gruppo Dinamico
54
FUN-
0002
Il server, allo scatenarsi di un particolare evento
(ad es. la pubblicazione di un processo)
provvederà ad eliminare i gruppi dinamici
inutilizzati.
OWK-
FUN-
0003
Associare Gruppo ad un’Attività
L’utente (utilizzatore di BPM Tools®) avr{ la
possibilità di associare ad un gruppo dinamico
precedentemente creato un’attivit{.
- Gruppo Dinamico
- Attività
OWK-
FUN-
0004
Visualizzare Elenco Gruppi Dinamici
L’utente (utilizzatore di BPM Tools®) avrà la
possibilit{ di visualizzare l’elenco di tutti i gruppi
dinamici definiti.
- Gruppo Dinamico
OWK-
FUN-
0005
Modificare Gruppo Dinamico
L’utente (utilizzatore di BPM Tools®) avr{ la
possibilità di modificare i gruppi dinamici
precedentemente inseriti. L’utente potrà
modificare nome, descrizione ed espressione. Per
“modifica dell’espressione” si intende la
cancellazione, e la modifica di ogni singola
condizione e l’inserimento di nuove condizioni.
- Gruppo Dinamico
- Condizione
- Espressione
OWK-
FUN-
0006
Controllo formale di correttezza
Prima della pubblicazione, il Server deve essere in
grado di controllare la correttezza della
definizione di un gruppo dinamico. Un gruppo
dinamico si dirà corretto quando gli operatori
logici saranno ben bilanciati e quando tutti gli
attributi coinvolti saranno validi per la
piattaforma in uso. Un attributo si dirà valido
rispetto alla piattaforma, quando il suo uso è
ammesso in quella piattaforma.
- Gruppo Dinamico
- Attributo
OWK-
FUN-
0007
Richiedere informazioni sulle attività che
coinvolgono l’utente nei gruppi dinamici
L’utente (utilizzatore dell’interfaccia Web Client)
all’atto della richiesta di accesso al sistema, dovr{
poter conoscere quali sono le attività in carico (da
svolgere) che lo coinvolgono in un gruppo
dinamico.
- Gruppo Dinamico
- Attività
Raffinamento
Delle classi candidate precedentemente individuate è necessario
scartarne alcune per differenti motivi:
Condizione: non è propriamente una classe, ma
semplicemente un attributo della classe “Espressione”.
Attributo: non è propriamente una classe.
55
Classi definitive
Figura 8: Classi definitive
La classe Activity pur essendo stata inserita all’interno
dell’insieme delle classi definitive, è già presente nella piattaforma
openwork®.
56
6.2 Casi d’uso
6.2.1 Diagrammi
A partire dai requisiti funzionali si estraggono i casi d’uso.
Si ispezionano i requisiti funzionali al fine di far emergere le
funzionalità del sistema in relazione ad ogni singolo attore.
Mapping
Requisiti Funzionali Attore Caso d’uso
OWK-
FUN-
0001
Creare Gruppi Dinamici
L’utente (utilizzatore di BPM
Tools®) avrà la possibilità di creare
nuovi gruppi detti “gruppi dinamici”
specificando nome, descrizione ed un
insieme di condizioni (attributo-
operatore-valore). Le condizioni
devono essere composte con
operatori logici AND e OR. Il set di
attributi utilizzabili può cambiare nel
tempo.
Business Flow
Modeler
Creare un gruppo
dinamico
OWK-
FUN-
0002
Eliminare Gruppo Dinamico
Il server, allo scatenarsi di un
particolare evento (ad es. la
pubblicazione di un processo)
provvederà ad eliminare i gruppi
dinamici inutilizzati.
Application
Server
Eliminare gruppi
dinamici inutilizzati
OWK-
FUN-
0003
Associare Gruppo ad un’Attività
L’utente (utilizzatore di BPM
Tools®) avrà la possibilità di
associare ad un gruppo dinamico
precedentemente creato un’attivit{.
Business Flow
Modeler
Associare gruppo ad
un’attivit{
OWK-
FUN-
0004
Visualizzare Elenco Gruppi
Dinamici
L’utente (utilizzatore di BPM
Tools®) avrà la possibilità di
visualizzare l’elenco di tutti i gruppi
dinamici definiti.
Business Flow
Modeler
Visualizzare gruppi
dinamici
OWK-
FUN-
0005
Modificare Gruppo Dinamico
L’utente (utilizzatore di BPM
Tools®) avrà la possibilità di
Business Flow
Modeler
Modificare gruppo
dinamico
57
modificare i gruppi dinamici
precedentemente inseriti. L’utente
potrà modificare nome, descrizione e
condizioni. Per “modifica
dell’espressione” si intende la
cancellazione, e la modifica di ogni
singola condizione e l’inserimento di
nuove condizioni.
OWK-
FUN-
0006
Controllo formale di correttezza
Prima della pubblicazione, il Server
deve essere in grado di controllare la
correttezza della definizione di un
gruppo dinamico. Un gruppo
dinamico si dirà corretto quando gli
operatori logici saranno ben
bilanciati e quando tutti gli attributi
coinvolti saranno validi per la
piattaforma in uso. Un attributo si
dirà valido rispetto alla piattaforma,
quando il suo uso è ammesso in
quella piattaforma.
Application
Server,
Business Flow
Modeler
Controllare la
correttezza formale,
Pubblicazione del
processo
OWK-
FUN-
0007
Richiedere informazioni sulle
attività che coinvolgono l’utente
nei gruppi dinamici
L’utente (utilizzatore dell’interfaccia
Web Client) all’atto della richiesta di
accesso al sistema, dovrà poter
conoscere quali sono le attività in
carico (da svolgere) che lo
coinvolgono in un gruppo dinamico.
Business Flow
Modeler
Verifica
l’appartenenza ad
un gruppo
dinamico, Utenti che
appartengono ad un
gruppo dinamico
58
Diagramma dei casi d’uso
Figura 9: Diagramma dei casi d'uso
59
6.2.2 Dettaglio casi d’uso
1. Show Dynamic Groups
L’utente deve avere la possibilit{ di consultare l’elenco dei Gruppi
Dinamici inseriti nella piattaforma.
ACTORS
Business Flow Modeler.
USE CASE INTERACTION
Use Case Relation Direction
Link Dynamic Group to Activity Extend From
SCENARIO
Scenario di base
1. L’utente preme il pulsante relativo alla sezione dei Gruppi Dinamici, all’interno della finestra di assegnazione partecipanti nel Business Flow Designer;
PERCORSI ALTERNATIVI
None
REQUISITI TRACCIATI
OWK-FUN-0004
60
2. Delete Unused Dynamic Groups
L’Application Server, allo scatenarsi di uno specifico evento, deve
provvedere automaticamente a cancellare i gruppi dinamici
dichiarati nel modello di processo, ma non utilizzati da quest’ultimo.
ACTORS
Application Server.
USE CASE INTERACTION
Use Case Relation Direction
SCENARIO
Scenario di base
1. L’Application Server controlla il verificarsi di un determinato evento; 2. Quando l’evento si scatena, l’Application Server elimina tutte le definizione dei
gruppi dinamici superflui per il corrente modello di processo.
PERCORSI ALTERNATIVI
None
REQUISITI TRACCIATI
OWK-FUN-0002
61
3. Create Dynamic Group
L’utente deve avere la possibilità di inserire un Gruppo Dinamico
nella piattaforma.
ACTORS
Business Flow Modeler.
USE CASE INTERACTION
Use Case Relation Direction
Link Dynamic Group to Activity Extend To
Formal Control of Accuracy Include To
SCENARIO
Scenario di base
1. Il Business Flow Modeler preme il pulsante relativo al collegamento di un’attivit{ con i Gruppi Dinamici;
2. Il Business Flow Modeler preme il pulsante relativo all’inserimento di un nuovo Gruppo Dinamico;
3. Il Business Flow Modeler inserisce le informazioni richieste (lista di attributi e valori relativi);
4. Il Business Flow Modeler preme sul pulsante di conferma inserimento; 5. L’Application Server controlla la correttezza dei dati inseriti; 6. L’Application Server assegna il gruppo dinamico all’attività in esame.
PERCORSI ALTERNATIVI
Scenario alternativo
5. L’Application Server controlla la correttezza dei dati inseriti e notifica gli errori; 6. Il Business Flow Modeler reinserisce i dati in modo corretto; 7. L’Application Server assegna il gruppo dinamico all’attivit{ in esame.
REQUISITI TRACCIATI
OWK-FUN-0001
62
4. Update Dynamic Group
L’utente deve avere la possibilit{ di modificare un Gruppo
Dinamico inserito nella piattaforma.
ACTORS
Business Flow Modeler.
USE CASE INTERACTION
Use Case Relation Direction
Show Dynamic Groups Extend To
Formal Control of Accuracy Include To
SCENARIO
Scenario di base
1. Il Business Flow Modeler preme il pulsante relativo alla visualizzazione dei Gruppi Dinamici;
2. Il Business Flow Modeler preme il pulsante relativo alla modifica di un Gruppo Dinamico visualizzato;
3. Il Business Flow Modeler modifica le informazioni opportune (nome e/o condizioni); 4. Il Business Flow Modeler preme sul pulsante di conferma modifiche; 5. L’Application Server controlla la correttezza dei dati inseriti; 6. L’Application Server assegna il gruppo dinamico all’attivit{ in esame.
PERCORSI ALTERNATIVI
Scenario alternativo
5. L’Application Server controlla la correttezza dei dati inseriti e notifica gli errori; 6. Il Business Flow Modeler reinserisce i dati in modo corretto; 7. L’Application Server controlla la correttezza dei dati inseriti; 8. L’Application Server assegna il gruppo dinamico all’attivit{ in esame.
REQUISITI TRACCIATI
OWK-FUN-0005
63
5. Link Dynamic Group to Activity
L’utente deve avere la possibilità di associare un Gruppo
Dinamico inserito nella piattaforma ad un’attivit{ nel Business Flow
Designer.
ACTORS
Business Flow Modeler.
USE CASE INTERACTION
Use Case Relation Direction
Show Dynamic Groups Extend From
Update Dynamic Group Extend From
Create Dynamic Group Extend From
SCENARIO
Scenario di base
1. Il Business Flow Modeler accede al Business Flow Designer per gestire un modello di processo;
2. Il Business Flow Modeler seleziona l’attivit{ da sottoporre al gruppo dinamico; 3. Il Business Flow Modeler preme sul pulsante relativo all’indicazione dei partecipanti; 4. Il Business Flow Modeler selezione il gruppo dinamico desiderato; 5. L’Application Server associa l’attivit{ a quel gruppo dinamico.
PERCORSI ALTERNATIVI
None
REQUISITI TRACCIATI
OWK-FUN-0003
64
6. Formal Control of Accuracy
L’Application Server deve controllare la correttezza formale della
definizione di un Gruppo Dinamico. Un Gruppo Dinamico è
formalmente corretto quando gli operatori logici presenti nelle
condizioni sono ben bilanciati e quando le condizioni coinvolgono
attributi che sono utilizzabili sulla piattaforma. Ogni piattaforma può
utilizzare un set diverso di attributi. E’ necessario pertanto
controllare che la espressione del gruppo dinamico faccia
riferimento solo ad attributi che possono essere interpretati dalla
piattaforma.
ACTORS
Application Server.
USE CASE INTERACTION
Use Case Relation Direction
Create Dynamic Group Include From
Update Dynamic Group Include From
Publish Process Model Include From
SCENARIO
Scenario di base
1. L’Application Server controlla la correttezza formale del gruppo dinamico. 2. L’Application Server restituisce l’esito del controllo.
PERCORSI ALTERNATIVI
None
REQUISITI TRACCIATI
OWK-FUN-0006
65
7. Publish Model
Questo caso d’uso non è oggetto di questo documento. Per questa
ragione non verrà descritto.
ACTORS
Business Flow Modeler.
USE CASE INTERACTION
Use Case Relation Direction
Formal Control of Accuracy Include From
SCENARIO
None
PERCORSI ALTERNATIVI
None
REQUISITI TRACCIATI
None
66
8. Request Access
Questo caso d’uso non è oggetto di questo documento. Per questa
ragione non verrà descritto.
ACTORS
Web Client User.
USE CASE INTERACTION
Use Case Relation Direction
Verify affiliations of dynamic group Include To
SCENARIO
None
PERCORSI ALTERNATIVI
None
REQUISITI TRACCIATI
None
67
9. Verify affiliations of dynamic group
L’utente che utilizza il Web Client richiede l’accesso al sistema.
All’atto della richiesta dell’accesso al sistema, tra le tante
funzionalità che il sistema gli espone c’è quella di proporre la lista
delle attivit{ in carico. Questo particolare caso d’uso riguarda
l’insieme di quelle attivit{ proposte, che coinvolgono l’utente poiché
questi è parte di un gruppo dinamico associato ad un’attivit{ in
esecuzione. In particolare questo caso d’uso sta ad indicare la
funzionalit{ di verifica dell’appartenenza ad un gruppo dinamico.
Iterando questo procedimento per tutti i gruppi dinamici presenti, è
facile ottenere l’elenco di tutti i gruppi dinamici ai quali l’utente
appartiene.
ACTORS
Application Server.
USE CASE INTERACTION
Use Case Relation Direction
Request Access Include From
SCENARIO
Scenario di base
1. L’Application Server comunica all’esterno se l’utente richiedente fa o meno parte di
un particolare gruppo dinamico.
PERCORSI ALTERNATIVI
None
REQUISITI TRACCIATI
OWK-FUN-0007
68
10. Affiliated Users of a Dynamic Group
L’Application Server è in grado di valutare l’espressione di un
determinato gruppo dinamico ed estrarre una lista di partecipanti
attivi: tutti e soli quelli che soddisfano le condizioni del gruppo.
Questa attività è estremamente onerosa in termini di risorse
consumate e per questa ragione ha un limitatissimo campo di
applicabilità.
In generale questa funzionalità verrà utilizzata solo per
particolari tipi di attività che non costituiscono la maggior parte di
quelli in esecuzione.
ACTORS
Application Server.
USE CASE INTERACTION
Use Case Relation Direction
SCENARIO
Scenario di base
L’Application Server percepisce l’identificativo del gruppo dinamico.
L’Application Server valuta l’espressione contenuta nella definizione del Gruppo
Dinamico.
L’Application Server restituisce una lista di partecipanti che in quel preciso momento
soddisfa le particolari condizioni presenti nell’espressione del Gruppo Dinamico.
PERCORSI ALTERNATIVI
None
REQUISITI TRACCIATI
OWK-FUN-0007
69
Capitolo 7:
Conclusioni
Dopo aver studiato la fattibilità e dopo aver analizzato
formalmente il concetto di Gruppo Dinamico, esso è diventerà uno
dei punti cardine della prossima generazione di openwork®.
In particolare, ci si è resi conto, dopo una lunga fase di studio che
i Gruppi Dinamici sono stati definiti in maniera sufficientemente
generale da poter inglobare nella loro definizione altre forme di
organizzazioni oltre a quella gestita dall’attuale piattaforma.
Ciò significa che anche le restanti entità organizzative potranno
essere viste come un gruppo dinamico (espressione). Di fatto nella
prossima generazione di openwork® tutta l’organizzazione sar{
gestita come gruppo dinamico.
7.1 Possibili sviluppi futuri
Lo stage nella Net Sistemi srl è durato giusto il tempo necessario
per comprendere la logica dell’intera piattaforma, approfondire il
dominio applicativo (a me totalmente sconosciuto prima di allora) e
redigere un documento di analisi dei requisiti completo.
Per questa ragione, il naturale sviluppo di questa tesi consisterà
nel procedere con le restanti fasi del ciclo di sviluppo del software:
progettazione, codifica e test.
70
7.1.1 Uso trasversale delle espressioni
Un interessante sviluppo della soluzione precedentemente
illustrata è quello di estendere l’ambito di competenza delle
espressioni dai soli gruppi dinamici a tutte le entità presenti nella
piattaforma.
Oltre che poter utilizzare come operandi le sole entità
organizzative, in futuro potrebbe essere possibile utilizzare tutte le
entità coinvolte: documento, processo, attività e naturalmente
organizzazione.
I costi di realizzazione di una soluzione del genere impongono di
relegare l’idea nella sezione sviluppi futuri.
7.1.2 Information Retrieval
I gruppi dinamici, per come sono stati analizzati sono un fattore
chiave della futura generazione della piattaforma openwork® pur
tuttavia rimanendo ad un livello di elaborazione dati sintattico.
Un possibile sviluppo futuro, interessante e pioneristico,
potrebbe essere quello di integrare un motore di ricerca semantico
all’interno della piattaforma, che consentisse all’utente di scrivere
una semplice descrizione testuale del gruppo che vuole creare e
lasciare alla piattaforma il compito di trasformare quella descrizione
testuale in una espressione come accade oggi.
Si pensi all’utente che anziché destreggiarsi con espressioni
booleane, tipi di dati e altro, si cimenti nella scrittura di una
descrizione del gruppo in linguaggio naturale. La piattaforma, dotata
di un sistema di information retrieval, interpreterà il testo come
query e restituirà oggetti di dati strutturati che nel caso specifico
saranno le entità organizzative.
71
Appendice
72
A UML
In ingegneria del software, UML (Unified Modeling Language,
linguaggio di modellazione unificato) è un linguaggio di
modellazione e 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.
L’ultima versione del linguaggio, la 2.0, è stata consolidata nel
2004 e ufficializzata da OMG nel 2005. UML 2.0 riorganizza molti
degli elementi della versione precedente (1.5) in un quadro di
riferimento ampliato e introduce molti nuovi strumenti, inclusi
alcuni nuovi tipi di diagrammi. Sebbene OMG indichi UML 2.0 come
la versione corrente del linguaggio, la transizione `e di fatto ancora
in corso; le stesse specifiche pubblicate da OMG sono ancora non
completamente aggiornate e il supporto dei tool a UML 2.0 `e, nella
maggior parte dei casi, appena abbozzato.
73
A.1 Storia
I linguaggi per la modellazione object-oriented iniziarono a
svilupparsi in diversi contesti a partire dagli anni ’80. Si trattava di
notazioni di varia natura, che consentivano di descrivere la struttura
di un sistema software a oggetti (in termini di classi e relazioni fra
classi) ed eventualmente il suo comportamento dinamico. La
proliferazione di queste notazioni diede luogo a quelle che furono
poi battezzate guerre dei metodi (method wars), con diversi
progettisti, o organizzazioni, che adottavano e sostenevano una
particolare notazione a scapito di altre adottate altrove. Intorno alla
met{ degli anni ’90 diversi metodi e linguaggi iniziarono a fondersi, e
si iniziò a delineare la possibilità di una integrazione dei principali
formalismi in una notazione universalmente accettabile.
Fra le metodologie e le notazioni più apprezzate e diffuse del
periodo spiccavano OMT (Object Modeling Technique) di Jim
Rumbaugh, e il cosiddetto metodo Booch di Grady Booch, entrambi
ricercatori presso Rational Software. Il lavoro di unificazione iniziò
con loro; in seguito si un`ı a questo sforzo Jacobson con la sua
software house Objectory. Il primo risultato congiunto di questo
team fu OOSE (Ob ject Oriented Software Engineering).
Mentre i tre gringos operavano per unificare i propri approcci
all’analisi e alla progettazione a oggetti, il progetto fu accolto sotto
l’egida dell’OMG (Object Management Group), un consorzio fondato
con l’obiettivo di creare e gestire standard nel contesto dello
sviluppo del software a oggetti. Nel 1995, l’OMG raccolse tutti i
principali metodologisti del settore in un incontro internazionale per
discutere della notazione unificata. Nel 1996 l’OMG emise una RFP
(Request for Proposal) per tale notazione. Nello stesso anno, Booch,
Rumbaugh e Jacobson misero a punto le release 0.9 e 0.91 di UML. Il
progetto fu ben accolto dalla comunità internazionale e
innumerevoli grandi organizzazioni si unirono a Rational per
proseguirlo (per esempio Digital, Hewlett-Packard, IBM, Microsoft,
Oracle e Unisys). Questo gruppo esteso realizzò, nel 1997, UML 1.0,
che fu sottoposto alla OMG come risposta alla RFP dell’anno
precedente.
La release 1.1 di UML contribuì a consolidare la semantica del
linguaggio e incluse elementi tratti da una proposta avanzata
74
indipendentemente all’OMG da un gruppo composto da IBM,
ObjectTime, Ptech e altre.
A.2 Caratteristiche speciali
La notazione UML è semi-grafica e semi-formale; un modello UML
è costituito da una collezione organizzata di diagrammi correlati,
costruiti componendo elementi grafici (con significato formalmente
definito), elementi testuali formali, ed elementi di testo libero. Ha
una semantica molto precisa e un grande potere descrittivo.
Il linguaggio è stato progettato con l’obiettivo esplicito di
facilitare il supporto software alla costruzione di modelli e
l’integrazione di questo supporto con gli ambienti integrati di
sviluppo. OMG, in particolare, gestisce una famiglia di standard
correlata a UML, detta Model Driven Architecture (MDA), che ha lo
scopo di fornire le fondamenta concettuali e semantiche per lo
sviluppo di ambienti evoluti di roundtrip engineering in cui la
modellazione UML, in qualche misura, possa sostituire di fatto la
programmazione tradizionale. Sebbene questo obiettivo sia ancora
da raggiungere, molti IDE comprendono strumenti di modellazione
in UML e forniscono meccanismi automatici di traduzione parziale
dei diagrammi UML in codice e viceversa. Viceversa, molti ambienti
software dedicati alla modellazione in UML consentono di generare
codice in diversi linguaggi.
UML è un linguaggio di modellazione general purpose, che
fornisce concetti e strumenti applicabili in tutti i contesti. Poiché
particolari domini applicativi o famiglie di applicazioni potrebbero
aver bisogno di concetti ulteriori e specifici, UML fornisce un
meccanismo standard che consente di estendere il linguaggio. Una
estensione di UML per un particolare contesto viene detta un profilo
UML.
75
A.3 Applicazioni
Di per sé, UML è solo un linguaggio di modellazione, e non
definisce alcuna specifica metodologia per la creazione di modelli (o
alcun processo software). UML può quindi essere utilizzato nel
contesto di diversi approcci metodologici. La OMG gestisce uno
standard metodologico, correlato a UML ma proposto come specifica
indipendente, detto RUP.
UML consente di costruire modelli object-oriented per
rappresentare domini di diverso genere. Nel contesto dell’ingegneria
del software, viene usato soprattutto per descrivere il dominio
applicativo di un sistema software e/o il comportamento e la
struttura del sistema stesso. Il modello è strutturato secondo un
insieme di viste che rappresentano diversi aspetti della cosa
modellata (funzionamento, struttura, comportamento, e così via), sia
a scopo di analisi che di progetto, mantenendo la tracciabilità dei
concetti impiegati nelle diverse viste. Oltre che per la modellazione
di sistemi software, UML viene non di rado impiegato per descrivere
domini di altri tipi, come sistemi hardware, strutture organizzative
aziendali, processi di business.
Lo standard UML, gestito da OMG, definisce una sintassi e delle
regole di interpretazione; non si tratta quindi di una metodologia di
progettazione e per questo motivo può essere adottato con diverse
metodologie o in ambiti diversi da quello informatico.
76
B XML
L’XML, acronimo di eXtensible Markup Language, ovvero
«Linguaggio di marcatura estensibile» è un metalinguaggio creato e
gestito dal World Wide Web Consortium (W3C). È una
semplificazione e adattamento dell’SGML, da cui è nato nel 1998, e
permette di definire la grammatica di diversi linguaggi specifici
derivati. Rispetto all’HTML, l’XML ha uno scopo ben diverso: mentre
il primo è un linguaggio creato principalmente per la descrizione e la
formattazione di pagine web e, più in generale, di ipertesti, il
secondo è un meta linguaggio utilizzato per creare nuovi linguaggi,
atti a descrivere documenti strutturati. Mentre l’HTML ha un insieme
ben definito e ristretto di tag, con l’XML è invece possibile definirne
di propri a seconda delle esigenze. L’XML è oggi molto utilizzato
anche come mezzo per l’esportazione di dati tra diversi DBMS. Per
poter essere correttamente interpretato da un browser, un
documento XML deve essere ben formato, deve cioè possedere le
seguenti caratteristiche:
• Un Prologo, che è la prima istruzione che appare scritta nel
documento. Nel nostro caso: <?xml version=“1.0” encoding=“ISO-
8859-1”>
• Un unico Elemento radice (ovvero il nodo principale) che
contiene tutti gli altri nodi del documento. Nel nostro esempio:
<utenti>;
• All’interno del documento tutti i Tag devono essere bilanciati.
Un documento XML viene considerato Well Formed se non
contiene errori di sintassi, tutti tag sono bilanciati ed esiste un unico
77
nodo radice che contiene tutti gli altri. Se il documento è well-formed
e in più rispetta i requisiti strutturali definiti nel DTD o nell’XML
Schema si dice Valid.
B.1 Strumenti aggiuntivi per XML
L’XML non si esaurisce qui: esistono diversi strumenti legati
all’XML, ognuno con uno scopo differente:
• DTD (acronimo di Document Type Definition): `e un documento
attraverso cui si specificano le caratteristiche strutturali di un
documento XML attraverso una serie di regole grammaticali. In
particolare definisce l’insieme degli elementi del documento XML, le
relazioni gerarchiche tra gli elementi, l’ordine di apparizione nel
documento XML e quali elementi e quali attributi sono opzionali o
meno.
• XML Schema: come la DTD, serve a definire la struttura di un
documento XML. Oggi il W3C consiglia di adottarlo al posto della
DTD stessa, essendo una tecnica più nuova ed avanzata. La sua sigla
è XSD, acronimo di XML Schema Definition;
• XLink: serve a collegare in modo completo due documenti XML;
al contrario dei classici collegamenti ipertestuali che conosciamo in
HTML, XLink permette di creare link multidirezionali e
semanticamente avanzati;
• XSL (acronimo di eXtensible Stylesheet Language): è il
linguaggio con cui si descrive il foglio di stile di un documento XML.
La sua versione estesa è l’XSLT (dove la T sta per Trasformations);
• XPath: è un linguaggio con cui è possibile individuare porzioni
di un documento XML e sta alla base di altri strumenti per l’XML
come XQuery. A supporto di questo scopo principale, fornisce anche
elementari funzionalità per trattare stringhe, numeri e dati booleani.
Il suo funzionamento si basa sulla creazione di un albero a partire
dal documento e la sintassi succinta permette di indirizzare una
specifica parte attraverso i nodi dell’albero con la semplice parola
path;
• XPointer: serve ad identificare univocamente precise porzioni di
un documento XML; consente poi il loro accesso ad altri linguaggi o
oggetti di interfaccia;
78
• XQuery: è un linguaggio di query concepito per essere
applicabile a qualsiasi sorta di documento XML e si basa sull’utilizzo
di XPath per la specificazione di percorsi all’interno di documenti.
XQuery ha funzionalità che consentono di poter attingere da fonti di
dati multiple per la ricerca, per filtrare i documenti o riunire i
contenuti di interesse;
• SAX (Simple API for XML): è un’interfaccia di programmazione,
implementata in numerosi linguaggi, che permette di leggere e
modificare i documenti XML. Attraverso SAX è possibile
implementare dei parser XML specifici. SAX è event-base, al
contrario di DOM, e reagisce agli eventi di parsing facendo rapporto
all’applicazione. È compito del programmatore implementare i
metodi per reagire agli eventi di parsing;
• DOM: è un’interfaccia di programmazione, come SAX,
implementata in una moltitudine di linguaggi di programmazione,
per la manipolazione di file XML. DOM costruisce partendo dal file
XML un albero dove ogni nodo dell’albero corrisponde ad un
elemento del file; per questo motivo è detta tree based;
• VTD-XML.
DOM è più facile ed immediata da utilizzare rispetto a SAX ed è
pertanto preferita solitamente dai programmatori per manipolare
un file XML; purtroppo l’albero generato da DOM va mantenuto
completamente nella memoria RAM e di conseguenza non è possibile
utilizzare questa interfaccia per manipolare file che siano più grandi
della memoria disponibile sul computer.
• XForms: come il suo nome lascia intendere, è un linguaggio nato
per creare moduli (forms) di tipo HTML all’interno di un documento
XML;
• RSS: è uno standard che serve a creare un documento con una
struttura di tipo XML univoca, atta allo sviluppo di un semplice
scambio dati tra pagine Web ed accessibile da qualsiasi linguaggio di
scripting. In sostanza si tratta di un documento XML la cui struttura
dei nodi ed i relativi tag hanno lo stesso nome;
• SVG (Scalable Vector Graphics): è uno standard per la creazione
di immagini vettoriali che sfrutta dei documenti formattati in XML.
Serve inoltre a descrivere immagini bidimensionali, statiche e
dinamiche. Leggendo le istruzioni contenute nel documento sorgente
XML, l’interprete disegna le figure-base fino al completamento
dell’immagine.
79
Glossario ed Acronimi
.NET Tecnologia di programmazione ad oggetti versatile
di Microsoft.
API Application Programming Interface
BPEL Business Process Execution Language
BPM Business Process Management
BPMN Business Process Management Notation
COM+ Component Object Model; Piattaforma Microsoft