Techniques d'architecture

Approche itérative et incrémentale

Il s'agit d'une approche itérative et incrémentale composée de cinq étapes principales qui permet de générer des solutions candidates. Cette solution candidate peut encore être affinée en répétant ces étapes et enfin créer une conception d'architecture qui correspond le mieux à notre application. À la fin du processus, nous pouvons revoir et communiquer notre architecture à toutes les parties intéressées.

Ce n'est qu'une approche possible. Il existe de nombreuses autres approches plus formelles qui définissent, révisent et communiquent votre architecture.

Identifier l'objectif de l'architecture

Identifiez l'objectif d'architecture qui forme l'architecture et le processus de conception. Des objectifs irréprochables et définis mettent l'accent sur l'architecture, résolvent les bons problèmes dans la conception et aident à déterminer quand la phase actuelle est terminée et prêt à passer à la phase suivante.

Cette étape comprend les activités suivantes -

• Identifiez vos objectifs d'architecture dès le départ.
• Identifiez le consommateur de notre architecture.
• Identifiez les contraintes.

Des exemples d'activités d'architecture incluent la création d'un prototype pour obtenir des commentaires sur l'interface utilisateur de traitement des commandes pour une application Web, la création d'une application de suivi des commandes client et la conception de l'architecture d'authentification et d'autorisation pour une application afin d'effectuer un examen de sécurité.

Scénarios clés

Cette étape met l'accent sur le design qui compte le plus. Un scénario est une description détaillée et complète de l'interaction d'un utilisateur avec le système.

Les scénarios clés sont ceux qui sont considérés comme les scénarios les plus importants pour le succès de votre application. Cela aide à prendre des décisions sur l'architecture. Le but est d'atteindre un équilibre entre les objectifs utilisateur, métier et système. Par exemple, l'authentification des utilisateurs est un scénario clé car elles sont une intersection d'un attribut de qualité (sécurité) avec des fonctionnalités importantes (comment un utilisateur se connecte à votre système).

Aperçu de l'application

Créez une vue d'ensemble de l'application, ce qui rend l'architecture plus accessible, la connectant aux contraintes et aux décisions du monde réel. Il comprend les activités suivantes -

Identifier le type d'application

Identifiez le type d'application, qu'il s'agisse d'une application mobile, d'un client riche, d'une application Internet riche, d'un service, d'une application Web ou d'une combinaison de ces types.

Identifier les contraintes de déploiement

Choisissez une topologie de déploiement appropriée et résolvez les conflits entre l'application et l'infrastructure cible.

Identifier les styles de conception d'architecture importants

Identifiez les styles de conception d'architecture importants tels que client / serveur, couches, bus de messages, conception axée sur le domaine, etc. pour améliorer le partitionnement et promouvoir la réutilisation de la conception en fournissant des solutions aux problèmes fréquemment récurrents. Les applications utilisent souvent une combinaison de styles.

Identifier les technologies pertinentes

Identifiez les technologies pertinentes en considérant le type d'application que nous développons, nos options préférées pour la topologie de déploiement des applications et les styles architecturaux. Le choix des technologies sera également guidé par les politiques de l'organisation, les limites de l'infrastructure, les compétences en ressources, etc.

Problèmes clés ou points chauds clés

Lors de la conception d'une application, les points chauds sont les zones où les erreurs sont le plus souvent commises. Identifiez les problèmes clés en fonction des attributs de qualité et des préoccupations transversales. Les problèmes potentiels incluent l'apparition de nouvelles technologies et les exigences commerciales critiques.

Les attributs de qualité sont les fonctionnalités globales de votre architecture qui affectent le comportement d'exécution, la conception du système et l'expérience utilisateur. Les préoccupations transversales sont les caractéristiques de notre conception qui peuvent s'appliquer à toutes les couches, composants et niveaux.

Ce sont également les domaines dans lesquels des erreurs de conception à fort impact sont le plus souvent commises. Des exemples de problèmes transversaux sont l'authentification et l'autorisation, la communication, la gestion de la configuration, la gestion et la validation des exceptions, etc.

Solutions pour les candidats

Après avoir défini les points chauds clés, créez l'architecture de base initiale ou la première conception de haut niveau, puis commencez à renseigner les détails pour générer l'architecture candidate.

L'architecture candidate comprend le type d'application, l'architecture de déploiement, le style architectural, les choix technologiques, les attributs de qualité et les préoccupations transversales. Si l'architecture candidate est une amélioration, elle peut devenir la base à partir de laquelle de nouvelles architectures candidates peuvent être créées et testées.

Validez la conception de la solution candidate par rapport aux principaux scénarios et exigences déjà définis, avant de suivre de manière itérative le cycle et d'améliorer la conception.

Nous pouvons utiliser des pointes architecturales pour découvrir les domaines spécifiques de la conception ou pour valider de nouveaux concepts. Les pointes architecturales sont un prototype de conception, qui détermine la faisabilité d'un chemin de conception spécifique, réduit le risque et détermine rapidement la viabilité des différentes approches. Testez les pics architecturaux par rapport aux principaux scénarios et hotspots.

