Work World WORK WORLD PROGETTO INGEGNERIA DEL SOFTWARE. Alessandro Spinelli

WORK WORLD PROGETTO INGEGNERIA DEL SOFTWARE di Alessandro Spinelli

Indice 1 - Introduzione 2 - Descrizione del problema 2.1 Requisiti funzionali 2.2 Requisiti non funzionali 3 - Analisi 3.1 Dizionario dei termini 3.2 - Gellish 3.3 Alloy 3.4 UML 3.4.1 Attori 3.4.2 Use case Diagram 3.4.3 - Activity Diagram 4 Progettazione 4.1 UML 4.1.1 Class Diagram 4.1.2 Sequence Diagram 4.2 - OCL 4.3 Reti di Petri 5 - Conclusioni

1- Introduzione Si vuole realizzare una applicazione web, che ha come principale tema il modo del lavoro. Lo scopo del sito è quello di orientare l utente nel mondo del lavoro, tramite l inserimento di dati personali che permettono l accesso e la registrazione al sito, ma anche la possibilità di potere inserire dati inerenti il personale curriculum. In seguito a questa operazione il sito permetterà di fare capire all utente registrato quale è l area dove può ambire a qualche posto di lavoro in base ai dati che esso stesso ha inserito precedentemente. Ci sono due modalità che permettono la scelta del lavoro appropriato: - Predisposizione nel sito il così detto certificato POR. Quest ultimo può essere definito come il documento che da attuazione ai finanziamenti dei Fondi Strutturali a sostegno dei Progetti delle P.M.I. ( Piccole e Medie Imprese ) e degli Enti Pubblici. Ogni POR Regionale è articolato in ASSI, che rappresentano gli obiettivi, entro cui investire per ricevere i finanziamenti.. In base ai dati immessi dall'utente, è possibile capire in quale zona il proprio lavoro è maggiormente richiesto. (es: POR Emilia Romagna, richiesta personale scolastico o Assistenza Informatica; coloro che hanno queste caratteristiche, potranno informarsi riguardo quei determinati posti di lavoro in quella regione). -Definizione di un meccanismo di domanda-offerta tra colui che immette i propri dati,alla ricerca di un lavoro, e colui che invece, offre un posto di lavoro a determinate condizioni e requisiti: il datore di lavoro deve specificare le caratteristiche che bisogna avere per quel posto che sta offrendo,valutando l'accettazione del richiedente anche se non soddisfa tutti i vincoli(definizione vincoli primari e secondari). Lo stesso richiedente deve definire le proprie qualità e caratteristiche(curriculum) Entrando più nello specifico, utilizzando i vari strumenti di analisi di un software analizzerò e specificherò la composizione di esso, basandomi sul linguaggio UML (Unifed Modeling Language),cioè un linguaggio unificato di modellazione, che tramite i suoi strumenti (i vari diagrammi ad esempio) mi permetterà di optare per una documentazione del sito per lo più grafica,in modo tale da ampliare tramite i diagrammi le capacità di analisi e design,e di conseguenza anche la qualità della analisi stessa. Fondamentale sarà anche la parte riguardante la progettazione nella quale specificherò le varie attività che si possono svolgere all interno del sito e le varie modalità di accesso e registrazione,utilizzando il linguaggio OCL e le Reti di Petri, che differentemente da UML (soprattutto OCL) permette di migliorare l analisi e la

progettazione,ponendo una descrizione testuale affiancata a quella scritta. La progettazione in OCL sarà fondamentale in quanto mi permette di specificare i vari vincoli e le varie dinamiche che si innescano all interno del rapporto tra colui che offre il posto di lavoro e colui a cui questa domanda è rivolta. Infatti possiamo introdurre due tipi di utenti: colui che offre la sua prestazione,le sue conoscenze alla ricerca di un posto di lavoro, e colui che invece offre un posto in base alle proprie necessità. Il POR è un qualcosa in più che permette di muoversi con maggiore facilità all utente in cerca, in quanto indica direttamente in quale area andare a cercare.( funzionalità secondaria). 2- Descrizione del problema 2.1- Requisiti Funzionali ID DESCRIZIONE MoSCow 0 Il sito deve permettere la registrazione degli utenti Must Have 1 Nella registrazione,il sito deve chiedere quale ruolo avrà l'utente al suo interno: richiedente o offerente del lavoro 2 Il sito deve permettere il caricamento di un file DOC con curriculum (utente-richiedente) e richieste specifiche (utente-offerente) Must Have Must Have 3 Il sito deve permettere la lettura di questi file Must Have 4 Il sito deve permettere la comunicazione tra queste due parti che deve essere accettata dall'utente-offerente,tramite e- mail(dato inserito nell autenticazione) Must Have 5 Il sito deve proteggere dati personali da privacy Must Have 2.2- Requisiti non Funzionali ID DESCRIZIONE MoSCoW 0 Il sito deve permettere caricamento di file in grosse dimensioni Should Have 1 Il sito deve mettere a disposizione degli utenti registrati un file di istruzioni esaustive sull utilizzo dello strumento di caricamento dei file DOC

