Download - Il Project Management nei progetti IT
IngSW - Design - 1 © Ing. Giulio Destri – 2011
Ing. Giulio Destri
Il Project Management
nei progetti IT
La fase di Design
Università degli Studi di Parma Corso di Laurea in Informatica
IngSW - Design - 2 © Ing. Giulio Destri – 2011
Ing. Giulio Destri, Ph.D.
http://www.areaprofessional.net/giulio.destri
http://www.giuliodestri.it/articoli
[email protected] – [email protected]
twitter.com/GiulioDestri
Digital Solution Architect & Advisor presso AREA Professional
Docente di Sistemi Informativi I e (sino al 2009) di Ingegneria del Software presso Università di Parma
IngSW - Design - 3 © Ing. Giulio Destri – 2011
Argomenti
• La struttura base di un’applicazione interattiva
• Il modello client-server
• Le architetture derivate da MVC
• La fase di Design
IngSW - Design - 4 © Ing. Giulio Destri – 2011
Struttura base di un’applicazione
• Interfaccia utente (grafica): presentazione dei dati e interazione con l’utente
• Regole funzionali (logica business): le procedure che compiono le operazioni in base ai comandi ricevuti dal livello precedente
• Dati: su cui si deve agire e che devono essere memorizzati (durano oltre i programmi)
IngSW - Design - 5 © Ing. Giulio Destri – 2011
La struttura dell’applicazione
Dati
Logica
business
Interfaccia
utente
IngSW - Design - 6 © Ing. Giulio Destri – 2011
Il modello client-server
• Un programma server opera su un computer server (host)
• Un programma client opera su una postazione client (workstation)
• L’utente interagisce col programma client
• Il programma client dialoga col server via rete
IngSW - Design - 10 © Ing. Giulio Destri – 2011
Architettura Web base
HTTP request
HTTP response
Web Server Application
Server
Stream dinamico
HTML
Web Client
TCP/IP
CGI, NSAPI, ISAPI
DBMS
Documenti HTML e
immagini
Template HTML
+ Contenuti HTML
generati dinamicamente
IngSW - Design - 11 © Ing. Giulio Destri – 2011
Architettura Web: estensioni
Primo livello Secondo livello Terzo livello
Web Browser
Web Server Regole business
sistemi
legacy
database
Sorgenti di dati
Quarto livello
Enterprise
Application
Integration
Application/
Transaction
Server
connetori
componenti
Web Service
client
IngSW - Design - 12 © Ing. Giulio Destri – 2011
L’interfaccia utente
• Riga comandi (es. DOS, UNIX)
• Riga comandi/menu (es. TSO-MVS)
• Maschera testo (es. applicativi gestionali prime generazioni)
• GUI a finestre (es. Windows, Motif)
• GUI/Maschera Web
IngSW - Design - 13 © Ing. Giulio Destri – 2011
L’interfaccia utente Web
• Maschera/tabella Web base (es. Form HTML)
• Lightweight client Web (es. programmi JavaScript, Flash con retroconnessione)
• Applet Java (es. JDE for Web, versione Java)
• Controllo ActiveX
IngSW - Design - 14 © Ing. Giulio Destri – 2011
Le funzioni dell’interfaccia utente
• Gestione degli eventi dell’utente
• Immissione dati
• Verifica coerenza fra dati e regole dell’applicazione
• Visualizzazione dati (risultati elaborazione)
• Notifica eventi interni all’applicazione
IngSW - Design - 15 © Ing. Giulio Destri – 2011
Le funzioni dell’interfaccia utente - 2
• La verifica della coerenza dati viene fatta
– Dalla interfaccia utente?
– Trasmessa ad un altro modulo e qui fatta?
– Quando (a fine compilazione o campo per campo)?
• La gestione eventi viene fatta
– Localmente?
– Da un altro modulo?
IngSW - Design - 16 © Ing. Giulio Destri – 2011
La logica business
• Offre le funzionalità di azioni sui dati
• Le funzionalità possono anche essere asincrone rispetto all’intefaccia utente (avvio senza attesa bloccante)
• La successione degli eventi trasmessagli dalla interfaccia utente determina la successione di azioni sui dati
• Si connette alla base di dati
IngSW - Design - 17 © Ing. Giulio Destri – 2011
La base di dati
• Nella stragrande maggioranza dei casi è un database relazionale
• Non è detto che sia visto come tale dalla logica business
– Meccanismi trasparenti di persistenza di oggetti (es. EJB)
– Accesso dati in formato XML (es. Oracle, ADO-NET)
IngSW - Design - 18 © Ing. Giulio Destri – 2011
La base di dati - 2
• Quasi sempre occorre una mappatura relazionale-oggetto
• Nei casi XML e EJB esistono sistemi automatici di ausilio alla mappatura
• Il database deve essere progettato a partire dall’analisi a oggetti dell’applicazione
IngSW - Design - 19 © Ing. Giulio Destri – 2011
Problematiche in applicazioni complesse
• Necessità di accedere alle stesse funzioni da tipi diversi di interfacce (es. approccio multi-canale)
• Necessità di porting di applicazioni su piattaforme diverse con il massimo riuso possibile del codice
• Problematiche di GUI su piattaforme diverse (tipiche di Java)
IngSW - Design - 20 © Ing. Giulio Destri – 2011
Il pattern Model View Controller (MVC)
E’ un modo per suddividere un’applicazione (o anche solo la sua l’interfaccia utente) in tre parti
• Controller = input
• Model = elaborazione
• View = output
IngSW - Design - 21 © Ing. Giulio Destri – 2011
MVC: architettura teorica
MODEL
•Incapsula lo stato dell’applicazione
•Risponde alle domande sullo stato
•Espone le funzionalità dell’applicazione
•Notifica alla View i cambiamenti
VIEW
•Interpreta il Model
•Richiede aggiornamenti al Model
•Trasferisce gli input dell’utente al
Controller
•Permette al Controller di scegliere la
View
CONTROLLER
•Incapsula il comportamento
dell’applicazione
•Mappa gli input dell’utente sugli
aggiornamenti del Model
•Seleziona la View dopo un input
Richiesta stato
Notifica stato
Cambio di stato
Selezione View
Input utente
IngSW - Design - 22 © Ing. Giulio Destri – 2011
MVC: separazione dei ruoli
• L'input dell'utente,
• il programma che modella i processi del dominio business
• la risposta visuale (testo, immagini ecc...) all'utente
• sono separati fra loro e gestiti rispettivamente
– dal modulo controller
– dal model
– dal view
IngSW - Design - 23 © Ing. Giulio Destri – 2011
MVC: il modulo controller
• Il controller interpreta gli eventi di input via tastiera o mouse dell'utente
• Mappa questi eventi
• traducendoli in comandi/segnali
• che invia al modello e/o al view
• per realizzare il cambiamento/azione richiesto
IngSW - Design - 24 © Ing. Giulio Destri – 2011
MVC: il modulo model
• Il model gestisce uno o più elementi dei dati
• Risponde alle interrogazioni relative al suo stato
• Reagisce alle istruzioni relative al cambio di stato
IngSW - Design - 25 © Ing. Giulio Destri – 2011
MVC: il modulo view
• Il view (detto anche viewport) gestisce un'area del display
• E' responsabile della presentazione dei dati all'utente
• attraverso un'apposita combinazione di elementi grafici e testuali
IngSW - Design - 26 © Ing. Giulio Destri – 2011
MVC: approfondimenti sul model
• Il model viene usato
• per trattare le informazioni
• per notificare gli osservatori (ossia i moduli view che mostrano i dati all'utente)
• quando le informazioni cambiano
• (es. il news ticker di borsa)
IngSW - Design - 27 © Ing. Giulio Destri – 2011
MVC: approfondimenti sul model
• Il model contiene soltanto dati e funzionalità legate da uno scopo comune
• Per mettere assieme due gruppi di dati e funzionalità non in relazione tra loro sarebbe bene creare due model separati, uno per ciascuno di essi.
IngSW - Design - 28 © Ing. Giulio Destri – 2011
MVC: approfondimenti sul model
Possiamo considerare il model come
• il risultato di una analisi
• modellazione
• ed adattamento al mondo informatico
• del mondo reale
IngSW - Design - 29 © Ing. Giulio Destri – 2011
MVC: approfondimenti sul model
• Ovvero come una "approssimazione" computazionale
• di un sistema o processo del mondo reale (o meglio del dominio di business)
IngSW - Design - 30 © Ing. Giulio Destri – 2011
MVC: approfondimenti sul model
Il model contiene quindi
• non solo lo stato del sistema reale
• ma anche i suoi principali processi di funzionamento
IngSW - Design - 31 © Ing. Giulio Destri – 2011
MVC: approfondimenti sul model
In pratica quindi in un'applicazione ad oggetti il model
• è l'insieme dei componenti interni dell'applicazione,
• risultanti dalla proiezione sotto forma di classi ed oggetti entro il dominio software
• delle entità del dominio di business e delle loro relazioni
IngSW - Design - 32 © Ing. Giulio Destri – 2011
MVC: approfondimenti sul model
In particolare si può pensare ad un model che crea un “ponte” fra un sistema informatico e la interfaccia utente
• In questo scenario il modello "avvolge" ed astrae le funzionalità del sistema(software o hardware)
• e agisce da collegamento con il mondo esterno
• ovvero l'interfaccia utente
IngSW - Design - 33 © Ing. Giulio Destri – 2011
MVC: approfondimenti sul controller
• Il controller è il modulo attraverso cui l'utente interagisce con l'applicazione
• Un controller riceve l'input dall'utente ed istruisce il model e il view a compiere le azioni associate a tale input
• Il controller è responsabile di mappare le azioni dell'utente sulle risposte dell'applicazione
IngSW - Design - 34 © Ing. Giulio Destri – 2011
MVC: approfondimenti sul view
• Il view ha lo scopo di mappare una visualizzazione (grafica o no) su un dispositivo di output
• Tipicamente il view ha una corrispondenza con le caratteristiche del dispositivo e “sa” come rappresentare i dati su di esso
• Il view si “aggancia” ad un model e visualizza i suoi contenuti sul dispositivo di output
IngSW - Design - 35 © Ing. Giulio Destri – 2011
MVC: approfondimenti sul view
• In più, quando il model cambia, il view automaticamente aggiorna le parti corrispondenti della visualizzazione, in modo da rendere visibili tali cambiamenti
IngSW - Design - 36 © Ing. Giulio Destri – 2011
MVC: approfondimenti sul view
• Per lo stesso model possono esistere diversi view e ciascuno di essi può visualizzare gli stessi dati su dispositivi di output diversi in modo diverso
• Un view inoltre può essere composito, ovvero formato da vari sub-view, eventualmente a loro volta compositi
IngSW - Design - 37 © Ing. Giulio Destri – 2011
MVC: approfondimenti sul view
Graphic
Printer
Internet
CD
Reports
Frankfurt: Wind 4 WNW / Rain / 22°C
News Ticker
Braille
Model:
dati
meteo
Ffff
ffff
fffffffffffffffff
IngSW - Design - 38 © Ing. Giulio Destri – 2011
Scomposizione in elementi tecnici
• Interfacce verso altri sistemi
• Interfacce utente (es. GUI, Web)
• Logica di business
• Base di dati
IngSW - Design - 39 © Ing. Giulio Destri – 2011
Descrizioni delle interfacce
• Interfacce verso altri sistemi
– Titolo
– Descrizione (breve)
– Elenco dei metodi
– Elenco dei possibili errori
• Interfacce utente (es. GUI, Web)
– Prototipo di analisi
– O schematic
IngSW - Design - 40 © Ing. Giulio Destri – 2011
Descrizioni della logica di business
• Titolo
• Descrizione (breve)
• Relazione con altri controller
• Relazione con le entità
• Elenco dei metodi
• Elenco degli errori
• Modello a oggetti
• Osservazioni
IngSW - Design - 41 © Ing. Giulio Destri – 2011
Descrizioni della base di dati
• Titolo
• Attributi
• Metodi
• Possibili errori
• Relazioni
• Generalizzazione/specializzazione
• Consistenza
IngSW - Design - 42 © Ing. Giulio Destri – 2011
Argomenti
• La struttura base di un’applicazione interattiva
• Il modello client-server
• Le architetture derivate da MVC
• La fase di Design
IngSW - Design - 43 © Ing. Giulio Destri – 2011
Definire il processo di Progettazione
• Partendo dai risultati dell’analisi
• La progettazione deve produrre le istruzioni operative per la realizzazione effettiva del progetto informatico (implementazione)
• Con il giusto livello di dettaglio
• Espresse in forma di documenti strutturati
IngSW - Design - 44 © Ing. Giulio Destri – 2011
Progettazione vs. Analisi
• In analisi requisiti e struttura del sistema sono rappresentati in forma astratta e (teoricamente) indipendente dalla tecnologia
• La progettazione tiene conto anche di tutti i fattori relativi all’utilizzo di una tecnologia concreta
In progettazione devono essere definiti tutti gli aspetti necessari per una implementazione non ambigua
IngSW - Design - 45 © Ing. Giulio Destri – 2011
Glossario per la Progettazione
• Architettura
• Componenti
• Sottosistema
• Classe
• Accoppiamento (coupling)
• Coesione
IngSW - Design - 46 © Ing. Giulio Destri – 2011
Glossario per la Progettazione: dati
• Struttura dati piatta (flat o flat-file)
• RDBMS
• OODBMS
IngSW - Design - 47 © Ing. Giulio Destri – 2011
Analisi delle varianti tecniche: 2 estremi
• Decidere sulla base di criteri indipendenti dallo specifico progetto – Standard aziendali
– Skill del gruppo di sviluppo
– Disponibilità di strumenti/ambienti di sviluppo
• Tenere conto delle caratteristiche determinanti del progetto – Obiettivi, contesti
– Tecnologie di comprovata efficacia
IngSW - Design - 48 © Ing. Giulio Destri – 2011
Gli ambienti di sviluppo: caratteristiche
• Supporto dei concetti di architettura
• Disponibilità di componenti ad alte prestazioni
• Disponibilità di componenti per le interfacce utente
• Disponibilità di concetti di base nel linguaggio di programmazione
• Portabilità dell’applicazione
• Supporto della gestione delle versioni
IngSW - Design - 49 © Ing. Giulio Destri – 2011
Design base dati: IDE vs. DB
IDE DB
Sviluppo da zero Basato su applicazioni esistenti
Nuova progettazione UI UI = vista del DB
Nessun componente Componenti specifici
Soluzioni (quasi) illimitate Soluzioni dipendenti dal DB
Prodotto = estensioni funzioni richieste
Prodotto = database + funzionalità
Linguaggio + IDE selezionabili
Linguaggio + IDE vincolati dal DB
IngSW - Design - 50 © Ing. Giulio Destri – 2011
I requisiti di progettazione
• Documentazione appropriata
• Sicurezza
• Affidabilità
• Garanzie contro perdite dei dati
• Prestazioni
IngSW - Design - 51 © Ing. Giulio Destri – 2011
Architettura di sistema
• Documentazione appropriata
• Sicurezza
• Affidabilità
• Garanzie contro perdite dei dati
• Prestazioni
IngSW - Design - 52 © Ing. Giulio Destri – 2011
Interdipendenza delle classi
• Accoppiamento: misura della dipendenza tra due elementi dello stesso livello (2 moduli, sottosistemi, classi)
• Coesione: misura per l’unione interna di un elemento
IngSW - Design - 53 © Ing. Giulio Destri – 2011
Il passaggio del controllo fra le classi
• Stair: controllo passato in scala e diviso linearmente fra le classi
• Fork: oggetto coordinatore che passa il controllo a oggetti che glielo tornano
IngSW - Design - 54 © Ing. Giulio Destri – 2011
Architettura di sistema (software)
• Descrizione degli elementi partendo dai quali vengono creati i sistemi
• Interazioni tra gli elementi
• Modelli che gestiscono la composizione degli elementi
• Limiti di questi modelli
Un determinato sistema viene descritto attraverso un insieme di componenti e le interazioni fra di essi
IngSW - Design - 55 © Ing. Giulio Destri – 2011
Varie architetture
• Sistemi di flusso di dati
• Sistemi call and return
• Componenti indipendenti
• Macchine virtuali
• Sistemi centrati sui dati
IngSW - Design - 56 © Ing. Giulio Destri – 2011
Caratteristiche di un’architettura
• Definire con precisione il confine (cosa fa e cosa non fa parte del sistema)
• Interfacce diverse per possibili input
• Hardware sottostante
IngSW - Design - 57 © Ing. Giulio Destri – 2011
Descrizione di un’architettura
• Suddivisione dei compiti tra i componenti
• Scalabilità
• Manutenzione
Diagrammi di interazione su sottosistemi
Diagrammi dei componenti
Diagrammi di deployment
IngSW - Design - 58 © Ing. Giulio Destri – 2011
Le interfacce entro un’architettura
• Nome (di ogni metodo)
• Descrizione del comportamento
• Elenco e descrizione dei parametri
• Valori di ritorno
• Errori
IngSW - Design - 59 © Ing. Giulio Destri – 2011
Architettura: check-list
• I requisiti si riflettono adeguatamente nella progettazione dell’architettura?
• Le varie parti sono concettualmente bilanciate?
• Resistenza, affidabilità, sicurezza?
• Decisioni motivate?
• Come si può riusare il codice in varie architetture esecutive?
IngSW - Design - 60 © Ing. Giulio Destri – 2011
Architettura: check-list
• Motivazioni per decidere tra make e buy?
• Rapporto dimensioni/risorse?
• Suddivisione fra i singoli programmatori?
• Chi fa i controlli di qualità?
IngSW - Design - 61 © Ing. Giulio Destri – 2011
Componenti: check-list
• Da analisi: tutti i casi d’uso e i relativi componenti sono stati realizzati?
• Tutte le interfacce esterne dei componenti sono rappresentate?
• Tutte le interfacce tra componenti sono rappresentate?
• Tutti gli oggetti importanti sono rappresentati?
IngSW - Design - 62 © Ing. Giulio Destri – 2011
Progettazione di UI
• Conoscere gli utenti
• Progettare in modo coerente
• Usare le metafore giuste
• Interagire in modo diretto e completo
• Guidare gli utenti senza condizionarli
• Dare il giusto feedback
• Tollerare gli errori (applicazione robusta)
IngSW - Design - 63 © Ing. Giulio Destri – 2011
Test di usabilità di UI
• Finestre di dialogo semplici e naturali
• Usare il linguaggio dell’utente
• Ridurre il carico di memoria
• Mantenere la coerenza
• Prestare attenzione al feedback
• Specificare una via d’uscita ben segnalata
• Mettere a disposizione procedure abbreviate
• Messaggi di errore validi
• Impedire errori
IngSW - Design - 64 © Ing. Giulio Destri – 2011
La logica di business
• Espandere il modello di analisi per realizzare un sistema realistico
Coerente con le possibilità offerte dall’ambiente di sviluppo
Coerente con il contesto architetturale
IngSW - Design - 65 © Ing. Giulio Destri – 2011
La logica di business: class diagram
• Visibilità pubblica/privata/protetta
• Attributi a livello di classe
• Metodi a livello di classe
• Costruttori/distruttori
• Metodi set/get (accesso “diretto” su attributi)
• Gestione degli errori
• Valutazione delle condizioni operative
• Valutazione del comportamento dinamico
IngSW - Design - 66 © Ing. Giulio Destri – 2011
La base di dati
Persistenza dei dati da garantire
• Flat-file
• Relazionale
• OODBMS
• Misto OO-RDBMS
IngSW - Design - 67 © Ing. Giulio Destri – 2011
Check-list globale della progettazione
• Astrazione
• Modularità
• Coesione
• Accoppiamento (debole)
• Information hiding (e struttura)
• Perfezionamento graduale – Architettura
– Sottosistemi
– Componenti
– Strutture dati
– Algoritmi
IngSW - Design - 68 © Ing. Giulio Destri – 2011
Criteri di qualità della progettazione
• Comprensibilità
• Documentazione
• Adattabilità
• Tracciabilità
• Solidità
• Complessità
• Manutenibilità