Création d'une architecture de la solution

Une partie de la création d'une bonne architecture consiste à étudier d'autres stratégies architecturales. Ces autres stratégies présentent d'autres avantages en fonction de la plateforme choisie, des technologies utilisées et de la réutilisation de code. Chaque stratégie est conçue et des preuves de concept sont établies de façon à étudier plus avant les coûts et avantages de chaque stratégie. Les stratégies sont évaluées par rapport aux spécifications de produit et de qualité, et, pour finir, une stratégie est choisie pour l'implémentation du produit. La sécurité et les performances constituent des préoccupations architecturales pour lesquelles le travail doit porter sur l'ensemble du produit.

Dans cette rubrique

• Créer des conceptions de partitionnement d'architectures alternatives

• Concevoir le déploiement de l'architecture système

• Créer des preuves de concept

• Évaluer des alternatives

• Sélectionner l'architecture

• Développer un modèle de performance

Créer des conceptions de partitionnement d'architectures alternatives

Le problème est analysé et différentes approches sont prises en considération. Un groupe de spécifications est sélectionné, qui représente les principaux défis métier et technologiques à relever. Examinez les caractéristiques de ces défis, telles que l'intégration de systèmes hérités, et prévoyez les futurs besoins en fonction des besoins actuels, de la réutilisabilité du code et des coûts de maintenance.

Créer un diagramme d'application

À l'aide du modèle de domaine et des spécifications, créez un diagramme d'application qui représente les éléments logiques centraux du système. Ce diagramme sera ultérieurement partitionné en diagrammes système. Les autres schémas de partitionnement seront pris en considération et évalués.

L'une des façons de représenter un diagramme d'application est sous la forme d'un diagramme de cas d'usage UML (Unified Modeling Language). Ce type de diagramme peut indiquer les principaux sous-systèmes et leurs dépendances. De plus, vous pouvez placer des cas d'usage dans chaque sous-système pour indiquer le sous-système qui gère chaque scénario d'utilisateur.

Établir des critères d'évaluation

Déterminez les critères à utiliser pour identifier les spécifications et scénarios qui représentent des défis architecturaux significatifs. Consultez les documents relatifs à l'architecture d'entreprise existante pour déterminer ces critères. Étudiez tous les besoins de l'entreprise, les spécifications techniques et les normes d'entreprise qui doivent s'appliquer aux nouvelles applications. Capturez des critères supplémentaires connus pour être importants du point de vue de l'architecture, tels que l'intégration aux systèmes hérités, la réutilisabilité du code, la réutilisabilité des plateformes et bibliothèques de fournisseur existantes, et le contrôle des coûts de maintenance. Capturez des critères supplémentaires qui représentent des risques et des coûts lors de l'implémentation d'une solution technique.

Sélectionner un groupe candidat de spécifications

Évaluez les impératifs de qualité de service et les spécifications du produit par rapport aux critères d'évaluation. Si une spécification représente un défi architectural, considérez-la comme un candidat pour la modélisation. Par exemple, une spécification stipulant que le nouveau produit doit prendre en charge des bases de données client plus anciennes répond aux critères d'intégration aux systèmes hérités. Une telle spécification est candidate pour la modélisation du fonctionnement de l'intégration.

Sélectionner un groupe candidat de scénarios

Évaluez chaque scénario par rapport aux critères d'évaluation. Si un scénario représente un défi architectural, considérez-le comme un candidat pour la modélisation. Par exemple, un scénario dans lequel l'utilisateur télécharge une mise à jour cliente répond aux critères liés aux coûts de maintenance. Un tel scénario est candidat pour une modélisation liée à une meilleure gestion des mises à jour clientes.

Réduire le groupe candidat

Étudiez les scénarios et spécifications candidats. Supprimez les scénarios et spécifications qui doublent les critères d'évaluation ou sont mieux représentés par d'autres scénarios et spécifications. Réduisez le groupe candidat à un groupe central qui représente les défis architecturaux clés, les risques et les coûts de la nouvelle application. Conservez les scénarios et spécifications qui représentent le mieux les critères d'évaluation, qui présentent le moins de risques et qui présentent le meilleur coût pour la création de l'architecture d'une solution technique. Gardez les scénarios et spécifications qui représentent les parties les plus complètes ou centrales de l'application.

