Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
La deuxième étape d’un processus de conception d’application COM+ consiste à décomposer le modèle conceptuel dans les niveaux logiques de l’architecture à trois niveaux : le niveau de présentation , ou les services utilisateur ; le niveau intermédiaire ou les services métier ; et le niveau de données ou les services de données. Si vous ne connaissez pas l’architecture à trois niveaux, consultez Utilisation d’un modèle d’architecture Three-Tier.
Commencez ce processus en examinant le modèle conceptuel pour les noms et les verbes. Les noms peuvent souvent se traduire en objets métier (classes), et les verbes associés peuvent se traduire en actions (méthodes des classes). Même s’il peut être difficile de définir tous les noms en tant qu’objets métier, les omissions ou les erreurs deviendront évidents au moment où vous terminez le modèle logique.
La plupart des objets métier se retrouvent dans le niveau des services métier, avec les objets restants divisés entre les objets d’interface utilisateur du niveau des services utilisateur et les objets de données dans le niveau des services de données. Lorsque vous créez un modèle logique à l’aide de l’architecture à trois niveaux, gardez à l’esprit ce qui suit :
- Certains noms de la conception conceptuelle ne représentent pas des éléments physiques réels de données, mais peuvent représenter une action sur le système ou le rôle d’un objet métier sur le système. Un objet métier peut également être un service qui effectue un certain contrôle système, tel qu’un ID de connexion pour la sécurité.
- Évitez de créer des objets métier vagues en « lisant entre les lignes » dans le modèle conceptuel . Ces objets métier peuvent ne pas être corrects et vous devez les considérer attentivement avant de les inclure dans le modèle logique. S’ils apparaissent corrects, ajoutez-les explicitement au modèle conceptuel.
- Évitez de créer des objets métier qui expriment les mêmes informations ou fonctions ; la duplication peut être coûteuse en termes de vitesse et de performances de l’application.
- Déterminez les dépendances d’objet. Certains noms dans le modèle conceptuel peuvent simplement être des attributs d’autres objets métier. Déterminez si l’attribut peut exister indépendamment. Si c’est le cas, il doit devenir son propre objet métier ; si ce n’est pas le cas, il doit être combiné avec l’objet métier approprié.
- Évitez de créer des objets métier qui essaient de faire trop. Surcharger des objets métier peut signifier davantage de temps consacré à séparer le code plus tard et peut être un casse-tête de maintenance. Les objets distincts dans le modèle conceptuel ne doivent pas être combinés ; ils doivent rester des objets métier distincts. Vous pouvez gérer toutes les similitudes à l’aide du code pour déléguer leurs fonctions courantes à un objet métier.
- Supprimez les objets métier qui ne sont pas utilisés dans des scénarios d’utilisation. Si les objets sont destinés à prendre en charge la croissance future, envisagez de les implémenter une fois l’application initiale terminée.
À ce stade, vous pouvez commencer à penser en termes d’ordinateurs et de code. À partir de ces services métier, déterminez la fonctionnalité d’affichage et d’entrée que vous devez fournir en tant que services utilisateur. Définissez les tables et procédures stockées à fournir en tant que services de données. Pour terminer le modèle logique, définissez les interfaces pour chaque service et incluez les définitions de chaque champ de données et leurs règles de validation. Incluez également toutes les fonctions, leur syntaxe et leurs paramètres.
La définition de service ou d’objet ne doit inclure aucun aspect de l’implémentation physique. L’intention est de fournir une directive claire pour que les générateurs de composants logiques fonctionnent à partir de et pour permettre à d’autres programmeurs de coder des éléments de l’application qui peuvent utiliser le composant avant qu’il soit réellement terminé. Dans la conception de modèle logique, vous devez documenter chaque écran, fonction et objet. Ne passez pas au modèle physique ou à l’implémentation tant que vous ne répondez pas à ces critères. Si vous continuez pendant que le modèle conceptuel et le modèle logique ne sont pas en accord, vous aurez de graves problèmes plus tard dans le cycle de développement.
Le développement incrémentiel d’une application COM+ est courant. Cela implique la création d’un sous-ensemble des composants finaux, connus et les testant par le biais de chaque couche de l’application : le client, l’entreprise et les niveaux de données, jusqu’au stockage des données. Ce modèle de travail fournit un aperçu des exigences supplémentaires du client et des considérations relatives à l’implémentation. Souvent, ce modèle de travail est testé sur un seul ordinateur.
Rubriques connexes