Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Il secondo passaggio di un processo di progettazione di applicazioni COM+ consiste nell'suddividere il modello concettuale nei livelli logici dell'architettura a tre livelli: il livello di presentazione o i servizi utente; il livello intermedioo i servizi aziendali; e il livello dati o i servizi dati. Se non si ha familiarità con l'architettura a tre livelli, vedere Uso di un modello di architettura Three-Tier.
Iniziare questo processo esaminando il modello concettuale per sostantivi e verbi. I sostantivi possono spesso tradursi in oggetti business (classi) e i verbi associati possono tradursi in azioni (metodi delle classi). Anche se può essere difficile definire tutti i sostantivi come oggetti business, le omissioni o gli errori diventeranno evidenti dal momento in cui si completa il modello logico.
La maggior parte degli oggetti business finirà nel livello di servizi business, con gli oggetti rimanenti divisi tra gli oggetti interfaccia utente nel livello di servizi utente e gli oggetti dati nel livello di servizi dati. Quando si crea un modello logico usando l'architettura a tre livelli, tenere presente quanto segue:
- Alcuni sostantivi nella progettazione concettuale non rappresentano parti fisiche effettive di dati, ma possono rappresentare un'azione sul sistema o sul ruolo di un oggetto business nel sistema. Un oggetto business può anche essere un servizio che esegue un tipo di controllo di sistema, ad esempio un ID di accesso per la sicurezza.
- Evitare di creare oggetti aziendali vaghi "leggendo tra le righe" nel modello concettuale . Tali oggetti business potrebbero non essere corretti ed è consigliabile considerarli attentamente prima di includerli nel modello logico. Se vengono visualizzati correttamente, aggiungerli al modello concettuale in modo esplicito.
- Evitare di creare oggetti business che esprimono le stesse informazioni o le stesse funzioni; la duplicazione può essere costosa in termini di velocità e prestazioni dell'applicazione.
- Determinare le dipendenze degli oggetti. Alcuni sostantivi nel modello concettuale possono essere semplicemente attributi di altri oggetti business. Decidere se l'attributo può esistere in modo indipendente. In tal caso, dovrebbe diventare il proprio oggetto di business; in caso contrario, deve essere combinato con l'oggetto business appropriato.
- Evitare di creare oggetti business che tentano di eseguire troppe operazioni. L'overload degli oggetti business può richiedere più tempo per separare il codice in un secondo momento e può essere un problema di manutenzione. Gli oggetti distinti nel modello concettuale non devono essere combinati; devono rimanere oggetti business separati. È possibile gestire qualsiasi somiglianza usando il codice per delegare le funzioni comuni a un oggetto business.
- Rimuovere tutti gli oggetti business non usati in alcun scenario di utilizzo. Se gli oggetti sono destinati a supportare la crescita futura, prendere in considerazione l'implementazione dopo il completamento dell'applicazione iniziale.
A questo punto, è possibile iniziare a pensare in termini di computer e codice. Da questi servizi aziendali, determina la funzionalità di visualizzazione e input che devi fornire come servizi utente. Definire le tabelle e le procedure memorizzate da fornire come servizi di dati. Per completare il modello logico, definire le interfacce per ogni servizio e includere le definizioni di ogni campo dati e le relative regole di convalida. Includere anche tutte le funzioni, la relativa sintassi e i relativi parametri.
La definizione del servizio o dell'oggetto non deve includere alcun aspetto dell'implementazione fisica. Lo scopo è fornire una linea guida chiara per i generatori di componenti logici da cui lavorare e consentire ad altri programmatori di scrivere codice di parti dell'applicazione che possono usare il componente prima del completamento effettivo. Nella progettazione del modello logico è necessario documentare ogni schermata, funzione e oggetto. Non passare al modello fisico o all'implementazione fino a quando non si soddisfano questi criteri. Se si procede mentre il modello concettuale e il modello logico non sono in accordo, si avranno gravi problemi più avanti nel ciclo di sviluppo.
Lo sviluppo incrementale di un'applicazione COM+ è comune. Ciò implica la creazione di un subset dei componenti finali noti, e testarli attraverso ogni livello dell'applicazione: client, business e livello dei dati, fino all'archiviazione dei dati. Questo modello di lavoro fornisce informazioni dettagliate sui requisiti aggiuntivi da parte del cliente e delle considerazioni sull'implementazione. Spesso questo modello funzionante viene testato in un singolo computer.
Argomenti correlati