Università degli studi dell’Aquila Laurea magistrale in Ingegneria Informatica-Automatica
Progettazione e realizzazione di un sistema software per il Time-Logging Docente
Studenti
Prof. Serafino Cicerone
Stefano Dell’Osa Daniele Leombruni Luca Finocchio Vittoriano Muttillo
Ingegneria del software – A.A. 2011/2012
Indice
Introduzione
Strumenti e tecnologie utilizzati Progettazione mediante Visual Paradigm
Scelte progettuali e Problematiche affrontate
Diagrammi e modelli (Dominio, casi d’uso, Deployment, Package) Invocazione oggetti remoti Persistenza dei dati Configurazione del sistema Regole di dominio
Gestione dei Task Calcolo dello stipendio
Sviluppi futuri
Introduzione
Si vuole realizzare un’applicazione software per la gestione integrata dei progetti e del lavoro svolto dai dipendenti su tali progetti. In particolare si vuole memorizzare il numero delle ore spese da ciascun dipendente nell’adempimento del proprio lavoro. L’applicazione rientra nella categoria di applicazioni cosiddette time tracking software
Strumenti e tecnologie utilizzati
Repositories on-line
Strumenti di progettazione
XP-Dev.com – Codice sorgente e progetto Visual Paradigm Dropbox – Documentazione di progetto
Visual Paradigm for UML 10
Strumenti di sviluppo
Eclipse Kepler Plugin per Eclipse
SVN ICE
Progettazione mediante VP
La progettazione e realizzazione del software è avvenuta seguendo il modello UP Visual Paradigm ha avuto un ruolo fondamentale: Nella progettazione, fornendo strumenti a supporto della produzione dei diagrammi e relativa documentazione Nella costruzione del codice (Java round-trip engineering) Nella progettazione e realizzazione del database, con relativo mapping tramite ORM (Hibernate)
Modello di dominio
Diagramma dei casi d’uso
Ideazione / Elaborazione 1° iterazione Elaborazione 2° iterazione Elaborazione 3° iterazione Elaborazione 4° iterazione
Scelte architetturali
Diagramma di Deployment
Diagramma dei Package
Client
Server
Invocazione di oggetti remoti
Tecnologia software utilizzata per la realizzazione dell’architettura distribuita: ICE Ice si basa sul concetto di SLICE:
Slice (Specification Language for Ice) is the fundamental abstraction mechanism for separating object interfaces from their implementations. Slice establishes a contract between client and server that describes the types and object interfaces used by an application.
Integrazione con Eclipse:
Ogni slice viene mappato sul client come classi Proxy e sul Server come classi Skeleton, il tutto in maniera automatizzata grazie all’utilizzo dell’apposito plugin per Eclipse.
Invocazione di oggetti remoti (2)
PROBLEMA: Evitare che le classi dello strato di interfaccia si trovino ad assolvere compiti che vanno oltre la loro funzionalità specifica e che quindi si facciano carico di altre problematiche relative alla comunicazione clientserver.
SOLUZIONE: Applicazione del design pattern Simple Factory.
Alta coesione
Persistenza dei dati
PROBLEMI: Individuare
l’oggetto responsabile della persistenza
dei dati Disaccoppiare la logica applicativa dallo strato di interfaccia utilizzata verso il database
SOLUZIONE: utilizzo del pattern Pure Fabrication
Persistenza dei dati (2)
Pure Fabrication L’introduzione della classe FTask fornisce un’interfaccia al model, rendendolo indipendente dallo strato sottostante di collegamento al DB
Alta coesione Protezione dalle variazioni
Configurazione del sistema 
PROBLEMA: Permettere al sistema di cambiare il suo comportamento in fase di esecuzione a seconda dei dati con cui si trova a lavorare

