Modèle logique : définition et planification d’application
La deuxième étape d’un processus de conception d’application COM+ consiste à diviser 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 d’entreprise ; et la couche données, ou services de données. Si vous n’êtes pas familiarisé avec l’architecture à trois niveaux, consultez Utilisation d’un modèle d’architecture Three-Tier.
Commencez ce processus en examinant dans le modèle conceptuel les noms et les verbes. Les noms peuvent souvent se traduire en objets métier (classes), et les verbes qui leur sont associés peuvent se traduire en actions (méthodes des classes). Bien qu’il puisse être difficile de définir tous les noms en tant qu’objets métier, les omissions ou les erreurs deviendront évidentes au moment où vous terminez le modèle logique.
La plupart des objets métier se retrouvent dans le niveau services d’entreprise, les objets restants étant divisés entre les objets d’interface utilisateur dans le niveau services utilisateur et les objets de données dans le niveau services de données. Lorsque vous créez un modèle logique à l’aide de l’architecture à trois niveaux, gardez à l’esprit les points suivants :
- Certains des 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 une sorte de 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 examiner attentivement avant de les inclure dans le modèle logique. Si elles semblent correctes, 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 d’en faire trop. La surcharge des objets métier peut signifier plus de temps passé à séparer le code ultérieurement 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 de code pour déléguer leurs fonctions courantes à un objet métier.
- Supprimez tous les objets métier qui ne sont utilisés dans aucun scénario 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 à réfléchir en termes d’ordinateurs et de code. À partir de ces services métier, déterminez les fonctionnalités d’affichage et d’entrée que vous devez fournir en tant que services utilisateur. Définissez les tables et les procédures stockées qui doivent être fournies 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’objectif 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 ne soit réellement terminé. Dans la conception du 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 n’avez pas satisfait à ces critères. Si vous continuez pendant que le modèle conceptuel et le modèle logique ne sont pas d’accord, vous aurez de sérieux 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 connus finaux et leur test dans chaque couche de l’application : niveaux client, métier et données, jusqu’au stockage des données. Ce modèle de travail fournit des informations sur les exigences supplémentaires du client et les considérations relatives à l’implémentation. Souvent, ce modèle de travail est testé sur un seul ordinateur.
Rubriques connexes