progettazione e realizzazione di un sistema software per il time logging
TRANSCRIPT
Università degli studi dell’Aquila
Laurea magistrale in Ingegneria Informatica-Automatica
Ingegneria del software – A.A. 2011/2012
Docente Studenti
Prof. Serafino Cicerone Stefano Dell’Osa
Daniele Leombruni
Luca Finocchio
Vittoriano Muttillo
Progettazione e realizzazione di un
sistema software per il Time-Logging
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
XP-Dev.com – Codice sorgente e progetto Visual Paradigm
Dropbox – Documentazione di progetto
Strumenti di progettazione
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
Server Client
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 client-
server.
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)
Client
Server
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