SOLUZIONE: Parametrizzazione delle configurazioni di sistema su file xml e costruzione di un parser xml
Configurazione del sistema (2) Server
Client
Assegnazione delle responsabilità
PROBLEMA: Individuare un principio base per l’assegnazione delle responsabilità agli oggetti
SOLUZIONE: Utilizzo del pattern Information Expert Utilizzo del pattern Creator
Basso accoppiamento Alta coesione
Assegnazione delle responsabilità (2)
PROBLEMA: Individuare l’oggetto oltre lo strato UI il cui compito è quello di ricevere e coordinare le operazioni di sistema SOLUZIONE: Utilizzo del pattern Controller
Garantire la coesione
PROBLEMA: Come evitare che la classe Azienda si faccia carico di troppe responsabilità ( bassa coesione ) SOLUZIONE: Utilizzo del pattern Pure Fabrication Alta coesione
Garantire la coesione (2)
Pure Fabrication La gestione dei Dipendenti è scorporata da Azienda e demandata ad una nuova classe «EDirezione» La gestione degli stipendi è demandata ad una nuova classe «EMarketing»
Regole di dominio
Regole che l’Azienda ha interesse a stabilire per permettere una gestione dinamica dei propri dipendenti e dei progetti ai quali lavora. Esempio: Aggiunta/rimozione
di nuove figure professionali Differenziazione degli stipendi Cambiamenti a livello strutturale/organizzativo dei progetti
Regole di Dominio
PROBLEMA: Necessità di avere un sistema di gestione delle regole di dominio flessibile e che garantisca un’elevata estensibilità Regole per la gestione dei Task
Regole per il calcolo dello stipendio
Regole per la gestione dei Task 

Regole per la gestione del ciclo di vita del Task
Regole per la diversificazione dei privilegi associati ai singoli utenti relativi alla gestione dei Task
Gestione delle alternative
PROBLEMA: Gestire alternative basate sul tipo, ovvero come gestire situazioni in cui le alternative o i comportamenti correlati variano con il tipo (Es. Ogni Dipendente assolverà compiti differenti all’interno della struttura aziendale).
SOLUZIONE: Utilizzo del pattern Polymorfism
Gestione delle alternative (2)
Polymorfism Ogni Dipendente ha un compito differente L’aggiunta di nuovi dipendenti può avvenire in maniera flessibile, senza impattare significativamente sul sistema
Gestione delle alternative UI 

PROBLEMA: Visualizzare diverse interfacce grafiche a seconda dell'utente che si trova ad utilizzare il software in un determinato momento (Es. Azienda, Manager oppure Consulente). SOLUZIONE: Utilizzo del pattern Abstract Factory
Gestione delle alternative UI (2) 
Abstract Factory 
La UI varia a seconda della tipologia di utenza
Regole per il calcolo dello stipendio
PROBLEMA : Creare regole per il calcolo dello stipendio flessibili Supporto
a diversi metodi di calcolo Differenziazione del calcolo dello stipendio per ogni categoria di Dipendenti ipotizzata
SOLUZIONE: Utilizzo dei pattern Strategy, Composite e Simple Factory
Regole per il calcolo dello stipendio (2)
PROBLEMA: Definire gli algoritmi per le regole di calcolo dello stipendio, incapsularli e renderli intercambiabili fra di loro in maniera trasparente all’utilizzatore finale SOLUZIONE: Utilizzo del pattern Strategy
Regole per il calcolo dello stipendio (3)


PROBLEMA: Identificare chi si fa carico della creazione delle strategie/algoritmi per il calcolo dello stipendio SOLUZIONE: Utilizzo del pattern Simple Factory
Regole per il calcolo dello stipendio (4)


PROBLEMA: Comporre le varie regole per il calcolo dello stipendio in modo da ignorare la differenza fra le singole regole e quelle composte SOLUZIONE: Utilizzo del pattern Composite
Regole per il calcolo dello stipendio (5)
Separazione delle responsabilità
PROBLEMA: Gestione delle azioni da compiere al verificarsi di un evento associato ad un determinato oggetto o componente dell’interfaccia. SOLUZIONE: Utilizzo del pattern Command Alta coesione Facile estendibilità
Separazione delle responsabilità (2)
…
…
Sviluppi futuri
Problematiche da affrontare: Calcolo
della fattura
Gestione
dei progetti Visualizzazione dei report
Conclusioni
L’utilizzo di una tecnica consolidata di progettazione (UP) ha: Consentito
un approccio iterativo ed incrementale di risoluzione del problema Portato notevoli benefici al lavoro in Team, consentendo un’efficiente organizzazione e pianificazione dei passi da svolgere Consentito, insieme all’utilizzo dei pattern noti in letteratura, di avere un software agile e flessibile rispetto ai cambiamenti
GRAZIE PER L’ATTENZIONE