Créer des critères de partitionnement

À l'aide des spécifications, analysez les modèles architecturaux établis (tels que la façade ou le modèle Model-View-Controller) et identifiez les candidats potentiels à l'implémentation. Identifiez les modèles candidats en fonction de leur motivation et étudiez leurs compromis de conception par rapport aux fonctions de couplage, cohésion, extensibilité, adaptabilité et flexibilité. Sélectionnez un ensemble de candidats pour l'implémentation en tant qu'alternatives pour l'évaluation.

Concevoir le déploiement de l'architecture système

L'architecture système définit les groupements et configurations des éléments identifiés dans le diagramme d'application. Des diagrammes système sont créés, qui capturent l'architecture système pour chaque approche architecturale possible. Les diagrammes de déploiement indiquent les étapes du déploiement basées sur les dépendances et fonctionnalités principales. Un architecte d'infrastructure crée un diagramme de centre de données logique qui décrit la structure logique du centre de données où l'application sera déployée. Les diagrammes de déploiement sont validés par rapport au diagramme de centre de données logique pour vérifier que les systèmes peuvent être déployés.

Créer un modèle de système

L'architecte et le développeur sénior créent des diagrammes système à partir du diagramme d'application. Grâce aux diagrammes système, vous pouvez concevoir des systèmes d'applications réutilisables sous la forme d'unités de déploiement en les créant à partir d'éléments du diagramme d'application. Vous pouvez également concevoir des systèmes plus grands et plus complexes qui contiennent d'autres systèmes afin de pouvoir les utiliser dans des scénarios de systèmes distribués et extraire le détail des applications de ces systèmes. Archivez chaque nouveau fichier de diagramme dans le contrôle de version.

Vous pouvez représenter des diagrammes système dans Visual Studio des façons suivantes :

• Diagrammes de cas d'usage. Les scénarios d'utilisateurs principaux sont représentés sous la forme de cas d'usage, et les composants centraux du système sont indiqués en tant que sous-systèmes. Chaque cas d'usage peut être placé à l'intérieur du sous-système qui le gère. Pour plus d'informations, consultez Diagrammes de cas d'usage UML : indications.

• Diagrammes de composants UML Ces diagrammes vous permettent d'afficher les canaux de communication entre les composants, en plus des dépendances. Vous pouvez également créer des diagrammes de classes pour décrire les types qui sont visibles dans les interfaces pour les composants, et vous pouvez créer des diagrammes de séquence pour afficher leurs interactions. Pour plus d'informations, consultez Diagrammes de composants UML : indications, Diagrammes de classes UML : indications et Diagrammes de séquence UML : indications.

• Diagrammes de couches. Un diagramme de couche décrit la structure de bloc de l'application. Il affiche uniquement les composants et leurs dépendances. Son avantage est que, une fois le code écrit, vous pouvez valider le code et les dépendances par rapport au diagramme. Pour plus d'informations, consultez Diagrammes de couche : instructions.

Pour chaque sous-système, vous pouvez créer un package qui décrit ses types et son comportement avec plus de détails. Pour plus d'informations, consultez Définition de packages et d'espaces de noms..

Créer des preuves de concept

Les risques significatifs liés au projet peuvent être atténués par la création d'une preuve de concept architecturale. Il est important de gérer les risques le plus tôt possible dans le projet afin que les décisions stratégiques et architecturales clés soient prises alors qu'il est encore facile de modifier des sections fondamentales de l'architecture. La création de preuves de concept anticipées réduit les risques et inconnues liés au projet global. Des risques et des inconnues moindres rendent plus précises la planification et l'estimation des itérations ultérieures. Les preuves de concept peut être temporaires et supprimées une fois les problèmes traités, ou elles peuvent servir de base à l'architecture principale.

