Linea guida: Strutturazione del modello Implementazione per applicazioni J2EE
Questa linea guida descrive come strutturare il modello di implementazione relativo ad un'applicazione J2EE.
Relazioni
Descrizione principale

Introduzione

Si presuppone che l'utente conosca bene in generale J2EE come piattaforma di tecnologia, illustrata nel Concetto: Panoramica di J2EE (Java 2 Platform Enterprise Edition) e nel Concetto: Mappatura dalla progettazione al codice. Alcuni dei concetti di questa linea guida appartengono ad UML 1.4, anche se possono essere ugualmente applicati a plugin basati su UML 1.3. Se si ha tempo, si possono consultare le specifiche UML sull'argomento.

Strutturazione del modello di implementazione

Il Compito: Struttura del modello di implementazione descrive come produrre una struttura di un modello di implementazione completamente in linea con quella del modello di progettazione ma, al tempo stesso, riflette vincoli dell'ambiente di sviluppo e supporta lo sviluppo parallelo e l'integrazione progressiva.

La struttura del modello Implementazione relativo ad un'applicazione J2EE dipende dall'ambiente di sviluppo e di implementazione. Tuttavia, in generale, ci sono quattro potenziali strutture in un modello Implementazione J2EE:

  • Supporto di distribuzione (moduli J2EE e descrittori di distribuzione)
  • Struttura della directory virtuale (pagine JSP, HTML)
  • Directory Java per elementi distribuiti su un server Web (servlet, Javabean)
  • Directory Java per elementi distribuiti su un server dell'applicazione EJB (EJB)

Modellazione di sottosistemi di implementazione

La Vista Implementazione nel Prodotto di lavoro: Documento dell'architettura software fornisce una panoramica di alto livello del modello di implementazione, che include l'identificazione di sottosistemi di implementazione. In un'applicazione J2EE, i sottosistemi di implementazione possono non essere associati ad una singola directory nel file system o ad un pacchetto in un modello, poiché il sottosistema di implementazione può includere elementi non Java presi da un modello (come pagine JSP e HTML) ed elementi Java presi da un altro. Una strategia per gestire situazioni analoghe consiste nell'avere una struttura di pacchetto parallela in ogni modello. I pacchetti omonimi di ciascun modello sono implicitamente associati.

Un sottosistema di implementazione fornisce solitamente l'implementazione relativa ad un singolo file di implementazione distribuibile (JAR, WAR, o EAR). In tal caso, può essere utile identificare i file distribuibili per individuare poi i sottosistemi di implementazione.

Una rappresentazione di elementi fisici, ossia delle directory e dei file di implementazione, si trova normalmente in ciascun sottosistema di implementazione. Possono esserci anche elementi logici come i componenti di classi, pacchetti e così via, che corrispondono a quelli del Prodotto di lavoro: Modello di progettazione ma che sono tuttavia un modello preciso del codice sorgente (modello roundtrip engineering). Leggere il Concetto: Mappatura dalla progettazione al codice per maggiori dettagli sulla relazione tra il modello Progettazione ed il modello Implementazione.

I modelli roundtrip engineering forniscono una rappresentazione precisa del codice sorgente. In J2EE, ogni pacchetto di un modello Java rappresenta un pacchetto Java, ogni classe una classe Java e via dicendo. Tuttavia, spesso occorre aggiungere ai modelli roundtrip engineering altre informazioni, inclusi:

  • diagrammi che mostrano informazioni non prodotte automaticamente come parte del roundtrip engineering
  • astrazioni di livello superiore del modello

Le classi astratte del modello Progettazione, i componenti, i pacchetti e così via. Ci può essere comunque bisogno di astrazioni di più alto livello o di ulteriori diagrammi relativi agli elementi fisici (file e directory), che saranno descritti nelle sezioni successive.

Modellazione delle directory di implementazione

Il roundtrip engineering gestisce generalmente soltanto un sottoinsieme delle directory richieste nell'ambiente di sviluppo. Spesso occorrono altre directory per organizzare gli artefatti di verifica, le unità di distribuzione, la documentazione ecc. Di solito la modellazione non viene richiesta, poiché le directory possono essere considerate parte del sistema del file.

Modellazione di file di implementazione

In genere, i file di implementazione non vengono modellati, a meno che non sia fornito un apposito supporto da un tool di roundtrip engineering o che una relazione non troppo ovvia debba essere evidenziata.

Esiste solitamente un file .java per ogni interfaccia o classe Java e un file compilato .class per ogni file .java. Pertanto, non è interessante modellare questi file.

In J2EE, un sottosistema contiene normalmente uno o più file di archivio (JAR, WAR, o EAR).

I file di archivio sono più correttamente modellati come relazione di composizione dal file di archivio ai file in esso contenuti. Tuttavia, quando i file compilati .class si combinano per dar luogo ad un file JAR, può essere utile mostrare una dipendenza da un file JAR alle classi ed interfacce che vengono implementate alla fine.

Se il sottosistema di implementazione produce solo un file JAR, non ci sarà probabilmente bisogno di modellazione, specie se tutti i file distribuibili del sottosistema di implementazione possono essere considerati come parte del file JAR.

Sovrapporre file di archivio

È possibile, ma spesso è meglio evitarlo, definire due file di archivio che hanno alcuni elementi in comune. Ad esempio, due file EAR possono contenere soltanto certi elementi dei JAR EJB, oppure due JAR EJB tutti gli elementi degli EJB ma con diversi descrittori di distribuzione.

È preferibile che i file di archivio non si sovrappongano per mantenere una relazione stretta fra i sistemi di implementazione e i file di archivio distribuibili. Tuttavia, se è necessaria una sovrapposizione, può essere utile modellarla con il fondamento logico di queste sovrapposizioni.