Linea guida: Creazione di applicazioni Web con UML
Questa linea guida porta avanti l'analisi del caso d'uso ad un passo successivo per iniziare la progettazione delle applicazioni Web.
Relazioni
Elementi correlati
Descrizione principale

Riferimenti

I seguenti manuali e documenti sono dei riferimenti per queste linee guida:

Elaborazione sull'analisi del caso d'uso

Quello che è diverso, facendo il confronto con il Compito: Analisi del caso d'uso è che le classi boundary sono più focalizzate e a scopo singolo. Gli oggetti di queste classi hanno vita breve e qualsiasi stato del client (nelle pagine web) deve essere gestito esplicitamente da meccanismi specifici. Ad esempio, le pagine di Microsoft Active Server utilizzano i "cookie" come indice in una mappa di stato di tutti i client attivi correntemente.

Inoltre, quando si legge le specifica di un caso d'uso, accade quanto segue: 

  • Qualsiasi citazione di pagina web viene convertita in una classe boundary. 
  • Qualsiasi citazione di collegamento ipertestuale si traduce in un'associazione da una classe boundary ad un'altra classe boundary o classe controller. 
  • I verbi o le descrizioni dei processi tendono ad associarsi alle classi controller. 
  • I sostantivi si associano a delle classi di entità. 

La classe boundary, attraverso la quale vengono avviate le comunicazioni, conversa con una classe controller. La classe controller in genere non risponde nella stessa istanza della classe boundary.

Utilizzo dei diagrammi di interazione

Col procedere dell'analisi del caso d'uso, gli scenari possono essere descritti con i diagrammi di sequenza. Questo è utile per la convalida dell'esistenza degli oggetti di analisi rispetto ad uno scenario di caso d'uso. Se viene rilevato che gli oggetti dell'analisi non partecipano ad alcuno scenario, divengono sospetti e devono essere rivalutati. Il rischio è che se si scende troppo in dettaglio, i diagrammi divengono grandi ed ingestibili. Per evitare ciò, concentrarsi su scenari discreti e brevi, ed includere solo oggetti boundary, controller principale ed entità.

Ricordarsi che nelle applicazioni web gli oggetti boundary hanno una vita breve. Una classe boundary, tuttavia, può essere istanziata diverse volte durante l'esecuzione di uno scenario, il che comporta che nel diagramma verranno istanziati diversi oggetti boundary dalla stessa classe.

L'attore in un diagramma di sequenza a livello di analisi interagisce con un oggetto boundary. Viene inviato un messaggio di esplorazione dall'attore all'oggetto boundary.

Creazione delle classi di progettazione iniziali

Progettazioni iniziali della classe boundary

Una classe boundary può essere associata ad una classe di pagina client.

Se la classe boundary implica l'input di informazioni, in genere la si associa ad un modulo (o modulo web) mediante aggregazione. Un modulo può essere modellato come classe nidificata della pagina client, poiché il suo intero ciclo di vita è governato dalla pagina client. I moduli hanno sempre una relazione di inoltro con una pagina server, che elabora i valori del modulo, portando infine alla restituzione di una nuova pagina client.

Se l'interfaccia utente richiede un comportamento dinamico sul client, il modo più semplice di ottenerlo è mediante l'utilizzo di HTML dinamico sul client. Nel modello di progettazione in genere questo ha l'aspetto di operazioni sulla pagina del client. Le operazioni sulla pagina client si associano direttamente alle funzioni java script. Gli attributi di una pagina java si associano direttamente alle variabili d'ambito della pagina. I gestori dell'evento HTML dinamico vengono catturati come valori con tag.

Se l'interfaccia utente ha un comportamento molto sofisticato, associare un'applet alla classe boundary, mediante aggregazione.

Se l'architettura si basa su un sistema di oggetti distribuiti (come RMI, IIOP o DCOM), la pagina client può citare le interfacce ai componenti che comunicano direttamente con il server utilizzando RMI, IIO o DCOM, aggirando HTTP. Questi tipi di relazioni in genere sono <<rmi>>, <<iiop>> o <<dcom>> stereotipati per indicare al progettista le aree in cui si verificherà il traffico di rete, quindi candidate ai colli di bottiglia.

Progettazioni iniziali della classe entità

nella progettazione di un'applicazione web, l'unica cosa diversa delle classi di entità è che, se l'oggetto risiede nell'ambito della pagina client, l'oggetto entità si assocerà ad un oggetto java script.

Progettazioni iniziali della classe controller

Le classi di controllo si associano alle pagine server. I controller esprimono e coordinano la logica di business, e coordinano le altre logiche. In genere risiedono sul server. Molti oggetti controller sono responsabili della creazione delle pagine client (essenzialmente, utilizzano HTML come output principale). Gli oggetti controller possono interagire con le risorse della parte server, ad esempio i database, i componenti del livello centrale, i monitor i transazione, ecc. ecc. 

Le classi controller in genere si associano alle pagine web create con script della parte server (pagine Active Server Page, pagine server java).