Progettazione di SI web-based B. Pernici. Sommario Progettazione (come processo) Documenti di progetto Scelte architetturali.

Presentazione sul tema: "Progettazione di SI web-based B. Pernici. Sommario Progettazione (come processo) Documenti di progetto Scelte architetturali."— Transcript della presentazione:

1 Progettazione di SI web-based B. Pernici

2 Sommario Progettazione (come processo) Documenti di progetto Scelte architetturali

3 Bibliografia Conallen, cap. 6, cap. 7 (con richiami a cap. 3 e 4) Sito del libro: http://www.wae-uml.org/http://www.wae-uml.org/ Approfondimenti per chi fa il progetto: –L.A. Maciaszek, Sviluppo di sistemi informativi con UML, Addison Wesley, 2002 –Sito del libro: http://www.comp.mq.edu.au/books/maciaszek/

4 Processo di sviluppo di un SI Pianificazione iniziale Pianificazione Requisiti Analisi Design Implementazione Deployment Test Valutazione

5

6 Iterazione Identificazione dei requisiti del sistema Definizione dell’architettura Analisi dei requisiti Design Implementazione Test Sviluppo ambiente Gestione dei cambiamenti Gestione del progetto NB: sono attività che si svolgono in parallelo Si conclude con: –Valutazione con i referenti –Ripianificazione per l’eventuale iterazione successiva

7 Partecipanti e prodotti nel processo di sviluppo requisiti componenti Class diagrams Requisiti scenari d’uso Use case State diagrams Diagrammi di deployment management implementatori progettisti analisti UX team referenti integratori architetti Esperti di dominio Modello

8 Analizza azienda e problemi percepiti Interazione con i referenti (stakeholders) Comprendere le attivita’ dell’azienda

9 Sviluppo del modello del dominio Diagramma delle classi (o ER) Rappresentazione dei principali processi aziendali attuali (activity diagram di alto livello) Glossario: elenco dei termini e definizioni

10 Sviluppo “vision” Tratto dall’analisi dei risultati dei passi precedenti Esprime il contesto e gli obiettivi dell’intero progetto Spesso serve a farsi finanziare il progetto Struttura: –Introduzione: perche’ si realizza il sistema, identificazione referenti, possibili alternative con valutazione costi e benefici, priorita’ –Background: motivazioni di supporto, contesto aziendale, sistemi preesistenti –Requisiti e funzionalita’ generali: breve descrizione di cosa deve fare il sistema –Definizione dell’architettura generale del sistema (software architecture document)

11 Esempio vision Introduzione –L’obiettivo del progetto e’ quello di offrire ai clienti della ditta COMP i servizi di vendita su canali alternativi a quelli tradizionali. In particolare in questo progetto si esamina l’offerta di servizi su internet, ma nello sviluppo del progetto si porra’ particolare attenzione allo possibilita’ di offrire gli stessi servizi in futuro su altri canali (call center, su smartphone) estendendo il presente progetto. Si proporra’ quindi un’architettura flessibile basata sull’utilizzo di web- services. Alternative possibili ….. –I referenti nel corso del progetto saranno l’amministratore delegato della ditta COMP, il responsabile dei sistemi informativi, e verra’ selezionato un gruppo di grandi clienti a cui verranno presentate le caratteristiche del progetto.

12 Esempio vision (2) Background –Attualmente le vendite avvengono presso I punti di vendita. Tutti i punti di vendita sono collegati al sistema informativo della ditta COMP su cui sono registrati i componenti disponibili e le possibili configurazioni. –E’ possibile effettuare i pagamenti degli ordini al momento dell’acquisto anche con carta di credito e su richiesta emettere fatture