2 Il sito deve contenere un file.doc con all'interno il contenuto aggiornato del POR nazionale (opzione secondaria) 3 Programma deve essere sviluppato in Java 3 Analisi 3.1 Dizionario dei termini TERMINE Utente Utenterichiedente Utente-offerente Lavoro POR SIGNIFICATO Indica colui che immette i propri dati personali all'interno del sito quali: nome,cognome,indirizzo,e-mail... Termine che sta ad indicare quella tipologia di utente che si è registrato all'interno dell'applicazione web come richiedente del lavoro,simboleggiando la figura di una persona che sta cercando lavoro. Termine che sta ad indicare quella tipologia di utente che si è registrato all'interno dell'applicazione web come offerente del lavoro,simboleggiando la figura di una persona che,avendo a disposizione un'attività, cerca del personale con determinate caratteristiche. Elemento principale che tiene legate le due figure,che si approcciano differentemente a questo tema Documento che da attuazione ai finanziamenti dei Fondi Strutturali a sostegno dei Progetti delle P.M.I. ( Piccole e Medie Imprese ) e degli Enti Pubblici. Ogni POR Regionale è articolato in ASSI, che rappresentano gli obiettivi, entro cui investire per ricevere i finanziamenti. 3.2 Gellish Per evitare che i termini utilizzati risultino incomprensibili e ambigui, qualunque programmatore software utilizza un proprio dizionario di termini che identifica in modo chiaro e univoco,tramite il linguaggio Gellish, i concetti che esso

stesso utilizzerà. Gli elementi di un Gellish sono : i concetti ovvero gli elementi principali che condensano la conoscenza e le relazioni cioè caratterizzazioni che legano due concetti, come ad esempio : è un sottotipo di, è classificato come ( è un istanza di ); è un aspetto di... Per quanto riguarda la nostra applicazione, i concetti principali sono: Lavoro e Utente, che permettono poi le specifiche di altri elementi. TERMINE RELAZIONE TERMINE Utente-richiedente È una specializzazione di Utente Utente-offerente E' una specializzazione di Utente POR (documento) E' un istanza di Lavoro POR (documento) E' diviso in Assi (sezioni documento) Lavoro E' richiesto da Utente - richiedente Lavoro E' proposto da Utente - offerente POR (documento) E' usato da Utente - richiedente 3.3 Alloy Alloy è un linguaggio di specifica dichiarativo per esprimere vincoli strutturali e comportamentali complessi all interno di un sistema software. Deriva dall'esigenza di evitare che alcune situazioni si verifichino, in quanto può portare a perdite di vario tipo,spesso economiche. Per questo sono disponibili questi vari linguaggi,tra cui Alloy che in particolar modo tende a specificare ancor di più i requisiti del software e verifica la sua correttezza. Tutti i vari vincoli e dichiarazioni espresse in questo linguaggio possono essere controllare per mezzo del software Alloy Analyzer. Alloy è un linguaggio che non presenta ne variabili e ne costrutti; gli elementi fondamentali sono: -Segnature ( sig ) : dichiarano classi d'automi,in sostanza insiemi, con caratteristiche esplicitate nel corpo della segnatura. Es: sig stack{} indica una classe stack semplice / aig stack {composto : one Element} indica una classe stack composta da un (one) Element -Fatti ( fact ) : definiscono vincoli sempre validi -Predicati ( pred ) : definiscono vincoli con parametri, affinchè il modello rispetti determinate proprietà. Utilizzati soprattutto per rappresentare operazioni e formule.

-Funzioni ( fun ): espressioni che producono un risultato,spesso insiemi. -Asserzioni : asserzioni riguardanti il modello,controllabili. Simili ai fatti che però devono essere sempre veri, mentre queste sono relative al modello a cui sono legate. Risoluzione grafica Codice Alloy

