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


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


Argomenti

• La struttura base di un’applicazione interattiva

• Il modello client-server

• Le architetture derivate da MVC

• La fase di Design


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)


La struttura dell’applicazione

Dati

Logica

business

Interfaccia

utente


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


2-Tier Client/Server


3-Tier Client/Server


Multi-Tier Client/Server


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


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


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


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


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


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?


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


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)


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


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)


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


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


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


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


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


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


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)



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



Possiamo considerare il model come

• il risultato di una analisi

• modellazione

• ed adattamento al mondo informatico

• del mondo reale



• Ovvero come una "approssimazione" computazionale

• di un sistema o processo del mondo reale (o meglio del dominio di business)



Il model contiene quindi

• non solo lo stato del sistema reale

• ma anche i suoi principali processi di funzionamento



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



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


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


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



• In più, quando il model cambia, il view automaticamente aggiorna le parti corrispondenti della visualizzazione, in modo da rendere visibili tali cambiamenti



• 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



Graphic

Printer

Internet

CD

Reports

Frankfurt: Wind 4 WNW / Rain / 22°C

News Ticker

Braille

Model:

dati

meteo

Ffff

ffff

fffffffffffffffff


Scomposizione in elementi tecnici

• Interfacce verso altri sistemi

• Interfacce utente (es. GUI, Web)

• Logica di business

• Base di dati


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


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


Descrizioni della base di dati

• Titolo

• Attributi

• Metodi

• Possibili errori

• Relazioni

• Generalizzazione/specializzazione

• Consistenza


Argomenti






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


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


Glossario per la Progettazione

• Architettura

• Componenti

• Sottosistema

• Classe

• Accoppiamento (coupling)

• Coesione


Glossario per la Progettazione: dati

• Struttura dati piatta (flat o flat-file)

• RDBMS

• OODBMS


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


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


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


I requisiti di progettazione

• Documentazione appropriata

• Sicurezza

• Affidabilità

• Garanzie contro perdite dei dati

• Prestazioni


Architettura di sistema

• Documentazione appropriata

• Sicurezza

• Affidabilità

• Garanzie contro perdite dei dati

• Prestazioni


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


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


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


Varie architetture

• Sistemi di flusso di dati

• Sistemi call and return

• Componenti indipendenti

• Macchine virtuali

• Sistemi centrati sui dati


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


Descrizione di un’architettura

• Suddivisione dei compiti tra i componenti

• Scalabilità

• Manutenzione

Diagrammi di interazione su sottosistemi

Diagrammi dei componenti

Diagrammi di deployment


Le interfacce entro un’architettura

• Nome (di ogni metodo)

• Descrizione del comportamento

• Elenco e descrizione dei parametri

• Valori di ritorno

• Errori


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?


Architettura: check-list

• Motivazioni per decidere tra make e buy?

• Rapporto dimensioni/risorse?

• Suddivisione fra i singoli programmatori?

• Chi fa i controlli di qualità?


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?


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)


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


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


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


La base di dati

Persistenza dei dati da garantire

• Flat-file

• Relazionale

• OODBMS

• Misto OO-RDBMS


Check-list globale della progettazione

• Astrazione

• Modularità

• Coesione

• Accoppiamento (debole)

• Information hiding (e struttura)

• Perfezionamento graduale – Architettura

– Sottosistemi

– Componenti

– Strutture dati

– Algoritmi


Criteri di qualità della progettazione

• Comprensibilità

• Documentazione

• Adattabilità

• Tracciabilità

• Solidità

• Complessità

• Manutenibilità


Sommario





Il Project Management nei progetti IT

Documents

Transcript of Il Project Management nei progetti IT