I seguenti manuali e documenti sono dei riferimenti per queste linee guida:
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.
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.
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).
|