Progettazione e realizzazione di un sistema software per il time logging

1. 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

2. 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

3. 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

4. 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

5. 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)

6. Modello di dominio

7. Diagramma dei casi d’uso
 Ideazione /
Elaborazione 1°
iterazione
 Elaborazione 2°
iterazione
 Elaborazione 3°
iterazione
 Elaborazione 4°
iterazione

8. Scelte architetturali

9. Diagramma di Deployment

10. Diagramma dei Package
 Server Client

11. 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.

12. 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

13. 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

14. 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

15. 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

16. Configurazione del sistema (2)
Client
Server

17. 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

18. 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

19. 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

20. 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»

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. Gestione delle alternative UI (2)
 Abstract Factory
 La UI varia a seconda
della tipologia di utenza

28. 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

29. 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

30. 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

31. 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

32. Regole per il calcolo dello stipendio (5)

33. 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à

34. Separazione delle responsabilità (2)
… …

35. Sviluppi futuri
 Problematiche da affrontare:
 Calcolo della fattura
 Gestione dei progetti
 Visualizzazione dei report

36. 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

37. GRAZIE PER L’ATTENZIONE