analisi dettagliata e design b. pernici m.g. fugini aa 2004-05

Post on 01-May-2015

213 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Analisi dettagliata e design

B. Pernici

M.G. Fugini

AA 2004-05

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

Package

Analysis model

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

Mostra configurazione computer standard

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

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

Elaborazione analisi

Operazioni richieste

dall’utente

Funzionalità necessarie per

creare le pagine,Controlla la

sequenza degli stati

Sequence diagram per l’analisi

• Interazioni tra oggetti corrispondenti alle classi del modello di analisi

• Elaborazione del diagramma di sequenza di interazione precedente

Sequence Diagram (1)

Display Company Page

Display Categories

Display Products

Display Product detail

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

Order “proxy”

Controller FSM

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 – vista logica

• 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

Stereotipi per le associazioni

• «redirect»: da pagina client o server a un’altra risorsa. Impone al client di richiedere un’altra risorsa

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

PaymentInformationRequest

<<server page>>

PaymentConfirmation<<server page>>

<<input form>>

<<client page>>

Design – vista componenti

• Identificazione dei componenti software da realizzare

• Scelte implememntative sulla piattaforma tecnologica

«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

Model

ControllerView

JavaBean, relazioni in DB, componenti sw

HTML, JSP, classi, JavaBean, servlet, CGI

servlet, classi, componenti sw

Pattern architetturale MVC

State query Notifica cambiamento

metodo

evento

Cambia stato

Azioni utente

Selezione visualizzazione

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

Modello J2EE

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

Enterprise JavaBeans

Componenti in J2EE

Componenti

• 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: classi per “ordine”

• Order boundary

• Order controller

• Order entity (proxy)

• Order entity JavaBean

• Order in DBMS (tabelle relazionali)

top related