Scaricare la presentazione
La presentazione è in caricamento. Aspetta per favore
1
Analisi dettagliata e design
B. Pernici D. Ardagna
2
Sommario Analisi dettagliata Design
Separazione interfaccia, controllo, entita’ Design Logical view Progettazione dei dati Component view
3
Obiettivi Trasformare i requisiti in un progetto che puo’ essere implementato in un’applicazione software Analisi: utilizza casi d’uso e requisiti funzionali per realizzare un modello del sistema Progettazione: raffinamento del modello di analisi tenendo conto dei requisiti non funzionali dei vincoli architetturali
4
Processo di sviluppo Analisi e progettazione possono evolvere come due attivita’ separate o come parte di una stessa attivita’ Analisi e progettazione possono iniziare prima che la fase di raccolta dei requisiti sia completamente terminata Priorita’: gestione del rischio
6
Analisi dettagliata Packages Boundary-control-entity
(interfaccia, controllo, entita’)
7
Package Dipendenza Generalizzazione Appartenenza
8
Design package A partire dai casi d’uso di alto livello
Identificazione classi: analisi dei nomi e dei verbi Suddividere il modello in base agli elementi simili (classi e oggetti) Obiettivi: Comprensione Coesione Scarso accoppiamento Gerarchie comunque poco profonde
9
Boundary - control - entity
Secondo Conallen (interpretazione pattern model-view-controller): stereotipi Boundary Control Entity Separare logica applicativa da presentazione e da dati presentati all’utente Esaminare ciascun caso d’uso “Coordinamento” tra modello di navigazione e modello concettuale Si fara’ evolvere in modello di design
10
Primo passo analisi Use case: Mostrare Configurazione Computer Standard
Poca enfasi (gia’ in UX) Un diagramma per ogni caso d’uso Funzionalita’
11
Regole di robustezza Accesso a entita’ tramite controllori
Interfacce per gestire interazione con attori Entita’: dati di interesse, persistenti Da UX model: corrispondenza schermate – interfacce Da modello concettuale dei dati: corrispondenza entità con classi del class diagram
12
Elaborazione analisi Operazioni richieste dall’utente
Funzionalità per creare le pagine
13
Sequence diagram per l’analisi
Interazioni tra oggetti corrispondenti alle classi del modello di analisi Elaborazione del diagramma di sequenza di interazione precedente
14
Sequece Diagram (1) Display Company Page Display Categories
Display Products Display Product detail
16
Corrispondenza con il modello UX
Definire la corrispondenza partendo dalle classi del modello di analisi verso le schermate del modello UX: il modello di analisi e’ cosi’ il proprietario privilegiato
17
Design Obiettivo: raffinare il modello di analisi in modo che possa essere implementato con i componenti dell’architettura Raffinamento classi, introduzione di classi di servizio Vista dei componenti
18
Diagramma dei componenti
19
Diagramma dei componenti
20
Design Prima fase, progettazione comunque di alto livello
Partizionamento degli oggetti in livelli, quali client e server Separazione e definizione delle interfacce utente e pagine Web Rappresentare le pagine Web come elementi del modello
21
UML Web Application Extension
Stereotipo: associa un nuovo significato semantico a un elemento del modello. Rappresentazione: nuova icona o «» Vincolo: condizioni sotto le quali il modello puo’ essere considerato ben formato. Rappresentazione: stringhe comprese tra parentesi graffe Es. parameters=“productId=<%id%>”
22
«Server Page» Classe del metamodello: Classe
Pagina Web che ha contenuti costruiti da un Server per ogni richiesta. Può contenere script che possono interagire con altre risorse lato server (logiche applicative, database,…). Le operazioni rappresentano le funzioni implementate dallo script, le proprieta’ le variabili che sono visibili nella pagina Vincoli: possono avere relazioni solo con altri oggetti sul server
23
«Client Page» Classe del metamodello: Classe
Pagina HTML visualizzata in un Browser. Le operazioni corrispondono a funzioni di script (browser) e le proprieta’ alle variabili dichiarate nelle etichiette di script della pagina. Possono avere associazioni con altre pagine client o server.
24
«input Form» Classe del metamodello: Classe
Insieme di campi di input parte di una pagina Client. Non ha operazioni Valori etichetta: il metodo (GET o POST) usato per inviare i dati all’URL specificato per action
25
Stereotipi per le associazioni
«link»: da pagina client a risorsa lato server. Astrazione dell’ancora HTML. Parameters parametri HTTP «build»: da una pagina server a una client. Output HTML generato dell’esecuzione di una pagina server «submit»: da form HTML a pagina server. Astrazione dell’invio dati di una form HTML «redirect»: da pagina client o server a un’altra risorsa. Impone al client di richiedere un’altra risorsa
26
Stereotipi per le associazioni
«forward»: da pagina server ad un’altra pagina server o client. Delega di elaborazione di una richiesta «object»: contenimento di una classe della vista logica da parte di una pagina client «include»: contenimento di una pagina client o server da parte di una pagina server
28
«Static Page» Classe del metamodello: Componente Pagina HTML statica
Vincoli: non può invocare componenti logici sul server
29
«Dynamic Page» Classe del metamodello: Componente
Pagina dinamica invocata dal client. Può modificare lo stato del server ed elaborare input fornito dal browser
30
Seconda fase di design: componenti
31
Partizionamento degli oggetti
Attivita’ critica che dipende dall’architettura dell’applicazione Gli oggetti possono risiedere sul server sul client o su entrambi Es. oggetti per la convalida campi: sul client Es. oggetti contenitore (catalogo, clienti, …) sul server Es. fattura? Su entrambi, server ciclo di vita e persistenza, client documento XML
32
Partizionamento degli oggetti
Thick Web client: possono esistere sul client oggetti che non hanno associazioni e dipendenze con oggetti server. Tipicamente oggetti per la convalida input, controlli interfaccia utente, ecc. Web delivery client: la suddivisione dipende dalla natura del singolo oggetto Togliere parte del carico dal server Posizionare gli oggetti dove possono essere piu’ efficaci Regolare generale: semplificare accesso ai dati e collaborazioni
33
Modello J2EE Utilizzare una Servlet per validare input fornito dall’utente La servlet delega la costruzione della risposta ad una pagina JSP
34
Pattern architetturale MVC
JSP pages, componenti JavaBeans, classi, (Servlet), CGI View Model Controller JavaBeans, relazioni in DB, classi Middleware Classi controller, servlet, (client side scripting)
35
Pattern architetturale MVC
Model: dati dell’applicazione e regole che governano accesso e modifica dei dati. View: visualizza il contenuto del Model. Dipende dal client (Web based, desktop…). Allo stesso Model e’ possibile associare View differenti Controller: specifica il comportamento dell’applicazione, interpreta input dell’utente e richiede l’esecuzione di opportune operazioni da parte del Model. Finite State Machine. Client differenti dovrebbero condividere il Controller
36
Controller FSM
37
Complessita’ Pagine HMTL JSP basic e Servlet JSP, JavaBeans JSP, JavaBeans e EJB Robustezza Pagine HMTL Pagine HMTL JSP Servlet Pagine HMTL JSP Servlet JavaBeans Pagine HMTL JSP Servlet JavaBeans Eneterprise
38
Modello J2EE
39
Design o Implementazione ???
Presentation tier Pagine JSP, Pagine HTML, classi Java di servizio Application tier (JavaBeans, Middleware) Control Session data management (alcuni dati non persistenti) Resource tier Gestione persistenza Collegamento a DB e ad altre risorse EIS (Enterprise Information System)
40
Esempio ordine Order boundary Order controller Order entity (proxy)
Order entity JavaBean Order in DBMS (tabelle relazionali)
41
Esempio ordine (<<controller>>, <<entity>>)
Order “proxy”
42
“Pages”
Presentazioni simili
© 2024 SlidePlayer.it Inc.
All rights reserved.