13 Esempio vision (3) Requisiti generali e funzionalita’ –L’azienda COMP offre la possibilita’ di acquistare computer via Internet. Il cleinte puo’ selezionare un computer sulla pagina web dell’azienda. Il cliente puo’ selezionare una configurazione gia’ predisposta oppure comporre il proprio sistema assemblando componenti, con l’assistenza del sistema. Per ogni configurazione il cliente puo’ valutare il costo. –Per ordinare il cliente deve fornire le informazioni per la consegna e il pagamento. Il pagamento deve avvenire con carta di credito. Una volta inviato l’ordine, viene inviata via mail una conferma al cliente. Il cliente in attesa di consegna puo’ controllare lo stato dell’ordine in ogni momento. –Nel back-end viene controllata la solvibilita’ del cliente, viene richiesta al magazzino la configurazione ordinata, viene stampata la fattura e contattato un servizio di spedizione per effettuare la consegna.

14 Sviluppo di un piano di progetto Gantt –Attivita’ e sottoattivita’ (numerate) –Inizio e durata –Risorse (mesi uomo, costi) –Scadenze (milestone)

15 Esempio di Gantt

16 Definizione dell’architettura Architettura: –Significato diverso secondo diversi punti di vista Punti di vista: –Requisiti –Design –Realizzazione –Test

17 Definizione dell’architettura Porre vincoli architetturali alla base del progetto (design e implementazione) Documento che contiene descrizione delle principali scelte architetturali e le loro motivazioni –Es. piattaforma, set di caratteri Punti di vista espressi nei documenti di progetto (es requisiti non funzionali pongono vincoli architetturali)

18 Punto di vista dei requisiti Significant Architectural Requirements (SAR) Vista sul dominio –Contesto –Standard e regolamentazione Vista sui requisiti funzionali –Il sistema “osservabile” Vista sui requisiti non funzionali –Performance, robustness, security

19 Punto di vista del progetto (design) Progetto dell’architettura Sistemi, piattaforme, middleware componenti di terze parti Vista della struttura logica del sistema –Oggetti logici e loro relazioni strutturali Vista sui processi –Esecuzione parallela

20 Punto di vista della realizzazione Specifica dell’architettura Meccanismi di comunicazione ed invocazione (CORBA vs RMI vs SOAP vs DCOM) Associazione dei processi ai nodi elaborativi Librerie, namespace condivisi Codice: esempi di codice chiave (parti da standardizzare, ad es. algoritmi di sorting)

21 Punto di vista del testing Piano di test –Delle funzionalita’ –Dell’architettura

22 Attività architetturali Analizzare e assegnare priorita’ agli use case per individuare requisiti architetturali significativi (SAR) Definire una architettura candidata e preparare e valutare prototipi Definire una strategia di riuso

23 Esempio SAR –Il sistema chiede il nome e l’indirizzo. L’utente compila un modulo sullo schermo. … Quando inserisce il CAP, il sistema riempie automaticamente il nome della citta’ se non e’ gia’ stato riempito. –Quando l’indirizzo e’ completo il cliente preme il tasto Avanti per proseguire nel completamento dell’ordine

24 Esempio (2) SAR: –CAP significa solo clienti italiani? –Quale ipotesi lato client? Client ad hoc per l’applicazione disponibile per ogni utente? Internet: non si puo’ ipotizzare che vi sia un sw caricato sul client

25 Client dinamici Javascript Applet ActiveX/COM

26 Clienti dinamici scripting lato client BROWSER HTML Script Compiled modules DOM DOM: Document Object Model interface

27 Javascript Linguaggio che permette di scrivere script all’interno di pagine web … Non ha niente a che fare con Java Gli script vengono eseguiti lato client dal browser Gli script possono accedere a oggetti del documento e proprietà del browser, modificandoli dinamicamente –Es: azione cambio colore al passaggio del mouse (event handler onMouseOver)

28 Principali handler onAbort (interruzione caricamento immagine) onClick onChange (cambia il valore di un elemento) onError onLoad onMouseOver onReset onSelect (selezione di un elemento di input) onSubmit onUnload

29 frm2 t1 t4