Examen de l'architecture

La révision de l'architecture est la tâche la plus importante afin de réduire le coût des erreurs et de trouver et de résoudre les problèmes d'architecture le plus tôt possible. C'est un moyen bien établi et rentable de réduire les coûts de projet et les chances d'échec du projet.

• Passez régulièrement en revue l'architecture lors des étapes importantes du projet et en réponse à d'autres changements architecturaux importants.

• Le principal objectif d'une revue d'architecture est de déterminer la faisabilité des architectures de base et candidates, qui vérifient correctement l'architecture.

• Relie les exigences fonctionnelles et les attributs de qualité à la solution technique proposée. Il aide également à identifier les problèmes et à identifier les domaines à améliorer

Les évaluations basées sur des scénarios sont une méthode dominante pour examiner une conception d'architecture qui se concentre sur les scénarios les plus importants du point de vue de l'entreprise et qui ont le plus grand impact sur l'architecture.

Méthode d'analyse de l'architecture logicielle (SAAM)

Il est à l'origine conçu pour évaluer la modifiabilité, mais a ensuite été étendu pour examiner l'architecture en ce qui concerne les attributs de qualité.

Méthode d'analyse des compromis d'architecture (ATAM)

Il s'agit d'une version perfectionnée et améliorée de SAAM, qui examine les décisions architecturales en ce qui concerne les exigences des attributs de qualité, et dans quelle mesure elles répondent à des objectifs de qualité particuliers.

Revue de conception active (ADR)

Il convient mieux aux architectures incomplètes ou en cours, qui se concentrent davantage sur un ensemble de problèmes ou des sections individuelles de l'architecture à la fois, plutôt que d'effectuer une révision générale.

Examens actifs des conceptions intermédiaires (ARID)

Il combine l'aspect ADR de la révision de l'architecture en cours avec une concentration sur un ensemble de problèmes, et l'approche ATAM et SAAM de la révision basée sur des scénarios axée sur les attributs de qualité.

Méthode d'analyse coûts-avantages (CBAM)

Il se concentre sur l'analyse des coûts, des avantages et des implications de calendrier des décisions architecturales.

Analyse de la modifiabilité au niveau de l'architecture (ALMA)

Il évalue la modifiabilité de l'architecture des systèmes d'information métier (BIS).

Méthode d'évaluation de l'architecture familiale (FAAM)

Il évalue les architectures des familles de systèmes d'information pour l'interopérabilité et l'extensibilité.

Communication de la conception de l'architecture

Après avoir terminé la conception de l'architecture, nous devons communiquer la conception aux autres parties prenantes, qui incluent l'équipe de développement, les administrateurs système, les opérateurs, les propriétaires d'entreprise et d'autres parties intéressées.

Il existe plusieurs méthodes bien connues suivantes pour décrire l'architecture à d'autres: -

Modèle 4 + 1

Cette approche utilise cinq vues de l'architecture complète. Parmi eux, quatre vues (lelogical view, la process view, la physical view, et le development view) décrivent l'architecture à partir de différentes approches. Une cinquième vue présente les scénarios et les cas d'utilisation du logiciel. Il permet aux parties prenantes de voir les caractéristiques de l'architecture qui les intéressent spécifiquement.

Langage de description d'architecture (ADL)

Cette approche est utilisée pour décrire l'architecture logicielle avant la mise en œuvre du système. Il répond aux préoccupations suivantes: comportement, protocole et connecteur.

Le principal avantage de l'ADL est que nous pouvons analyser l'architecture pour en vérifier l'exhaustivité, la cohérence, l'ambiguïté et les performances avant de commencer officiellement à utiliser la conception.

Modélisation agile

Cette approche suit le concept selon lequel «le contenu est plus important que la représentation». Il garantit que les modèles créés sont simples et faciles à comprendre, suffisamment précis, détaillés et cohérents.

Les documents du modèle Agile ciblent des clients spécifiques et répondent aux efforts de travail de ce client. La simplicité du document garantit une participation active des parties prenantes à la modélisation de l'artefact.

IEEE 1471

IEEE 1471 est le nom abrégé d'une norme officiellement connue sous le nom de ANSI / IEEE 1471-2000, «Pratique recommandée pour la description de l'architecture des systèmes logiciels intensifs». IEEE 1471 améliore le contenu d'une description architecturale, en particulier, en donnant une signification spécifique au contexte, aux vues et aux points de vue.

Langage de modélisation unifié (UML)

Cette approche représente trois vues d'un modèle de système. lefunctional requirements view (exigences fonctionnelles du système du point de vue de l'utilisateur, y compris les cas d'utilisation); the static structural view(objets, attributs, relations et opérations, y compris les diagrammes de classes); et ledynamic behavior view (collaboration entre objets et modifications de l'état interne des objets, y compris les diagrammes de séquence, d'activité et d'état).