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.
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?
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.
Figura 3: Vista Scatola bianca del sottosistema di progettazione Cliente
|