Linea guida: Progettazione di sottosistemi per applicazioni J2EE
Questa linea guida descrive come progettare sottosistemi relativi ad un'applicazione J2EE.
Relazioni
Descrizione principale

Introduzione

Queste linee guida forniscono alla Linea guida: Progettazione di sottosistemi principi di base attinenti allo sviluppo di applicazioni J2EE. Si raccomanda di leggere le linee guida per la progettazione di sottosistemi prima di queste linee guida specifiche a J2EE. Tali linee guida trattano la progettazione di sottosistemi con maggiore granularità rispetto ai singoli EJB. Per informazioni sugli EJB, fare riferimento alla Linea guida: EJB (Enterprise JavaBean).

Notare inoltre che un client dell'applicazione viene considerato come sottosistema di progettazione specializzato. Vedere la Linea guida: Client dell'applicazione J2EE.

Miglioramento dei sottosistemi di progettazione

L'iniziale identificazione di un sottosistema non ne specifica la tecnologia, che verrà successivamente identificata da interfacce, descrizioni testuali e macchine a stati, che descrivono il comportamento atteso dalle operazioni. Tuttavia, simili sottosistemi neutri da tecnologie sono tipicamente trasformati in rappresentazioni specifiche alla tecnologia.

Il discorso che segue mostra la trasformazione di un sottosistema di progettazione con tecnologia non specificata.

Specifica di sottosistema (Vista Scatola nera del sottosistema)

Una specifica di sottosistema può inizialmente essere modellata come se avesse interfacce UML astratte.

Considerare la progettazione preliminare di un sottosistema Cliente, come mostra la figura 1. 

Diagramma descritto nel testo di accompagnamento.

Figura 1: Sottosistema preliminare progettazione-cliente

ICustomerMgt viene descritto ulteriormente per eseguire operazioni, come "getCustomerDetails" e "setCustomerDetails".

Man mano che la progettazione scende nei dettagli (Compito: subsystem_design_real-time_design), queste interfacce astratte sono sostituite da elementi specifici al linguaggio e alla tecnologia. (Si può scegliere di mantenere il modello più astratto del sottosistema; ad esempio, se occorre implementare la stessa progettazione in più di un linguaggio o di una tecnologia). Vedere il Concetto: Mappatura dalla progettazione al codice per la descrizione di queste opzioni. La progettazione corrispondente Prodotto di lavoro: Realizzazione di caso d'uso viene aggiornata per rispettare le modifiche all'interfaccia.

In questo esempio, la figura 2 è una vista di specifica o di scatola nera del sottosistema Cliente. La progettazione che ne deriva indica che il sottosistema Cliente dovrebbe essere un'entità EJB. Il sottosistema diprogettazione preliminare viene trasformato in interfacce EJB come segue:

  • ICustomerMgt =>
    • CustomerHome ?EJBEntityHomeInterface?
  • ICustomer =>
    • Customer ?EJBRemoteInterface?

Diagramma descritto nel testo di accompagnamento.

Figura 2: Vista Scatola nera del sottosistema di progettazione Cliente

Le interfacce mostrate dai sottosistemi di progettazione dovrebbero includere interfacce Java regolari, interfacce EJB (come le interfacce Java), EJB (remota e home) o anche una o più classi delegate o access che nascondono interamente l'esistenza di uno o più EJB. Notare che tutte queste interfacce, incluse quelle Java, sono modellate come classi UML e non come interfacce UML (vedere la Linea guida: Interfacce per applicazioni J2EE). Ad esempio, un bean di sessione viene spesso utilizzato come facade per accedere ad una serie di bean di entità strettamente collegati. In questo caso, soltanto le interfacce del bean di sessione sarebbero esportate dal sottosistema.

I bean basati sui messaggi consumano messaggi in modo asincrono da una destinazione (o endpoint). Quindi, una destinazione può anche servire da "interfaccia" per un sottosistema di progettazione che contiene bean basati sui messaggi.

Notare che le interfacce locali sono utilizzate da altri EJB strettamente abbinati all'interno dello stesso sottosistema di progettazione e che appaiono nella realizzazione di sottosistemi più spesso che in un'interfaccia visibile mostrata da un sottosistema.

Per ulteriori informazioni sulle interfacce in un'applicazione J2EE, leggere la Linea guida: Interfacce per applicazioni J2EE. Per i dettagli su come modellare gli EJB, vedere la Linea guida: EJB (Enterprise JavaBean).

Realizzazione di sottosistema (Vista Scatola bianca del sottosistema)

I sottosistemi di progettazione devono mostrare solo ciò che richiedono i client. Quindi, la classe che implementa un EJB appartiene al sottosistema ed è logicamente parte della sia realizzazione. La realizzazione di un sottosistema può diventare:

  • una serie di EJB e di classi collaborativi, nascosti da una o più classi visibili delegate o access
  • un singolo EJB con nessun'altra classe collaborativa

Tornando all'esempio del sottosistema Cliente appena citato, la realizzazione dei sottosistemi include:

  • CustomerEntityEJB (componente) ?EJBEntityBean?
  • CustomerBean ?EJBImplementation?
  • altre classi helper

La figura 3 mostra una Vista Scatola bianca (ossia interna al sottosistema) del sottosistema di progettazione. Notare che le classi EJB sono modellate come descritto nella Linea guida: EJB (Enterprise JavaBean). Questa vista interna del sottosistema viene chiamata realizzazione del sottosistema. In questa vista è possibile osservare decisioni non visibili dai client. Ad esempio, in questa realizzazione del sottosistema un DAO (Data Access Object) accede ai dati permanenti tramite API JDBC. (In un altra progettazione, si sarebbe potuta utilizzare la permanenza gestita dal contenitore). Leggere la Linea guida: EJB (Enterprise JavaBean) per ulteriori dettagli sulle classi DAO.

Diagramma descritto nel testo di accompagnamento.

Figura 3: Vista Scatola bianca del sottosistema di progettazione Cliente