Modellazione UML per il WEB: Approccio di Conallen

UML & WEb
- Approccio WAE: Conallen -

Master in Web
Technology
Corso di: Modellazione UML per il Web
Docente: Henry Muccini
VIII Edizione 2012/2013
Dipartimento di Ingegneria e Scienze dell’Informazione e Matematica
Università 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

Henry Muccini

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

Conallen
> Approccio di Conallen per la modellazione di
applicazioni Web tramite UML
- Uso dei Meccanismi di estensione di UML
> Tool support
> Esempio

3

Approccio di Conallen per il
Web

4

Conallen
» Considera tutto il processo:
> Requisiti
> Analisi
> Design
> Implementazione

» Implementa il processo di sviluppo RUP per
applicazioni Web

5

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

6

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
esteso a seconda delle necessità

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

7

RUP
» RUP:
> Use case driven
> Architecture-centric
> Iterative and incremental

Use Cases

Guides Drive
SA

8

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
procedure di test

9

Struttura del processo
Core Workflows Inception Elaboration Construction Transition

Requirements

An iteration in the
elaboration phase
Analysis

Design

Implementation

Test

P re lim ina ry ite r. ite r. ite r. ite r. ite r. ite r. ite r.
Ite ra tion (s) #1 #2 #n # n+ 1 # n+2 #m #m +1

I te ra tio n s
10

Struttura dinamica del processo: in
breve
Ideazione Elaborazione Costruzione Transizione

»Ideazione (Inception):
> Definisce lo scopo del progetto
»Elaborazione (Elaboration):
Elaborazione
> Pianificazione di progetto, specifica delle
features e base architetturale
»Construzione (Construction):
> Costruisce il prodotto
»Transizione (Transition):
> trasferisce il prodotto agli utenti
11

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
12

Analysis Model (a la RUP)
» 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
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

13

Look and Feel

14

Look and Feel

Po
ss
i ed
e
ra
vo
La

15

Look and Feel

16

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

17

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

18

Classi Boundary: Esempio

Studente Registrazione per Corsi Sistema Catalogo
Corsi

FormRegistrazioneCorsi Sistema CatalogoCorsi
(from Design Mod...

19

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
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)

20

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
quindi non si modellano)
> Rimuovere i costrutti di implementazione

Attributi ed operazioni vengono determinati
successivamente

21

Classi Entity
» Esempio
> Use-case: Registrazione per Corsi

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

P ia n o s t u d i
O ffe rta C o rs i

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

22

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 informazioni
» 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

23

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 i st e m a
C a ta lo g o C o rs i

C o n tro lle rR e g i s tra z io n e

24

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

» Rules:
R1: Actors interagiscono solo con boundary obj
R2: Entity interagiscono solo con controller obj
R3: Controller interagiscono con tutti

25

» R1: Actors interagiscono solo con boundary obj

B

» R2: Entity interagiscono solo con controller obj

E C

» R3: Controller interagiscono con tutti
B
C

E C
26

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

> Per ciascun Use Case, si identificano le Analysis
class che le possono realizzare
- Per ciascuna classe, si identifica il tipo (boundary, control,
entity)

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

27

Ricerca Anagrafica Personale B E C

R1 Home
Gestione Ufficio
Form di
Ricerca Parametr Persona Risultato
Uffici Ricerca i Ricerca Ricerca
Utente Anagrafica Qualifica Persone Ufficio
Giudiziari Personale Insuff. Persone
Generico Personale Qualifica
Incarico
Naviga

Visualizza

Ricerca Anagr. Pers.
Ricerca Anagr. Pers.
R2
Get Entry
Build

Visualizza

Inserisce Param. Ricerca

Submit
Ricerca Persone

Controlla Parametri

[Param. Insufficienti]
Redirect
R2
Visualizza [Param. OK]
Get Entry
Build
Visualizza

28

Altri diagrammi nella fase Analysis
» Altri diagrammi:
> Packages
> Sequence diagram
> Activity diagram

29

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)
30

Esempio da fare in classe
» Riprendiamo il sistema Trip4You

31

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

» Goals:
> Elaborare le classi
> Partizionare gli oggetti in tiers (Architettura)
> Separare e definire interfacce
- Web page: client e server pages

» Component diagram

33

Look and Feel

34

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

35

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,
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

36

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

37

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
al browser, alle Applet, ActiveX controls, ...

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

38

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
» A seconda
attrib1 dell’architettura
attrib2
scelta, una Web
property1() page puo’ avere
property2()
delle diverse
proprieta’
39

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

