Modellazione UML per il WEB: Approccio di Conallen

UML & UML & WEbWEb-- Approccio WAE: Approccio WAE: ConallenConallen --

Master in Web

TechnologyCorso di: Modellazione UML per il WebDocente: Henry MucciniVIII Edizione 2012/2013Dipartimento di Ingegneria e Scienze dell’Informazione e MatematicaUniversità degli Studi dell’Aquila

Copyright Notice

» Il materiale riportato in queste slide puo’ essere riutilizzato, parziale o totalmente, a patto che le fonti e gli autori vengano citati

Master in Web Technology VIII Edizione 2012/2013 | Henry Muccini: UML for Web Applications2

Henry Muccini

Conallen> Approccio di Conallen per la modellazione di

applicazioni Web tramite UML- Uso dei Meccanismi di estensione di UML

> Tool support> Esempio


Approccio di Approccio di ConallenConallen per il per il


Approccio di Approccio di ConallenConallen per il per il WebWeb

Conallen

» Considera tutto il processo:> Requisiti

> Analisi

> Design

> Implementazione


Implementazione

» Implementa il processo di sviluppo RUP per applicazioni Web

Cosa è un processo di sviluppo?

» Un processo definisce chi fa che cosa, quando e come per raggiungere un determinato obiettivo

» Nell’ingegneria del SW l’obiettivo è di produrre prodotti SW o di migliorarne di esistenti


Rational Unified Process (RUP)

» RUP è un processo effettivo per lo sviluppo di SW

» RUP è un prodotto sul processo, sviluppato e aggiornato dalla Rational

» RUP è un framework di processo, cioè è adattato ed


» RUP è un framework di processo, cioè è adattato ed esteso a seconda delle necessità

» RUP abbraccia le 6 best practice e utilizza tools per implementarle

RUP

» RUP:

> Use case driven

> Architecture-centric

> Iterative and incremental


Use Cases

SA

DriveGuides

RUP guidato dai casi d’uso

» Use case catturano i requisiti funzionali del sistema

» Gli use case guidano tutte le fasi del processo> Use case sono l’anello di congiunzione tra i requisiti e

le attività di design> Use case costituiscono la base per identificare le


> Use case costituiscono la base per identificare le procedure di test

Struttura del processo

Inception Elaboration Construction TransitionCore Workflows

An iteration in the

elaboration phase

Requirements

Analysis


P re lim ina ry

Ite ra tion(s)

ite r.

# 1

ite r.

# 2

ite r.

# n

ite r.

#n+ 1

ite r.

# n+2

iter.

# m

ite r.

#m +1

I te ra tio n s

Design

Implementation

Test

Struttura dinamica del processo: in breve

»Ideazione (Inception):

> Definisce lo scopo del progetto

Elaborazione (Elaboration):

Ideazione Elaborazione Costruzione Transizione


»Elaborazione (Elaboration): > Pianificazione di progetto, specifica delle

features e base architetturale

»Construzione (Construction): > Costruisce il prodotto

»Transizione (Transition): > trasferisce il prodotto agli utenti

Requisiti

» Requisiti funzionali di applicazioni Web sono catturati e modellati tramite Use Cases;

» Come nello sviluppo tradizionale, Use Case D. hanno l’obiettivo di presentare graficamente ed esplicitare tramite templates, gli obiettivi funzionali da raggiungere


» Use Case diagram sono usati per guidare i seguenti passi nel processo di sviluppo Web

> Web actors identification- WebAdministrator, Browser, OnlineCustomer, Registered (unregistered)

User

> Web-related Use cases

» Uso di Sequence Diagram> Ad altissimo livello

» L’attivita’ di analisi consente di trasformare i requisiti del sistema in un progetto

» Gli obietti dell’analisi degli use case sono:> Identificare le classi e gli oggetti che esibiscono il comportamento

descritto negli use case.

Identificare le responsabilità, gli attributi e le associazioni delle

Analysis Model (a la RUP)


> Identificare le responsabilità, gli attributi e le associazioni delle classi.

> Rilevare l’utilizzo dei meccanismi architetturali

» A questo livello si identificano delle “analysis class”, che sono delle classi concettuali, astratte, indipendenti dalla specifica tecnologia implementativa

Look and Feel


Look and Feel

Possiede


Lavora

Look and Feel


» Le analysis class possono essere stereotipate in tre tipi: boundary, entity e controller