3.4 UML UML (Unified Modeling Language) può essere considerato un linguaggio formale per specificare,visualizzare e costruire astrazioni. Comporta una rappresentazione per lo più grafica contenente simboli e concetti: infatti ci offre una serie di diagrammi,ognuno dei quali con le proprie caratteristiche e le proprie regole,utili sia per la visualizzazione di un sistema,specificandone il comportamento e la struttura, sia per documentare le decisioni prese. In quest'ambito,utilizzeremo UML per descrivere gli attori protagonisti della nostra applicazione, tramite l'ausilio di due diagrammi: Use Case Diagram e gli Activity Diagram. Tutto ciò al fronte di migliorare l'analisi già trattata tramite Alloy,in quanto i due diagram servono descrivere in modo prettamente grafico le funzioni e i servizi offerti dal sistema, soprattutto come sono utilizzati dagli attori,definendo le attività da svolgere per realizzare una determinata specificità. 3.4.1 Attori ATTORI DESCRIZIONE Utente-offerente Colui che durante la registrazione ha scelto come ruolo quello dell'offerente: ciò gli permette di potere offrire un posto di lavoro con determinate caratteristiche. Visitatore Colui che deve effettuare una registrazione per accedere al sito ed alle conseguenti funzionalità Utente Colui che ha effettuato la registrazione del sito e deve effettuare il login per accederci Utente-richiedente Colui che durante la registrazione ha scelto come ruolo quello del richiedente: ciò gli permette di potere cercare un posto di lavoro tramite varie modalità

3.4.2 Use Case Diagram Servono nelle fasi iniziali per descrive iterazioni attori e sistema. Use case : AUTENTICAZIONE ID 1 / Attori primari : Utente Attori secondari: - Breve descrizione : Inserimento user name e password per iniziare una sessione Pre-condizioni : Deve essere già stata effettuata una registrazione al sito, e la combinazione user-password deve essere esatta. Flusso principale: Decisione dell'utente già registrato di effettuare il login Inserimento user e password se inserimento è corretto c'è l'accesso all'applicazione web Post-Condizioni : Utente ha accesso,in base al proprio ruolo alle funzioni del sito