30 Esempi di JavaScript function CalcSomma() { var alfa = 10 * window.document.frm2.t1.value; var beta = 20 * window.document.frm2.t2.value; var gamma = 30 * window.document.frm2.t3.value; window.document.frm2.t4.value=alfa+beta+gamma; }

31 Esempi JavaScript Esempio onChange Prodotto …… Alfa 10 …….. Totale

32 Applet Uso di Java per il controllo dell’interfaccia utente lato client, puo’ usare direttamente il DOM Identificate dal tag nella pagina HTML Si specifica da dove scaricare l’applet

33 Applicazioni complesse: un esempio di modulo intelligente (in sist. distribuiti) client CAP Web server Richiesta form Risposta 3 minuti Risposta con form con inclusione script per completare citta’ da CAP

34 CAP Web server Sottomissione form invocata da script Java Risposta 3 secondi Risposta con form ricostruito con completamento citta’ da CAP Seconda soluzione CAP 00198 ROMA

35 Web server L’oggetto comunica direttamente con l’application server Risposta < 1 sec Oggetto distribuito che comunica direttamente con un oggetto sul lato server e restituisce la citta’ dato il CAP Terza soluzione CAP 00198 Application server

36 Pattern architetturali per il presentation tier Thin web client –Ci si basa su browser in grado di gestire form Fat (thick) web client –Una parte significativa di business logic e’ eseguita sulla macchina client Web delivery pattern –Il browser utilizzato come strumento di interazione con oggetti distribuiti (puo’ utilizzare non solo HTTP, ma anche IIOP e DCOM)

37 Thin web client Punto di vista dei requisiti Limitare le funzionalita’ che si suppongono disponibili nel browser Cookie? (disabilitabili) Firewall (uso porte standard)

38 Punto di vista architettura –Web browser –Web server (scripting?) –HTTP connection (SSL?) –Pagine dinamiche Linguaggi, interfacce –Application server –DB server

39 I componenti essenziali dell’architettura: INTERNET Web Server Web Server Script Engine Script Engine Application Server Application Server Database Server Database Server Scelte architetturali per decidere: Quali componenti vanno su macchine separate Quante macchine servono per ogni componente Come collegare tra loro componenti

40 Configurazione 1: SINGLE PROCESSOR INTERNET Una sola macchina (Host 1) ospita: Web Server Script execution engine Database

41 Il router/ firewall Router: –Punto di connessione Internet/ Intranet –Consente a browser esterni di connettersi al Web Server Firewall: –Separa il mondo esterno (Internet) dalla rete aziendale (Intranet) –Blocca i tentativi di intrusione e le richieste non autorizzate (attraverso Access Control Rules) Può essere un unico dispositivo che svolge le due funzioni Internet Intranet

42 SINGLE PROCESSOR: valutazione INTERNET Prestazioni: legata alle caratteristiche della macchina (velocità CPU, HDD, connessione di rete, DBMS). Criticità: Database e Web Server sulla stessa macchina. Sono due processi che occupano molte risorse (RAM, tempo-CPU) Scalabilità: unica possibilità è upgrade della macchina (aggiunta RAM, cambio CPU o dischi, …) Disponibilità: se cade un componente, tutto il sistema è fermo Mantenimento dello stato: semplice perché su macchina singola (memorizzato nello script engine e/o nel database) Sicurezza: dati non difesi se il firewall viene superato Costo: basso, se non serve hw ad alte prestazioni Complessità: soluzione più semplice da installare e mantenere

43 Config. 2: SEPARAZIONE DEL DB SERVER INTERNET Web Server e Script execution engine sono ospitati su una macchina (Host 1) Il Database Server è ospitato su un altro calcolatore (Host 2) L’aggiunta di un firewall intermedio aumenta la sicurezza dei dati (data tier) (middle tier)