» Ne esistono altri, ma questi sono quelli
analizzati in [Con_Book]
» Per ora, ci focalizziamo sul Thin Web Client

40

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

» Adatto per clients con bassa capacita’ di
computazione

» Adatto per applicazioni B-2-C

41

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
» 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’

42

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

43

Figura Architettura Thin Web Client

44

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 server
semplicemente spedisce la pagina
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.

45

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
polling periodico
» permette una limitata abilita’ nello
sviluppare interfacce utenti, visto che
l’informazione deve essere presentata
usando le capacita’ del browser

46

Class Diagram – Design level
<<include>>

String-Util
+LetterEntry
<<link>> +LetterEntry
25 <<link>>
{BeginWith} 26

GetEntries {BeginWith}
GlossaryHome
<<redirect>>
{ErrDescription} <<build>>

spErrorMsg EntryListing
<<redire...
<<submit>> {ErrDescription}
SearchForm
<<build>>
globa.asa

SearchResults

ProcessSearch

47

Sequence Diagram – Design level

48

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

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

49

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

<<Web Page>> <<Client Page>>
MainPage MainPage
attrib1
attrib2

operation1() <<Server Page>>
operation2()
MainPage

50

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 controller object in delle server page
> gli entity object invece, verranno probabilmente
mappati in una serie di server component

51

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

52

Relazione di <<redirect>>
» Relazione di <<redirect>>
> consiste nella possibilità di redirezionare la gestione
di determinate richieste da una server page ad
un’altra

53

Pagina di Parametri Persona Risultati
Ricerca Ricerca Ricerca Ufficio Ricerca
Utente Anagrafica Anagrafica Insufficienti Qualifica

Naviga

Visualizza

Inserisce Parametri

Cerca

Ricerca Anagr
[Param. Insufficienti]
Build
Visualizza
[Param. OK]
get Entry

Build
Visualizza

54

55

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
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».
56

57

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

58

» 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
59

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

60

61

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
> 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
62

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
» 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

63

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:
> 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

64

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

65

Disegno architetturale del Thick Web
Client

66

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 di
un’operazione su client stesso
67

» Thin Web client:
> Tutta la computazione
viene eseguita sul
Server

» Thick Web client:
> I controlli possono
essere fatti sul client
- Immissione parametro
- Controlli sintattici

68

69

Client Object
» Generalmente ActiveX o applet Java

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

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

70

Da Fare in Classe
» Uso di Magic Draw per modellare Analysis e
Design class models di Conallen

77

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

78

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
- 1 componente piu’ server pages
> Scripted Pages
- Una componente realizza una server page
- 1 componente 1 server page

79

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

80

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)
sono memorizzati nei tagged value del package

Web Pages Server
Components

81

Web pages package
Browsing

<<include>>

String-Util
+LetterEntry
<<link>> +LetterEntry
25 <<link>>
{BeginWith} 26

GetEntries {BeginWith}
GlossaryHome
<<redirect>>
{ErrDescription} <<build>>

spErrorMsg EntryListing
<<redire...
SearchForm
<<build>>
globa.asa

SearchResults

82 ProcessSearch

Browsing +LetterEntry

25
GetEntries
<<link>>
SearchChar : String
nl : String <<include>>
<<link>> +LetterEntry String-Util {BeginWith}
{BeginWith} 26 Main()
GetEntries()
WriteEntry(id : long, word : string, description : string, bgColor : String)
...
WriteLetterIndex()

GlossaryHome

<<redirect>> <<build>>
{ErrDescription}

EntryListing
spErrorMsg
<<redire...
SearchForm
<<build>>
globa.asa

SearchResults
83 ProcessSearch

Code
» Apri file 16_GetEntries.asp

84

User eXperience Model

87

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
imboccare durante la visita del sito

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

88

Tre concetti nuovi:

» Screens and Content
» Storyboard scenarios
» Navigational paths attraverso gli screens

89

» 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

» Navigational Path map:
> struttura degli screens di un’applicazione insieme alle possibili
“strade” che possono essere percorse
> mappa stradale degli screens dell’applicazione

90

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
91

Esempi
» Screen:
- É molto importante realizzare un mapping
fra gli screens e gli elementi utilizzati in fase
di analisi per mantenere la tracciabilità

92

Esempi

93

Esempi

» Storyboard
scenario:
> modellato
in UML tramite
un collaboration
diagram

94

