Les principes clés
L'architecture logicielle est décrite comme l'organisation d'un système, où le système représente un ensemble de composants qui accomplissent les fonctions définies.
Style architectural
le architectural style, également appelé architectural pattern, est un ensemble de principes qui façonne une application. Il définit un cadre abstrait pour une famille de système en termes de modèle d'organisation structurelle.
Le style architectural est responsable de -
Fournissez un lexique des composants et des connecteurs avec des règles sur la façon dont ils peuvent être combinés.
Améliorez le partitionnement et permettez la réutilisation de la conception en apportant des solutions aux problèmes fréquents.
Décrivez une manière particulière de configurer un ensemble de composants (un module avec des interfaces bien définies, réutilisables et remplaçables) et des connecteurs (lien de communication entre les modules).
Les logiciels conçus pour les systèmes informatiques présentent l'un des nombreux styles architecturaux. Chaque style décrit une catégorie système qui englobe -
Un ensemble de types de composants qui exécutent une fonction requise par le système.
Un ensemble de connecteurs (appel de sous-programme, appel de procédure à distance, flux de données et prise) qui permettent la communication, la coordination et la coopération entre différents composants.
Contraintes sémantiques qui définissent comment les composants peuvent être intégrés pour former le système.
Une disposition topologique des composants indiquant leurs interrelations d'exécution.
Conception architecturale commune
Le tableau suivant répertorie les styles architecturaux qui peuvent être organisés en fonction de leur domaine d'intervention principal:
| Catégorie | Conception architecturale | La description |
|---|---|---|
| la communication | Bus de messages | Prescrit l'utilisation d'un système logiciel capable de recevoir et d'envoyer des messages en utilisant un ou plusieurs canaux de communication. |
| Architecture orientée services (SOA) | Définit les applications qui exposent et utilisent des fonctionnalités en tant que service à l'aide de contrats et de messages. | |
| Déploiement | Serveur client | Séparez le système en deux applications, où le client fait des requêtes au serveur. |
| 3 niveaux ou N niveaux | Sépare la fonctionnalité en segments séparés, chaque segment étant un niveau situé sur un ordinateur physiquement séparé. | |
| Domaine | Conception pilotée par le domaine | Axé sur la modélisation d'un domaine métier et la définition d'objets métier basés sur des entités au sein du domaine métier. |
| Structure | Basé sur les composants | Découpez la conception de l'application en composants fonctionnels ou logiques réutilisables qui exposent des interfaces de communication bien définies. |
| En couches | Divisez les préoccupations de l'application en groupes empilés (couches). | |
| Orienté objet | Basé sur la division des responsabilités d'une application ou d'un système en objets, chacun contenant les données et le comportement correspondant à l'objet. |
Types d'architecture
Il existe quatre types d'architecture du point de vue d'une entreprise et, collectivement, ces architectures sont appelées enterprise architecture.
Business architecture - Définit la stratégie des affaires, la gouvernance, l'organisation et les processus commerciaux clés au sein d'une entreprise et se concentre sur l'analyse et la conception des processus d'affaires.
Application (software) architecture - Sert de modèle pour les systèmes d'application individuels, leurs interactions et leurs relations avec les processus métier de l'organisation.
Information architecture - Définit les actifs de données logiques et physiques et les ressources de gestion des données.
Information technology (IT) architecture - Définit les blocs de construction matériels et logiciels qui composent le système d'information global de l'organisation.
Processus de conception d'architecture
Le processus de conception d'architecture se concentre sur la décomposition d'un système en différents composants et leurs interactions pour satisfaire les exigences fonctionnelles et non fonctionnelles. Les principales contributions à la conception de l'architecture logicielle sont:
Les exigences produites par les tâches d'analyse.
L'architecture matérielle (l'architecte logiciel fournit à son tour les exigences à l'architecte système, qui configure l'architecture matérielle).
Le résultat ou le résultat du processus de conception d'architecture est un architectural description. Le processus de conception de l'architecture de base se compose des étapes suivantes:
Comprendre le problème
C'est l'étape la plus cruciale car elle affecte la qualité de la conception qui suit.
Sans une compréhension claire du problème, il n'est pas possible de créer une solution efficace.
De nombreux projets et produits logiciels sont considérés comme des échecs car ils n'ont pas résolu un problème commercial valide ou n'ont pas un retour sur investissement (ROI) reconnaissable.
Identifier les éléments de conception et leurs relations
Dans cette phase, créez une base de référence pour définir les limites et le contexte du système.
Décomposition du système en ses principaux composants en fonction des exigences fonctionnelles. La décomposition peut être modélisée à l'aide d'une matrice de structure de conception (DSM), qui montre les dépendances entre les éléments de conception sans spécifier la granularité des éléments.
Dans cette étape, la première validation de l'architecture est effectuée en décrivant un certain nombre d'instances du système et cette étape est appelée conception architecturale basée sur les fonctionnalités.
Évaluer la conception de l'architecture
Chaque attribut de qualité reçoit une estimation afin de recueillir des mesures qualitatives ou des données quantitatives, la conception est évaluée.
Il s'agit d'évaluer la conformité de l'architecture aux exigences des attributs de qualité architecturale.
Si tous les attributs de qualité estimés sont conformes à la norme requise, le processus de conception architecturale est terminé.
Sinon, la troisième phase de la conception de l'architecture logicielle est entrée: la transformation de l'architecture. Si l'attribut de qualité observé ne répond pas à ses exigences, une nouvelle conception doit être créée.
Transformez la conception de l'architecture
Cette étape est réalisée après une évaluation de la conception architecturale. La conception architecturale doit être modifiée jusqu'à ce qu'elle satisfasse complètement aux exigences des attributs de qualité.
Il s'agit de sélectionner des solutions de conception pour améliorer les attributs de qualité tout en préservant la fonctionnalité du domaine.
Une conception est transformée en appliquant des opérateurs de conception, des styles ou des motifs. Pour la transformation, prenez la conception existante et appliquez l'opérateur de conception tel que la décomposition, la réplication, la compression, l'abstraction et le partage des ressources.
La conception est à nouveau évaluée et le même processus est répété plusieurs fois si nécessaire et même exécuté de manière récursive.
Les transformations (c'est-à-dire les solutions d'optimisation des attributs de qualité) améliorent généralement un ou certains attributs de qualité alors qu'elles affectent négativement d'autres
Principes clés de l'architecture
Voici les principes clés à prendre en compte lors de la conception d'une architecture -
Construire pour changer au lieu de construire pour durer
Réfléchissez à la manière dont l'application peut devoir évoluer au fil du temps pour répondre aux nouvelles exigences et aux nouveaux défis, et intégrez la flexibilité nécessaire pour prendre en charge cela.
Réduisez les risques et modélisez à analyser
Utilisez des outils de conception, des visualisations et des systèmes de modélisation tels que UML pour capturer les exigences et les décisions de conception. Les impacts peuvent également être analysés. Ne formalisez pas le modèle au point qu'il supprime la capacité d'itérer et d'adapter facilement la conception.
Utiliser des modèles et des visualisations comme outil de communication et de collaboration
Une communication efficace de la conception, des décisions et des changements continus de la conception est essentielle à une bonne architecture. Utilisez des modèles, des vues et d'autres visualisations de l'architecture pour communiquer et partager efficacement la conception avec toutes les parties prenantes. Cela permet une communication rapide des modifications apportées à la conception.
Identifiez et comprenez les décisions d'ingénierie clés et les domaines où les erreurs sont le plus souvent commises. Investissez pour prendre les bonnes décisions du premier coup pour rendre la conception plus flexible et moins susceptible d'être interrompue par les changements.
Utilisez une approche incrémentielle et itérative
Commencez par l'architecture de base, puis faites évoluer les architectures candidates par des tests itératifs pour améliorer l'architecture. Ajoutez de manière itérative des détails à la conception sur plusieurs passes pour obtenir la bonne image, puis concentrez-vous sur les détails.
Principes de conception clés
Voici les principes de conception à prendre en compte pour minimiser les coûts, les exigences de maintenance et maximiser l'extensibilité et l'utilisabilité de l'architecture -
Séparation des préoccupations
Divisez les composants du système en fonctionnalités spécifiques afin qu'il n'y ait pas de chevauchement entre les fonctionnalités des composants. Cela fournira une cohésion élevée et un couplage faible. Cette approche évite l'interdépendance entre les composants du système, ce qui aide à maintenir le système facilement.
Principe de responsabilité unique
Chaque module d'un système doit avoir une responsabilité spécifique, ce qui aide l'utilisateur à comprendre clairement le système. Cela devrait également aider à l'intégration du composant avec d'autres composants.
Principe de la moindre connaissance
Aucun composant ou objet ne doit avoir la connaissance des détails internes des autres composants. Cette approche évite l'interdépendance et contribue à la maintenabilité.
Minimisez dès le départ les grandes conceptions
Réduisez dès le départ les grandes conceptions si les exigences d'une application ne sont pas claires. S'il y a une possibilité de modifier les exigences, évitez de faire une grande conception pour l'ensemble du système.
Ne répétez pas la fonctionnalité
Ne pas répéter la fonctionnalité spécifie que la fonctionnalité des composants ne doit pas être répétée et qu'un morceau de code doit donc être implémenté dans un seul composant. La duplication de fonctionnalités dans une application peut rendre difficile la mise en œuvre des modifications, réduire la clarté et introduire des incohérences potentielles.
Préférer la composition à l'héritage lors de la réutilisation de la fonctionnalité
L'héritage crée une dépendance entre les enfants et les classes parentes et bloque par conséquent l'utilisation gratuite des classes enfants. En revanche, la composition offre un grand niveau de liberté et réduit les hiérarchies d'héritage.
Identifiez les composants et regroupez-les en couches logiques
Les composants d'identité et le domaine de préoccupation qui sont nécessaires dans le système pour satisfaire les exigences. Regroupez ensuite ces composants associés dans une couche logique, ce qui aidera l'utilisateur à comprendre la structure du système à un niveau élevé. Évitez de mélanger des composants de différents types de problèmes dans la même couche.
Définir le protocole de communication entre les couches
Comprendre comment les composants communiqueront entre eux, ce qui nécessite une connaissance complète des scénarios de déploiement et de l'environnement de production.
Définir le format de données pour un calque
Divers composants interagiront les uns avec les autres grâce au format de données. Ne mélangez pas les formats de données afin que les applications soient faciles à implémenter, étendre et maintenir. Essayez de garder le même format de données pour une couche, de sorte que divers composants n'aient pas besoin de coder / décoder les données tout en communiquant entre eux. Cela réduit les frais généraux de traitement.
Les composants de service système doivent être abstraits
Le code lié à la sécurité, aux communications ou aux services système tels que la journalisation, le profilage et la configuration doit être résumé dans les composants séparés. Ne mélangez pas ce code avec la logique métier, car il est facile d'étendre la conception et de la maintenir.
Exceptions de conception et mécanisme de gestion des exceptions
La définition des exceptions à l'avance aide les composants à gérer les erreurs ou les situations indésirables de manière élégante. La gestion des exceptions sera la même dans tout le système.
Conventions de nommage
Les conventions de dénomination doivent être définies à l'avance. Ils fournissent un modèle cohérent qui aide les utilisateurs à comprendre facilement le système. Il est plus facile pour les membres de l'équipe de valider le code écrit par d'autres et, par conséquent, augmentera la maintenabilité.