44 SEPARAZIONE DEL DB: valutazione INTERNET Prestazioni: dimensionamento migliore delle due macchine Es.: potenziamento accesso/mirroring dei dischi del DB server Scalabilità: possibilità di intervenire separatamente su middle tier e data tier In genere è il middle tier che raggiunge per primo la saturazione Disponibilità: un componente fermo blocca ancora il sistema Sicurezza: dati su macchina separata sono più sicuri; un firewall tra middle e data tier può bloccare le richieste HTTP (attacchi) e consentire solo le richieste al DB

45 REPLICAZIONE E PARALLELISMO INTERNET prestazioni disponibilità scalabilità sono limitate dalla presenza di UNA SINGOLA ISTANZA DI OGNI COMPONENTE Soluzione: REPLICAZIONE Replico i processi critici (Web Server, script engine,…) Tengo in esecuzione più copie in parallelo di ogni processo Engine Replicazione : applicabile a qualsiasi livello dell’architettura

46 Vantaggi della replicazione INTERNET Prestazioni consente LOAD-BALANCING: distribuzione del carico di lavoro sui server/ processi in modo bilanciato Scalabilità Se necessario, è possibile aggiungere nuove istanze di processi (o macchine server, in cluster ) Disponibilità consente FAIL-OVER: se cade uno dei processi, il suo carico di lavoro viene distribuito sui processi funzionanti e il sistema continua a fornire il servizio

47 Config. 3: REPLICAZIONE DEL WEB SERVER INTERNET Più copie del Web Server funzionanti in parallelo Router/firewall fa da NETWORK DISPATCHER (bilancia il carico di lavoro tra i diversi Web Server) Alcuni server possono usare SHTTP per garantire la sicurezza: il dispatcher invia tutte le richieste SHTTP al server sicuro

48 Il problema delle sessioni utente INTERNET Bisogna garantire che lo stato dell’utente sia mantenuto SUL LOAD-BALANCING: STICKY SESSION: Tutte le richieste dello stesso client devono essere inviate dal dispatcher allo stesso server (lo stato utente è memorizzato sul server!) Il dispatcher deve avere una certa “intelligenza” per riconoscere le richieste di uno stesso utente. Non basta l’IP del client: potrebbe essere usato da più utenti di una intranet SUL FAIL-OVER: Le sessioni memorizzate dal Web server guasto devono essere recuperate ed usate dagli altri Web server (che riceveranno le richieste seguenti degli utenti connessi al server guasto) I dati di sessione devono essere memorizzati in modo duraturo (es. nel DB) [Soluzione costosa per le prestazioni]

49 REPLICAZIONE DEL WEB SERVER: valutazione INTERNET Prestazioni: più elevate grazie al load-balancing Scalabilità: possibilità di aggiungere nuovi Web server Disponibilità: se cade un Web server, il suo traffico è ridiretto su una sua replica Mantenimento dello stato: necessari meccanismi sticky session e memorizzazione stato per il fail-over Sicurezza: possibilità di avere uno o più server sicuri Complessità: accresciuta dalla replicazione

50 Configurazione 4: CON APPLICATION SERVER INTERNET Centralizzazione della business logic nell’App. Server mediante oggetti riusabili (per esempio, Enterprise Java Beans, componenti MS DCOM) Gli oggetti possono essere invocati da qualunque applicazione aziendale (anche non Web) La gestione di parallelismo, replicazione, sicurezza, disponibilità è garantita dall’application server ed è trasparente al programmatore

51 Configurazione 4: CON APPLICATION SERVER INTERNET Bilanciamento e fail over a livello degli oggetti applicativi Parallelismo DINAMICO: il numero di processi allocati e di istanze di oggetti è scelto a run-time in base al traffico reale Possibilità di effettuare catene di operazioni sugli oggetti in modo transazionale Application server isolabile con un ulteriore firewall

52 Application Server: valutazione INTERNET Prestazioni: elevate grazie al load-balancing dinamico Scalabilità: virtualmente illimitata replicando l’application server Disponibilità: capacità di fail-over a livello degli oggetti eseguiti all’interno dell’application server, gestione delle transazioni Complessità: ambienti generalmente complessi da manutenere