Examiner les risques

Ayez une bonne compréhension des éléments qui mènent à l'identification des risques ou des décisions architecturales. Examinez les impératifs de qualité de service et les scénarios liés. Recherchez les éventuelles implications pour les environnements cibles.

Planifier l'approche

Déterminez la forme de la preuve de concept requise. Utilisez les diagrammes système et d'application pour faciliter la planification. Résolvez uniquement le problème architectural identifié par le risque. Recherchez la solution la plus simple.

Générer et exécuter les preuves de concept

Générez la preuve de concept. Vous pouvez l'implémenter à partir du diagramme d'application. Restez concentré sur le problème à résoudre. Déployez la preuve de concept dans un environnement physique conforme au diagramme de centre de données logique. L'environnement physique doit correspondre le mieux possible aux paramètres du diagramme de centre de données logique. Testez la preuve de concept par rapport aux problèmes présentant des risques élevés.

Évaluer des alternatives

La méthode LAAAM (Lightweight Architecture Alternative Analysis Method) facilite la prise de décision entre différentes stratégies architecturales pour la création d'une application. La mise en œuvre de cette méthode dure généralement une journée. Commencez par générer une arborescence d'utilitaire qui décrit les pilotes fonctionnels et de qualité clés de l'application basés sur les spécifications. Chaque pilote est écrit sous la forme d'un scénario qui prend la forme d'une instruction écrite en tant que contexte, impulsion et réponse. Utilisez une matrice d'évaluation pour évaluer comment chaque stratégie gère chaque scénario.

Créer une arborescence d'utilitaire

Examinez les impératifs de qualité de service et les spécifications du produit pour déterminer les pilotes clés de la qualité et des fonctions de l'application. Construisez une arborescence d'utilitaire qui représente la qualité globale de l'application. Le nœud racine de l'arborescence s'intitule Utilitaire. Les nœuds suivants portent généralement des noms liés aux termes de qualité standard tels que modifiabilité, disponibilité et sécurité. L'arborescence doit représenter la nature hiérarchique des qualités et fournir une base pour le classement par priorité. Chaque niveau de l'arborescence constitue un affinage supplémentaire des qualités. Pour finir, ces qualités deviennent des scénarios.

Construire une matrice d'évaluation

Pour chaque nœud terminal de l'arborescence d'utilitaire, écrivez un scénario. Le scénario prend la forme d'un contexte, d'une impulsion et d'une réponse (par exemple, « Dans le cadre d'un fonctionnement normal, effectuer une transaction de base de données en moins de 100 millisecondes »).

Créez une feuille de calcul ou un tableau, et entrez chaque scénario sous la forme d'une ligne dans cette matrice d'évaluation. Entrez chaque stratégie architecturale sous la forme d'une colonne. À chaque intersection entre stratégies et scénarios, entrez une évaluation sur une échelle qui s'étend de 1 à 4.

L'évaluation doit prendre en considération les facteurs suivants :

• Coût de développement Cette solution est-elle facile ou difficile à implémenter ? Quel est son impact sur les autres domaines ?

• Coût d'exploitation Au moment de l'exécution, cette solution fonctionnera-t-elle facilement ou affectera-t-elle de façon défavorable la facilité d'utilisation, les performances, etc ?

• Risque Est-il certain que cette solution va permettre une bonne gestion du scénario ou existe-t-il des coûts inconnus ? Cette solution peut-elle avoir un impact défavorable sur la capacité de l'équipe à s'adapter à de futures améliorations des spécifications ?

Si une preuve de concept a été créée pour une stratégie, utilisez les informations de cette preuve de concept pour faciliter la détermination des valeurs.

En bas du tableau, additionnez les valeurs des scénarios. Utilisez ces chiffres dans le cadre de la discussion qui aboutit aux décisions relatives aux autres architectures.

Téléchargez l'ensemble de la matrice d'évaluation dans le portail du projet.

Sélectionner l'architecture

