Analisi dettagliata e design

B. Pernici

D. Ardagna

Sommario

• Analisi dettagliata– Separazione interfaccia, controllo, entita’

• Design– Logical view– Progettazione dei dati– Component view

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

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

Analisi dettagliata

• Packages

• Boundary-control-entity

(interfaccia, controllo, entita’)

•Dipendenza•Generalizzazione•Appartenenza

Package

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

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

Primo passo analisi Use case: Mostrare Configurazione Computer Standard

Poca enfasi(gia’ in UX)

Funzionalita’

Un diagramma per ogni caso d’uso

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

Elaborazione analisi

Operazioni richieste

dall’utente

Funzionalità per creare le

pagine

Sequence diagram per l’analisi

• Interazioni tra oggetti corrispondenti alle classi del modello di analisi

• Elaborazione del diagramma di sequenza di interazione precedente

Sequece Diagram (1)

Display Company Page

Display Categories

Display Products

Display Product detail

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

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

Diagramma dei componenti

Diagramma dei componenti

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

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%>”

«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

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

«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

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

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

«Static Page»

• Classe del metamodello: Componente

• Pagina HTML statica

• Vincoli: non può invocare componenti logici sul server

«Dynamic Page»

• Classe del metamodello: Componente

• Pagina dinamica invocata dal client. Può modificare lo stato del server ed elaborare input fornito dal browser

Seconda fase di design: componenti

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

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

Modello J2EE

• Utilizzare una Servlet per validare input fornito dall’utente• La servlet delega la costruzione della risposta ad una pagina

JSP

View

ControllerModel

JavaBeans, relazioni in DB, classi Middleware

JSP pages, componenti JavaBeans, classi, (Servlet), CGI

Classi controller, servlet, (client side scripting)

Pattern architetturale MVC

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

Controller FSM

Complessita’R

obus

tezz

a

Pagine HMTL

JSP basic e Servlet

JSP, JavaBeans

JSP, JavaBeanse EJB

Pagine HMTL

Pagine HMTL

JSP

Servlet

Pagine HMTL

JSP

ServletJavaBeans

Pagine HMTL

JSP

ServletJavaBeans

Eneterprise JavaBeans

Modello J2EE

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)

Esempio ordine

• Order boundary

• Order controller

• Order entity (proxy)

• Order entity JavaBean

• Order in DBMS (tabelle relazionali)

Esempio ordine (<<controller>>, <<entity>>)

Order “proxy”

“Pages”