> Boundary object:- rappresentano l’interfaccia tra l’attore ed il sistema. - Istanze di questi oggetti sono tipicamente maschere di input o

controlli all’interfaccia utente. - Nelle applicazioni Web, i boundary object possono anche

rappresentare delle intere pagine Web.> Entity object:

- esempi di entity object, le cui istanze possono apparire in più invocazioni di use case, sono ordini, clienti, prodotti, ecc.


- Nelle applicazioni Web, rappresentano i dati> Controller object:

- rappresentano processi. - Questi oggetti rappresentano delle attività di sistema alle quali

può essere attribuito un nome. - I controller object tipicamente dirigono le attività degli entity e

dei boundary object.

Classi Boundary

» Diversi tipi> User interface:

- intermediano la comunicazione con l’interfaccia umana del sistema

- Bisogna concentrarsi su quale informazione viene presentata all’utente e non sui dettagli della UI

> System interface: intermediano la comunicazione con


> System interface: intermediano la comunicazione con altri sistemi

> Device interface: forniscono l’interfaccia verso dispositivi che catturano eventi esterni

Nelle classi System e device è necessario concentrarsi su quali protocolli utilizzare e non come verranno implementati

Classi Boundary: Esempio

Studente Registrazione per Corsi Sistema Catalogo Corsi


FormRegistrazioneCorsi