Une fois la matrice d'évaluation créée, une réunion de révision est organisée pour déterminer l'architecture à utiliser dans l'itération suivante. La matrice d'évaluation et les informations découlant des preuves de concept sont utilisées pour faciliter la prise de décision. Une fois l'architecture sélectionnée, ses diagrammes sont archivés en tant que solution de référence, et un document de justification est créé qui capture les raisons de ce choix.

Préparer la révision

L'architecte et le développeur sénior identifient les vérificateurs appropriés pour la révision des architectures proposées et transmettent la documentation relative aux architectures à chaque participant.

Réviser l'architecture système et de déploiement

Pendant la réunion de révision, les diagrammes système, le rapport de déploiement et le diagramme de centre de données logique sont examinés. L'objectif est de choisir une architecture à implémenter dans l'itération suivante.

Étudiez les classements des matrices d'évaluation de chaque architecture de façon à évaluer le bien-fondé de chaque architecture. Tenez compte de toutes informations découlant des preuves de concept, telles que le coût ou la complexité de l'implémentation des différentes architectures. Si le diagramme de centre de données logique représente un centre de données existant qui ne peut pas être modifié, ne l'examinez pas. Si un centre de données est en cours de création, étudiez le diagramme pour connaître les considérations relatives à son déploiement. Sélectionnez l'architecture à utiliser. Révisez le concept architectural par rapport aux scénarios de façon à valider l'adéquation de la solution par rapport aux besoins du client.

Créer une solution de référence

Créez un document de justification qui capture les décisions de la réunion. Téléchargez-le dans le portail du projet. Pour l'architecture sélectionnée, archivez toutes les applications, tous les systèmes et tous les diagrammes de centre de données logique en tant que solution de référence à utiliser pour l'implémentation des fonctionnalités dans l'itération suivante. Communiquez à l'ensemble de l'équipe et aux éventuelles équipes dépendantes la décision relative à l'architecture choisie pour l'itération suivante.

Développer un modèle de performance

La modélisation des performances permet d'identifier et de résoudre les problèmes de performances potentiels de l'application. Un modèle de performance est développé à partir d'un impératif de qualité de service, qui est ensuite divisé en plusieurs tâches de développement. Un budget fonctionnel d'implémentation est assigné à chaque tâche de développement.

Identifiez les scénarios liés à l'impératif de qualité de service de performance. Mappez les tâches de développement aux scénarios. À partir de la liste des impératifs de qualité de service, déterminez la charge de travail pour l'application. À l'aide des estimations de charge de travail et de la liste des impératifs de qualité de service, identifiez les objectifs de performance pour chaque scénario clé. Ces objectifs peuvent être le temps de réponse, le débit et l'utilisation des ressources. Identifiez les ressources relatives aux performances budgétisées pour satisfaire les objectifs de performance. Des exemples de ressources relatives aux performances sont la durée d'exécution et la bande passante réseau. Déterminez l'allocation maximale autorisée de chaque ressource.

Répartissez les ressources budgétisées entre les différentes étapes de traitement de chaque scénario. Lorsque vous n'êtes pas sûr de la façon dont vous devez allouer le budget, estimez au mieux les besoins ou répartissez les ressources de façon égale pour chaque étape. La budgétisation est affinée pendant la validation. Joignez ou écrivez l'allocation sur la tâche de développement appropriée.

Déterminez les allocations de budget qui posent des risques pour la satisfaction des objectifs de performance. Envisagez des compromis qui facilitent la satisfaction des objectifs de performance, tels des alternatives de conception et de déploiement. Réévaluez les impératifs de qualité de service si nécessaire.

Identifiez les scénarios qui ne respectent pas les allocations de budget. Évaluez les performances des scénarios. Utilisez le prototypage lors des premières itérations si le code n'est pas disponible. Répétez les étapes de budgétisation, évaluation et validation selon les besoins à l'aide des données acquises pendant la validation.

Développer un modèle de menace

Pour plus d'informations, consultez la page suivante du site Web Microsoft : Centre de développement de sécurité.