Storyboard Scenario
» L’obiettivo di uno storyboard scenario e’ quello di
esprimere un uso tipico del sistema, come visto dagli
occhi 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 dai
Web servers e contengono contenuto statico e dinamico

95

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

96

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
possibili
» Aiutano a modellare la “site map”

97

Riassumendo
» L’approccio di Conallen focalizza su:
> Progettazione Boundary/Control/Entity
> Progettazione di pagine (client e server)
> Progettazione Architetturale
> Progettazione della User eXperience

98

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
> [Con_ACM99] Modeling Web Application Architectures with UML
Jim conallen, Rational Software, June 1999
In 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.91
Jim conallen.
> [UML2000] Modeling Web Applications in the UML
UML2000 Workshop.
Workshop home page: http://www.txt.com/webuml/

99

Riassumendo

10
0

Conallen
» Basics:
> Basato sul RUP
> Guidato fortemente dall’architettura dei sistemi
Web
» Fasi:
> 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

10
1

» Idea: Utilizzare UML stereotipato per
rappresentare gli elementi di un Sito
Web,cioe’…
» Oggetti
Pagine Form

Frame COM
object
» Relazioni

Link Frame
Content
10
2

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
Page
Page Link Page

Frame Frame

10
3

ServerPage:
Metamodel Class: Class nel Class Diagram
Descrizione Rappresenta una pagina Web con degli
Script. Tali script possono interagire con
le risorse disponibli sul Server
Icona

Attributi Sono le variabili
Operazioni funzioni degli script
Vincoli Le Server Page possono solo essere
collegate ad oggetti nel Server

10
4

ClientPage:
Descrizione Rappresenta una pagina formattata in
Html. E’ un mix di dati, grafica e
link.Possono essere linkate a ClientPage e
ServerPage

Icona

Attributi Sono le variabili nei tag
Operazioni Tag degli script
Vincoli Nessuno

10
5

» 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
al browser, alle Applet, ActiveX controls, ...

» 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)

10
6

Form:
Descrizione Una form e’ una collezione di campi di
Input che fanno parte di una ClientPage

Icona

Attributi Campi di Input
Operazioni Nessuna (non possono essere incapsulate
in una form)
Vincoli Nessuno

10
7

Frame Set:
Descrizione Un Frame set e’ un contenitore di piu’
pagine Web. Un Frame Set puo’ essere
una Page o un altro Frame Set

Icona

Attributi Quelli di una Page
Operazioni Quelli di una Page

Vincoli Nessuno

10
8

Target:
Descrizione E’ un particolare Frame o una nuova
finestra del Browser linkata da altre
pagine client

Icona

Attributi ----
Operazioni ----

10
9

11
0

11
1

JavaScript:
Descrizione Su browser che abilitano i JavaScript e’
possibile utilizzare tali oggetti. Possono
esistere solo in ClientPage

Icona

11
2

Link:
Metamodel Class: Association nel Class Diagram
Descrizione 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

<< link >>
Icona

11
3

Build:
Metamodel Class: Association nel Class Diagram
Descrizione 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
dinamica

<< build >>
Icona

11
4

11
5

11
6

Page:
Metamodel Class: Component nel Component Diagram
Descrizione 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
verranno rappresentate come Classi
linkate in un Class Diagram

Icona

11
7

11
8

11
9

Tool support

12
0

Visio Stencils

12
1

Rational Rose
» IBM Rational Rose include gli stereotipi di
Conallen

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

12
2

Esempio

12
3

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
modellato utilizzando le tre diverse architetture
proposte precedentemente

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

12
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
» 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
» ...

12
6

12
7

Utilizzo di un Glossario
» Ha il compito di:
> identificare:
- Pagine Web
- Dati e Dbase
- Applicativi

» Analizzare:
> l’architettura del sistema, al fine di distribuire
componenti ed assegnare le giuste tecnologie di
sviluppo

12
8

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

» 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

12
9

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)
> Pagina di ricerca sui prodotti (risultato dinamico)
> Pagina di Logout

13
0

Thin Web Client

13
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:
> contenuto
> presentazione
> business logic

13
2

Class D

13
3

13
4

13
5

Thick Web Client

13
6

13
7

Modellazione UML per il WEB: Approccio di Conallen

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (7)

Similaire à Modellazione UML per il WEB: Approccio di Conallen

Similaire à Modellazione UML per il WEB: Approccio di Conallen (20)

Plus de Henry Muccini

Plus de Henry Muccini (20)

Modellazione UML per il WEB: Approccio di Conallen