Use case : CARICAMENTO FILE OFFERTA ID 2 / Attori primari : Utente-offerente Attori secondari: - Breve descrizione : Inserimento tramite file formato.doc delle specifiche del lavoro che si sta offrendo Pre-Condizioni : Utente deve essere autenticato al sito e deve essere di tipo offerente Flusso principale: Autenticazione caricamento nel sito del file.doc Post-Condizioni : Permette di cercare un utente-richedente che definisca le specifiche descritte nel file dall'utente-offerente Use case : CARICAMENTO CURRICULUM ID : 3 / Attori primari : Utente-richiedente Attori secondari: - Breve descrizione : caricamento di un file.doc da parte dell'utente-richiedente nella quale specifica le proprie competenze e le proprie esperienze passate (curriculum) Pre-Condizione: Utente registrato, autenticato e deve essere di tipo richiedente Flusso principale: Autenticazione caricamento nel sito del file.doc Post- Condizione : Permette ad un utente-richiedente di caricare nel sito il proprio curriculum (in modo tale da potere essere scelto in base alle loro specifiche dall'utente-offerente ). Use case : RICERCA LAVORO ID: 4 / Attori primari : Utente-richiedente Attori secondari : - Breve descrizione : Permette all'utente richiedente di cercare lavoro o tramite la lettura del certificato POR (opzione secondaria) oppure tramite un contatto con un utente-offerente che ha postato nel sito un offerta di lavoro Specializzazione => Caso:POR caso:contatto offerente Pre- Condizione: Utente registrato,autenticato,richiedente e deve avere caricato il proprio curriculum (per comunicazione offerente-richidente) Flusso principale: Ricerca lavoro Consultazione POR oppure consultazione offerte

di lavoro nel sito da parte di utente-offerente Post-Condizioni :permette di ricercare il lavoro in base alle proprie esigenze e caratteristiche Use case: INVIO RICHIESTA CONTATTO ID : 5 / Attori primari :Utente- richiedente Attori secondari: Utente-offerente Breve descrizione : Si ricerca il contatto con l'utente offerente che ha specificato quella determinata proposta a cui è interessato Utente-Offerente Pre-Condizioni: Utente-richiedente deve avere effettuato una ricerca del lavoro,non in base al POR, ma in base alle offerte di lavoro specificate dall'offerente Flusso principale: Ricerca lavoro Valutazione offerte contatto offerente tramite una richiesta di comunicazione con l utente che ha offerto quel posto di lavoro Post-Condizioni : Possibile contatto con l'utente offerente che deve accettare o no questa comunicazione Use case : RISPOSTA A RICHIESTE ID : 6 / Attori primari : Utente-offerente Attori secondari : - Breve descrizione : in seguito a richiesta di contatto, l 'utente offerente può decidere se accettare o meno la comunicazione : se la sua risposta è affermativa, c'è la visualizzazione dei dati personale dell'utente offerente, e quindi un contatto tramite mail, se la risposta è negativa, non c'è possibilità di contatto Pre-condizione: Utente-offerente deve avere ricevuto una richiesta Flusso principale : Risposta a richiesta Affermativa c'è il contatto con chi ha inviato la richiesta di comunicazione (Contatto = rilascio mail) Negativa, non c'è possibilità Post-Condizioni: Possibili contatto con l'utente offerente riguardante le specifiche del lavoro che essi stesso ha richiesto nel sito

3.4.3 Activity Diagram Vengono utilizzati per rappresentare la logica interna dell'applicazione,rappresentando processi paralleli e la loro sincronizzazione. In questo caso vengono esplicitati i passi uno per uno che portano alla ricerca del lavoro all'interno del sito: preso un utente registrato ed autenticato, scelto il ruolo dell utente, si sfruttano le funzioni del sito. 4 Progettazione 4.1 UML Utilizzeremo ancora strumenti riguardanti UML per specificare le scelte progettuali in modo più dettagliato. 4.1.1 Class Diagram Da una visione statica del contenuto della applicazione,definendo gli elementi base del sistema: rappresenta gli oggetti che compongono il sistema,con relativi attributi e comportamenti,ma anche i vincoli tra le varie classi. Ogni classe ha un nome,attributi (privati e pubblici) e dei metodi (operazioni). Tra le classi possono esserci delle associazioni,che possono essere descritte da delle classi di associazioni.altri elementi fondamentali di questa tipologia di diagram sono: la generalizzazione,l'aggregazione e l'associazione tra le varie classi. Gli elementi che compongono il sistema che stiamo analizzando sono:

1. Classe Utente,che definisce le specifiche che caratterizza colui che ha accesso al sito 2. Classe Utente-richiedente, generalizzazione dell'utente 3. Classe Utente-offerente, altra generalizzazione 4. Associazione di comunicazione tra i due utenti 5. Classe POR per esplicitare la seconda modalità di ricerca lavoro 6. Associazione consultazione tra POR e Utente-richiedente 4.1.2 Sequence Diagram Descrive il comportamento dinamico di un gruppo di oggetti,rappresentando un o scenario derivante dalla collaborazione di tutti questi oggetti e attori.(non vengono rappresentate le relazione e associazioni tra oggetti). Elementi fondamentali sono Object,Messaage e Activation.

4.2 OCL Poichè a volte la rappresentazione grafica, con i vari diagrammi UML non garantisce appieno la comprensione di ciò che si sta sviluppando,si cerca di aggiungere nuove regole e vincoli tramite un ulteriore linguaggio di specifica,detto OCL (Object Constraint Language), basato sulle espressioni che arricchiscono l'espressività dei diagrammi, facendo riferimento talvolta ai loro elementi. (classi,associazioni ecc..). OCL specifica delle condizioni, dei vincoli che devono essere rispettate affinché il sistema sia valido: OCL consente di descrivere invarianti che legano il valore degli attributi di una classe, precondizioni e postcondizioni delle operazioni. Non possono esserci utenti con stessa Mail Context Utente inv: Utente : AllIstances() for all (u,w / u <> w => u.mail <> w.mail Non si possono effettuare più di 3 richieste Context Utente-richiedente :: Invia_richiesta (r : Richieste) pre: self.richieste size < 3 post : self.richieste = self.richieste@pre+1 // controlla buon esito operazione Non si possono caricare più di 3 offerte

Context Utente-offerente :: carico_file ( o : offerte ) pre: self.offerte size < 3 post: self.offerte = self.offerte@pre+1 4.3 Reti di Petri Una rete di Petri (conosciuta anche come rete posto/transizione o rete P/T) è una delle varie rappresentazioni matematiche di un sistema distribuito discreto. Come un linguaggio di modellazione, esso descrive la struttura di un sistema distribuito come un grafo bipartito con delle annotazioni. Ovvero, una rete di Petri ha dei nodi posti, dei nodi transizioni e degli archi diretti che connettono posti e transizioni. Una rete di Petri PT (Place/Transition) consiste di posti, transizioni e archi diretti. Possono esserci archi tra posti e transizioni - ma non tra posti e posti o transizioni e transizioni. Un posto da cui un arco parte per finire in una transizione è detto posto di input della transizione; un posto in cui un arco arriva partendo da una transizione è detto posto di output della transizione. I posti possono contenere un certo numero di token o marche. Una distribuzione di token sull'insieme dei posti della rete è detta marcatura. Le transizioni agiscono sui token in ingresso secondo una regola, detta regola di scatto (in inglese firing). Una transizione è abilitata se può scattare, cioè se ci sono token in ogni posto di input.

5 Conclusione I seguenti software sono stati necessari per la progettazione del progetto: Alloy 4.2 / Pipe / ArgoUML