(from Design Mod...

Sistema CatalogoCorsi

Classi Entity

» Entity object rappresentano i concetti chiave del sistema oggetto di sviluppo

» Memorizzano e gestiscono le informazioni del sistema, cioé mostrano la struttura logica dei dati

» Generalmente non sono specifici di uno use-case


» Generalmente non sono specifici di uno use-case ma possono far parte di tanti use-case

» Vengono dedotti dal glossario, flusso degli eventi degli use-case e dalle astrazioni chiave (identificate nell’analisi dell’architettura)

Classi Entity

» Metodo per determinare le classi entity> Utilizzare il flusso degli eventi e le astrazioni chiave come input> Dal flusso degli eventi sottolineare i nomi> Rimuovere i candidati ridondanti e vaghi> Rimuovere gli attori (non sono entità, sono esterni al sistema


> Rimuovere gli attori (non sono entità, sono esterni al sistema quindi non si modellano)

> Rimuovere i costrutti di implementazione

Attributi ed operazioni vengono determinati successivamente

Classi Entity

» Esempio> Use-case: Registrazione per Corsi

S tu d e n te(fro m D e s ig n M o d e l)


> N.B.: Anche se studente è un attore, il sistema mantiene informazioni sullo studente.

O ffe r ta C o rs i(fro m D e s ig n M o d e l)

P ia n o s tu d i(fro m D e s ig n M o d e l)

Classi Control» Coordinano il comportamento nel sistema» Definiscono la logica di controllo dello use-case, cioé

implementano il flusso degli eventi» Generalmente uno use-case contiene una control class» Può non essere presente qualora un particolare use-case

manipola soltanto informazioniUse-case complessi possono avere più classi di controllo


» Use-case complessi possono avere più classi di controllo» Disaccoppiano gli oggetti entity e boundary rendendo

quindi il sistema più tollerante ai cambiamenti e permette il riuso di oggetti entity tra i vari use-case

Classi Control

S tu d e n te R e g is tra z io n e p e r C o rs i S ist e m a C a ta lo g o C o rs i


C o n tro lle rR e gis tra z ion e

Analysis

» Elementi dell’Analysis model:> Boundary: interfaccia grafica> Entity: dati> Control: attivita’

» Rules:


» Rules:R1: Actors interagiscono solo con boundary objR2: Entity interagiscono solo con controller objR3: Controller interagiscono con tutti

» R1: Actors interagiscono solo con boundary obj

» R2: Entity interagiscono solo con controller obj

B


» R3: Controller interagiscono con tutti

E C

C

B

CE

Dai Requisiti all’Analysis

» Per passare dai Requisiti all’Analysis, si seguono i seguenti passi:

> Per ciascun Use Case, si identificano le Analysisclass che le possono realizzare


class che le possono realizzare- Per ciascuna classe, si identifica il tipo (boundary, control,

entity)

» In tale fase si realizzano Analysis ClassDiagram e Analyisis Sequence Diagram

B CE

R1

R2

Utente

Generico

Home

Uffici

Giudiziari

Risultato

Ricerca

Persone

Gestione

Anagrafica

Personale

Persona

Ufficio

Qualifica

Incarico

Ufficio

Qualifica

Ricerca Anagrafica Personale

Parametr

i Ricerca

Insuff.

Naviga

Visualizza

Ricerca Anagr. Pers.

Ricerca Anagr. Pers.

Form di

Ricerca

Personale

Ricerca

Persone

Get Entry

Build


R2

Visualizza

Inserisce Param. Ricerca

Submit

Ricerca Persone

[Param. Insufficienti]Redirect

[Param. OK]Get Entry

Build

Visualizza

Controlla Parametri

Visualizza

Altri diagrammi nella fase Analysis

» Altri diagrammi:> Packages> Sequence diagram> Activity diagram


Lessons Learned

» Analysis model classes can be elicited starting from:> Single Use Cases

- Merge is required

> Use Case Diagrams


» Traceability among Use Cases and Analysis classes is a must

» The boundary-control-entity pattern provides a very usefull schema for modeling modern Web applications (E.g., MVC patterns)

Esempio da fare in classe» Riprendiamo il sistema Trip4You


Design

» Input:> Architettura Web> Analysis model (Class + Sequence)

» Goals:> Elaborare le classi


> Elaborare le classi> Partizionare gli oggetti in tiers (Architettura)> Separare e definire interfacce

- Web page: client e server pages

» Component diagram

Look and Feel


Design = Analysis+Architettura+Pagine

» Questa e’ la fase in cui l’approccio di Conallen piu’ si specializza per il Web, legando la fase di Analysis con quella architetturale> l’analysis model viene raffinato, in modo tale che

possa essere implementato con le componenti


possa essere implementato con le componenti dell’architettura

> Le classi diventano meglio definite, con la specifica completa delle proprietà (nomi e tipi) e delle operazioni (signature complete).

» Si definiscono le Web pages

Design

» Passi:> La definizione delle interfacce utente, o pagine Web

> La suddivisione degli oggetti in tier, come client tier, server tier e così via.

» Per poter partizionare gli oggetti nei vari tier,


» Per poter partizionare gli oggetti nei vari tier, bisogna sapere quali tier si hanno a disposizione. Questo dipende dalle specifiche dell’architettura

» Tutti quanti i pattern architetturali delle applicazioni Web prevedono l’uso delle pagine Web

Pagine Web

» Il primo problema di modellazione che si presenta e’ come modellare pagine Web:

> pagina Web puo’ contenere degli script che devono essere eseguiti sul server.

> Per complicare ulteriormente le faccende, la stessa pagina


> Per complicare ulteriormente le faccende, la stessa pagina può contenere una serie di script che vengono eseguiti sul client.

» I modelli messi a disposizione da UML, da soli, non sono sufficienti ad esprimere tutte le sottigliezze che caratterizzano una pagina Web contenente degli script, per consentirne la rappresentazione in un class diagram.

Pagina Client e Pagina Server

» Nota: Il comportamento di una pagina Web sul Server e’ differente dal comportamento della stessa sul Client:> Sul Server la pagina deve accedere le risorse del

Server (dbase, file system, …) > Sul Client, la pagina deve essere invece collegata


> Sul Client, la pagina deve essere invece collegataal browser, alle Applet, ActiveX controls, ...

» Modelliamo gli aspetti Server-side e Client-sidecome elementi diversi, da linkare

Idea

» Creare uno stereotipo che ci definisce quali siano i campi caratterizzanti una pagina Web, le sue proprieta’, i suoi attribuiti, i suoi modi di interagire con altre pagine Web


<<Web Page>>

MainPage

attrib1

attrib2

property1()

property2()

» A seconda dell’architettura scelta, una Web page puo’ avere delle diverse proprieta’

Cominciamo….

» Vediamo ora come Conallen estende UML classico per modellare i tre tipi di architettura:> Thin Web Client;

> Thick Web Client;

> Web Delivery


> Web Delivery

» Ne esistono altri, ma questi sono quelli

analizzati in [Con_Book]

» Per ora, ci focalizziamo sul Thin Web Client

Thin Web Client

» Questo pattern viene usato per clients nei quali si

possa garantire solo una bassa configurazione

» Il client richiede solo un browser, abilitato ad usare

forms


forms

» Adatto per clients con bassa capacita’ di

computazione

» Adatto per applicazioni B-2-C

Componenti (1/2)» Client Browser:

> lavora come una user interface

> l’utente richiede pagine html dal server

> l’unico servizio a disposizione e’ quello relativo all’accettaz. di cookies

» Web Server:

> e’ il punto di contatto tra pagine Web e Client

> puo’ contenere degli script (CGI)

> fornisce i risultati in un formato HTML visibile sui browsers


> fornisce i risultati in un formato HTML visibile sui browsers

» HTTP connection:

> e’ il protocollo di comunicazione usato

> SSL puo’ essere usato per incrementare la sicurezza del sistema

» HTML page:

> non ha bisogno di alcuna computazione da parte del Server

> viene spedita dal Server al Client, cosi’ com’e’

Componenti (2/2)» Server Page:

> Sono pagine web prodotte dal Web Server, tramite l’utilizzo

di risorse Server-side

> hanno solitamente accesso a Dbase, business logic

components, legacy systems

> Tecnologia ASP, JSP, ...


» Application server:

> puo’ risiedere in una macchina differente dal Server

> si occupa della business logic

> e’ una applicazione indipendente dal Server Web, che ha il

compito di computare risultati utilizzando le risorse a

disposizione

Figura Architettura Thin Web Client


Dinamica di un Thin Client

1. Il client attiva il processo, richiedendo una pagina tramite HTTP

2. se la richiesta consiste semplicemente in un Html file o un Web server filesystem file, il Web serversemplicemente spedisce la pagina

3. se la pagina contiene uno script, il Server Web invoca


3. se la pagina contiene uno script, il Server Web invoca l’application server, il quale interpreta lo script e interagisce con risorse server side per produrre i risultati attesi

4. le informazioni vengono formattate in modo che siano comprensibili dal browser, ed inviate al client sotto forma di Web page.

Alcune considerazioni» Questo tipo di architettura e’ adatta per

applicazioni che rispondano in un certo time-limit (pochi secondi)

» non e’ adatta per servizi con tempi di esecuzione elevati… al limite si usa un


esecuzione elevati… al limite si usa un polling periodico

» permette una limitata abilita’ nello sviluppare interfacce utenti, visto che l’informazione deve essere presentata usando le capacita’ del browser

String-Util

GetEntries

<<build>>

25

+LetterEntry

25<<link>>

{BeginWith}

<<redirect>>

{ErrDescription}

GlossaryHome

26

+LetterEntry

26

<<link>>

{BeginWith}

<<include>>

Class Diagram – Design level


globa.asa

EntryListing

SearchResults

spErrorMsg

<<build>>{ErrDescription}

ProcessSearch

<<build>>

<<redire...

{ErrDescription}SearchForm

<<submit>>

Sequence Diagram – Design level


Architettura Thin Client con Conallen

» In questa architettura, dobbiamo distinguere tra due diverse tipologie di pagine Web:

> Client page, che possono interagire con dei form, per la raccolta di dati di input da inviare al server


per la raccolta di dati di input da inviare al server

> Server page, che provvedono ad elaborare i dati(interagendo con altre risorse server-side) e costruiscono dinamicamente delle pagine con i risultati delle elaborazioni,

- pagine che verranno inviate al client per la visualizzazione.

Client e Server page

» Dobbiamo iniziare con il fare una distinzione tra “Client page” e “Server page”


<<Web Page>>

MainPage

attrib1

attrib2

operation1()

operation2()

<<Client Page>>

MainPage

<<Server Page>>

MainPage

Da Analysis model a Design model

» Per passare da elementi dell’Analysis Model a quelli del Design model ci si puo’ aiutare seguendo tali direttive:

> trasformare i boundary object in delle client page


> trasformare i boundary object in delle client page

> trasformare i controller object in delle server page

> gli entity object invece, verranno probabilmente

mappati in una serie di server component

Relazioni tra Client e Server page

» Relazione fondamentale: <<build>>> La pagina Server, dopo avere elaborato i

dati,esegue un build della pagina Client

> E’ una relazione unidirezionale


> E’ una relazione unidirezionale

Relazione di <<redirect>>

» Relazione di <<redirect>>> consiste nella possibilità di redirezionare la gestione

di determinate richieste da una server page ad un’altra


Utente

Pagina di

Ricerca

Anagrafica

Ricerca

Anagrafica

Naviga

Visualizza

Parametri

Ricerca

Insufficienti

Persona

Ufficio

Qualifica

Risultati

Ricerca

Inserisce Parametri


Ricerca Anagr

Visualizza

Cerca

[Param. Insufficienti]

Build

[Param. OK]

get Entry

Build

Visualizza


Form

» Un form è una raccolta di elementi di input

» Un form può esistere soltanto nel contesto di una client page

» La relazione esistente tra un form e la client page che lo contiene è la relazione di


page che lo contiene è la relazione di aggregazione> Una client page puo’ contenere piu’ form

» La relazione esistente tra un form e la pagina Web che lo elabora, viene espressa nel modello attraverso un’associazione con lo stereotype «submits».


Link

» Un link in un’applicazione Web rappresenta un percorso di navigazione attraverso il sistema

» Questa associazione ha origine sempre da una client page e punta ad un’altra client page oppure ad una server page


oppure ad una server page


» I link possono anche contenere dei parametri (<<parameter>>), destinati ad essere utilizzati da parte della server page:> Nell’esempio, il parametro identifica la persona di cui si

vogliono i dettagli

Frame

» I frame sono implementati in HTML definendo un “frameset”

> I frameset sono rappresentati nel modello attraverso una client page con lo stereotype «frameset»

» Il meccanismo utilizzato per referenziare frame in un frameset e’ il “target”


frameset e’ il “target”> I target sono rappresentati tramite «target»

- Un target non ha proprietà o attributi, è semplicemente un contenitore per una client page, referenziabile da parte di altre client page

» In conclusione, un frameset può essere considerato come un’aggregazione di client page e di target


Architettura Thick Web Client con Conallen

» In questo pattern architetturale anche il Client puo’ eseguire delle computazioni

» In generale, si tratta di computazioni su risorse residenti esclusivamente al lato client


residenti esclusivamente al lato client> E.g., validazione sui dati in input

» Bisogna quindi modellare:> le componenti dell’applicazione lato client

> le relazioni tra queste componenti e le altre risorse client-side

» client-side scripting e client object

Thick Web Client

» Si aggiungono client-side script e oggetti, come

controlli ActiveX e applets.

» E’ quindi piu’ di una semplice interfaccia utente

» Richiede la possibilita’ di utilizzare e configurare un

client avanzato


client avanzato

» permette delle capacita’ di presentazione piu’

elevate

» Un esempio: validazione di dati immessi in input

> invece di mandare il tutto al Server

» Il browser si adatta alle capacita’ dell’utente

Componenti

» Thick Web Client = Thin Web Client + …

» Client script:> JavaScript o VBScript possono essere embedded nella pagina Html. Il browser ha la capacita’ di interpretare lo script

» Documenti XML

» Controlli ActiveX:


» Controlli ActiveX:> tali componenti, come i Com components, vengono downlodati dal Server sul Client ed eseguiti dal Browser. Hanno accesso alle risorse del client

» Java applet:> componenti compilate downlodate dal Server con accesso ristretto a risorse del Client. Solitamente usate per aumentare la capacita’ di presentazione del Client e per computazioni lato client

Dinamica e Considerazioni

Oltre la dinamica del thin client…

» il Thick client puo’ eseguire business logic senza richiedere l’intervento del Server

» Non tutti i browser supportano JavaScript o VBScript


» I controlli ActiveX possono essere usati solo da browser Microsoft

» Differenti browsers possono produrre differenti risultati

Disegno architetturale del Thick Web

Client


Client-Side Scripting

» Con client-side scripting s’intende il codice (generalmente JavaScript o VBScript) che consente di arricchire le funzionalità offerte dalla pagina


» Stereotype utilizzato:> «client-side script» (o equivalentemente

«JavaScript», o «VBScript»), associata alla client page contenente lo script.

Nota: Nei Sequence diagram, l’esecuzione di un client-side script da parte di una client page viene rappresentato attraverso l’invocazione diun’operazione su client stesso

» Thin Web client:> Tutta la computazione

viene eseguita sul Server


» Thick Web client:> I controlli possono

essere fatti sul client- Immissione parametro

- Controlli sintattici


Client Object

» Generalmente ActiveX o applet Java

» Stereotype «ActiveX control», o «Java applet».

» La relazione esistente tra un client object e la


» La relazione esistente tra un client object e la client page che lo contiene è la relazione di aggregazione

Da Fare in Classe» Uso di Magic Draw per modellare Analysis e

Design class models di Conallen


Implementation

» Nella fase di implementazione

> Il design deve essere mappato sul codice e componenti- Tutti i diagrammi finora realizzati ci devono aiutare nella fase di

implementazione


> Gestione delle modifiche tramite reverse engineering- Bisogna tenere allineati i modelli ed il codice

Mapping del design sulle componenti

» Per implementare Server Pages possono essere adottate due strategie:

> Compiled Page- Una compiled page ha generalmente il ruolo di implementare piu’

server page


server page

- 1 componente � piu’ server pages

> Scripted Pages- Una componente realizza una server page

- 1 componente � 1 server page

Coding

» Per iniziare la fase di mapping design-codice, si:> Prende il modello del design

> Prende il modello delle componenti

> Identificano le componenti reali che implementeranno le pagine identificate


Suddivisione in Package

» Web Pages tenute separate da Server Components

» Web Page package:> Astrazione di una directory sul Web Server

> Le informazioni sulla directory (nome e locazione)


> Le informazioni sulla directory (nome e locazione) sono memorizzati nei tagged value del package

Server

Components

Web Pages

Web pages packageBrowsing

String-Util

GetEntries

25

+LetterEntry

25 <<link>>

{BeginWith}

GlossaryHome

26

+LetterEntry

26

<<link>>

{BeginWith}

<<include>>


globa.asa

EntryListing

SearchResults

spErrorMsg

<<build>>

<<redirect>>

{ErrDescription}

ProcessSearch

<<build>>

<<redire...

{ErrDescription}

GlossaryHome

SearchForm<<submit>>

Browsing

String-Util

GetEntries

SearchChar : Stringnl : String

Main()GetEntries()WriteEntry(id : long, word : string, description : string, bgColor : String)...WriteLetterIndex()

<<build>>

25

+LetterEntry

25

<<link>>

{BeginWith}

<<redirect>>

{ErrDescription}

GlossaryHome

26

+LetterEntry

26

<<link>>

{BeginWith}

<<include>>


globa.asa

EntryListing

SearchResults

spErrorMsg

ProcessSearch

<<build>>

<<redire...

{ErrDescription}SearchForm

<<submit>>

Code

» Apri file 16_GetEntries.asp


User eXperience Model


User eXperience Model

User eXperience (UX) model

» Rappresentano delle estensioni, apportate da Conallen nella seconda versione del libro

» Catturano il “look and feel”:> possibili scenari che l’utente attraverserà durante

la navigazione > diagrammare le possibili strade che sarà possibile


> diagrammare le possibili strade che sarà possibile imboccare durante la visita del sito

» Lo UX model e’ considerata una vista a se stante, realizzata dagli Information Architects

Tre concetti nuovi:

» Screens and Content

» Storyboard scenarios

» Navigational paths attraverso gli screens


» Screen:

> uno screen è precisamente ciò che è presentato all’utente- La combinazione dei contenuti statici e dinamici produce lo screen

» Storyboard scenario:

> Ordine di visita degli screen

> Lo scopo finale degli “Storyboard scenarios” è di esprimere un uso tipico del sistema attraverso gli occhi dell’utente


uso tipico del sistema attraverso gli occhi dell’utente

» Navigational Path map:

> struttura degli screens di un’applicazione insieme alle possibili “strade” che possono essere percorse

> mappa stradale degli screens dell’applicazione

Screen

» Uno screen contiene gli elementi tipici di una UI, come menus, controlli, e contenuti (statici e dinamici) .


» Screen ≠ Web page> Le Web page producono gli screen

> Screen = cio’ che viene presentato all’utente, non come e’ stato generato

» Gli screen devono riportare I contenuti dinamici

Esempi

» Screen:- É molto importante realizzare un mapping

fra gli screens e gli elementi utilizzati in fase

di analisi per mantenere la tracciabilità


Esempi


Esempi

» Storyboard

scenario:> modellato


in UML tramite

un collaboration

diagram

Storyboard Scenario

» L’obiettivo di uno storyboard scenario e’ quello di esprimere un uso tipico del sistema, come visto dagliocchi di un utente finale.

» Gli Storyboard vengono utilizzati per modellare use case scenarios, oppure mini-stories


» Data una story, uno screen puo’ essere visitato piu’ volte, e con dati dinamici differenti

» Partendo da diagrammi fatti a mano, si puo’ passare a mockups o HTML files/templates, che sono realizzati daiWeb servers e contengono contenuto statico e dinamico

Esempi

» Navigation path map:> In UML è possibile esprimerlo mediante un class

diagram che mostra le “classi” (=screen) ed i principali percorsi fra di esse

> Se uno screen risulta collegato con un altro significa che è possibile accedere al secondo


che è possibile accedere al secondo

Navigation path map

» Esprime tutti I path accettabili

» Il comportamento dovuto al pulsante “back” del browser non viene modellato

» Si modellano solo i percorsi normali, non tutti I


» Si modellano solo i percorsi normali, non tutti I possibili

» Aiutano a modellare la “site map”

Riassumendo

» L’approccio di Conallen focalizza su:> Progettazione Boundary/Control/Entity

> Progettazione di pagine (client e server)

> Progettazione Architetturale

> Progettazione della User eXperience


Progettazione della User eXperience

Tool Support and Bibliography

» IBM Rational tools and Magic Draw contain the Conallen stereotypes

» Visio Stencils

» …

» Building Web Applications with UML – 2nd edition. The Addison-Wesley Object Technology Series. Jim Conallen


Addison-Wesley Object Technology Series. Jim Conallen> [Con_ACM99] Modeling Web Application Architectures with UML

Jim conallen, Rational Software, June 1999In the October 1999 (volume 42, number 10) issue of Communications of the ACM. On line at http://www.uml.com.cn/papers/webapps.htm

> [ConExt] UML Extension for Web Applications 0.91Jim conallen.

> [UML2000] Modeling Web Applications in the UML UML2000 Workshop.

Workshop home page: http://www.txt.com/webuml/

Riassumendo Riassumendo


0

Riassumendo Riassumendo

Conallen

» Basics:> Basato sul RUP> Guidato fortemente dall’architettura dei sistemi

Web

» Fasi:


1

> Requisiti, Analisi, Design, Implementazione

» Concetti base:> Pagina Web, che funge da legame tra Architettura e

gli Analysis model, tramite partizionamento di oggetti in tiers

> Stereotype

» Idea: Utilizzare UML stereotipato per

rappresentare gli elementi di un Sito

Web,cioe’…

» OggettiPagine Form


2

» Relazioni

Frame COM object

Link Frame

Content

Intuizione• Un Sito e’ composto da pagine, che

possono essere di tipo Client e Server.

• Una pagina puo’ contenere delle Form e

puo’ far parte di un Frame Set.

• Piu’ pagine possono essere linkate tra di

loro


3

loro

PagePage

PageLink

Frame Frame

ServerPage:

Metamodel Class:

Descrizione

Icona

Class nel Class Diagram

Rappresenta una pagina Web con degli

Script. Tali script possono interagire con

le risorse disponibli sul Server


4

Icona

Attributi

Operazioni

Vincoli

Sono le variabili

funzioni degli script

Le Server Page possono solo essere

collegate ad oggetti nel Server

ClientPage:

Metamodel Class:

Descrizione


Rappresenta una pagina formattata in

Html. E’ un mix di dati, grafica e

link.Possono essere linkate a ClientPage e

ServerPage


5

Icona

Attributi

Operazioni

Vincoli

Sono le variabili nei tag

Tag degli script

Nessuno

» Nota: Il comportamento di una pagina Web sul Server e’ differente dal comportamento della stessa sul Client:

> Sul Server la pagina deve accedere le risorse delServer (dbase, file system, …)

> Sul Client, la pagina deve essere invece collegataal browser, alle Applet, ActiveX controls, ...


6

» Modelliamo gli aspetti Server-side con una classe e

quelli Client-side con un’altra e leghiamo con il

<<build>> le due pagine (Separation of Concerns)

Form:

Metamodel Class:

Descrizione


Una form e’ una collezione di campi di

Input che fanno parte di una ClientPage


7

Icona

Attributi

Operazioni

Vincoli

Campi di Input

Nessuna (non possono essere incapsulate

in una form)

Nessuno

Frame Set:

Metamodel Class:

Descrizione


Un Frame set e’ un contenitore di piu’

pagine Web. Un Frame Set puo’ essere

una Page o un altro Frame Set


8

Icona

Attributi

Operazioni

Vincoli

Quelli di una Page

Quelli di una Page

Nessuno

Target:

Metamodel Class:

Descrizione


E’ un particolare Frame o una nuova

finestra del Browser linkata da altre

pagine client


9

Icona

Attributi

Operazioni

----

----


0


1

JavaScript:

Metamodel Class:

Descrizione


Su browser che abilitano i JavaScript e’

possibile utilizzare tali oggetti. Possono

esistere solo in ClientPage


2

Icona

Link:

Metamodel Class:

Descrizione

Association nel Class Diagram

Un Link e’ un puntatore di una Client

Page verso una Client o una Server Page.

I parametri che possono essere inviati

vengono rappresentati tramite Tagged

Values


3

Icona

Values

<< link >>

Build:

Metamodel Class:

Descrizione

Association nel Class Diagram

Una Server Page <<build>> una Client

Page nel senso che, ad ogni Client page

deve essere acciata la relativa Server Page.

Esempio: Server page = page dinamica,

Client page = istanza della pagina


4

Icona

Client page = istanza della pagina

dinamica

<< build >>


5


6

Page:

Metamodel Class:

Descrizione

Component nel Component Diagram

Tramite questa vista descriviamo tutti i

componenti (pagine Web) da sviluppare.

Un component Diagram puo’ essere visto

come una mappa del sito. Le componenti

collegate in un Component Diagram


7

Icona

collegate in un Component Diagram

verranno rappresentate come Classi

linkate in un Class Diagram


8


9

Tool support


0

Tool support

Visio Stencils


1

Rational Rose

» IBM Rational Rose include gli stereotipi di Conallen

» Visual UML:> http://www.visualuml.com/products.htm


2

> http://www.visualuml.com/products.htm

Esempio


3

Esempio

Esempio

» Prendendo ad esempio un sistema che permetta di eseguire acquisti on-line, tramite l’utilizzo di un carrello

» Vedremo come tale sistema puo’ essere


4

» Vedremo come tale sistema puo’ essere modellato utilizzando le tre diverse architetture proposte precedentemente

» Cercheremo di capire, quindi, quanto l’architetture influenza il design


5

Richieste del committente» Un utente, collegandosi al sito, deve poter effettuare degli acquisti

on-line. » Gli articoli possono essere visti direttamente sul sito, con una lista

delle caratteristiche e del prezzo. Tutti gli utenti possono eseguire tale visita

» Gli articoli possono essere acquistati solo da utenti registrati

» Dopo la selezione di un prodotto, il carrello dovra’ riportare la lista aggiornata dei prodotti da acquistare


6

aggiornata dei prodotti da acquistare» Naturalmente, ci sono dei requisiti di sicurezza il sistema deve

rispettare» Alla fine dell’operazione di acquisto, si esegue un logon

» La sessione deve rimaner valida finche’ l’utente non esegue logon e comunque per non piu’ di xxx minuti

» ...


7

Utilizzo di un Glossario

» Ha il compito di: > identificare:

- Pagine Web

- Dati e Dbase

- Applicativi


8

» Analizzare:> l’architettura del sistema, al fine di distribuire

componenti ed assegnare le giuste tecnologie di sviluppo

Oggetti: glossario» Gli articoli possono essere visti direttamente sul sito, con una

lista delle caratteristiche e del prezzo. Tutti gli utenti possono eseguire tale visita



9


» Dopo la selezione di un prodotto, il carrello dovra’ riportare la lista aggiornata dei prodotti da acquistare

Elementi del Modello

» Pagine lato Client:> Pagina Iniziale con possibilita’ di login

> Pagina di Login (input)

> Pagina di Errore nella Login (statica o dinamica)

> Pagina con link ai prodotti (link statico o dinamico)


0

Pagina con link ai prodotti (link statico o dinamico)

> Pagina di ricerca sui prodotti (risultato dinamico)

> Pagina di Logout

Thin Web Client


1

Ora… Conallen

» Le informazioni catturate nel passo precedente aiutano la definizione architetturale,

» aiutano la formalizzazione di un Class Diagram» permettono di avere una visione globale sugli

oggetti da modellari, suddivisi in tre categorie, rappresentanti:


2

rappresentanti:> contenuto> presentazione> business logic

Class D


3


4


5

Thick Web Client


6


7

Date post:	09-May-2015
Category:	Documents
Upload:	henry-muccini
View:	1,965 times
Download:	12 times

Modellazione UML per il WEB: Approccio di Conallen

Documents