Hiérarchie de motifs

Les motifs vont de l'abstrait au concret. Les motifs abstraits représentent des concepts sans références physiques (c'est-à-dire qui ne sont pas accessibles aux sens). Le concret fait référence aux objets qui sont accessibles aux sens. Par exemple, la liberté est abstraite, mais le livre (sur la liberté) est concret.

Les motifs axés sur la conception sont organisés en une hiérarchie de motifs (pattern hierarchy) qui comprend les styles architecturaux, les patrons d'architecture et les patrons de conception. Un motif abstrait situé au sommet de la hiérarchie de motifs est appelé un style architectural (architectural style) ; il capture un ensemble de caractéristiques et de fonctionnalités qui rendent une structure identifiable. Les styles sont conçus pour capturer les connaissances d'une conception efficace pour atteindre des objectifs spécifiés dans un contexte particulier. Un patron d'architecture est conforme à des styles architecturaux spécifiques et incarne des décisions de conception architecturale applicables à des problèmes de conception récurrents. Ils fournissent des modèles paramétrés qui peuvent être adaptés pour fournir des solutions adaptées à différents contextes de développement. Les patrons de conception sont conformes à des patrons d'architecture spécifiques et fournissent des composants (component) de conception granulaires pour les articuler.

Une fois qu'une pile technologique qui choisit les technologies spécifiques à utiliser pour implémenter la solution a été sélectionnée, les motifs axés sur la conception peuvent être implémentés. Chaque pile technologique possède une hiérarchie de motifs axée sur l'implémentation correspondante2 qui comprend des styles d'implémentation, des motifs d'implémentation et des idiomes. Un idiome (idiom) est une expression ou une locution dont le sens ne peut être déduit des définitions littérales de ses mots individuels, mais qui est plutôt compris par l'usage courant au sein d'une langue.

Les architectes de solutions créent plusieurs processus complexes pour implémenter avec succès une solution d'affaires. Ces étapes sont :

1. Étudier les éléments technologiques qui peuvent être appliqués pour résoudre un problème spécifique.
2. Proposer une combinaison de blocs de construction pour la meilleure solution possible au problème.
3. Concevoir une solution et gérer l'implémentation.

Une fois que l'architecte de solution a finalisé la conception et l'implémentation de la solution, les architectes d'entreprise vérifient que la stratégie des technologies de l'information est alignée sur la mission de l'entreprise en analysant les propriétés commerciales. Les architectes d'entreprise et de solution utilisent des hiérarchies de motifs pour créer des bonnes pratiques pour les architectures commerciales et techniques qui guident l'implémentation de solutions aux problèmes d'affaires. La généralisation et le masquage de l'information sont utilisés pour maintenir les motifs plus abstraits au sommet de la hiérarchie. La technologie qui permet la gestion de l'architecture résulte de décennies de recherche en gestion des motifs et de cadriciels utilisés pour planifier et livrer des solutions qui répondent aux stratégies commerciales et technologiques.

Motifs de modèle d'analyse et de conception

Un plan est un plan de haut niveau utilisé dans la phase de développement, et une architecture d'entreprise (EA) (enterprise architecture (EA)) est un plan conceptuel qui définit la structure et le fonctionnement des organisations. La modélisation de conception offre une variété de vues différentes du système, comme des plans d'architecture pour l'entreprise. Des exemples de style architectural axé sur la conception sont les microservices (microservices). Un exemple de style d'implémentation axé sur l'implémentation correspondant est les services REST. Lorsque le problème apparaît, un patron d'architecture incarne des décisions de conception architecturale applicables à un problème de conception récurrent, paramétrées pour tenir compte de différents contextes de développement de solutions.

Un patron de conception se rapporte aux structures et pratiques de conception courantes qui permettent la création de logiciels réutilisables. Un exemple de patron de conception est un singleton. Un singleton (singleton) restreint l'instanciation d'une classe et garantit qu'une seule instance de la classe existe (par exemple, un objet tableau de bord dans un jeu devrait être dérivé d'une classe singleton pour s'assurer qu'il n'y a qu'un seul objet tableau de bord et un seul ensemble de scores pour les joueurs à tout moment donné). La portée de l'architecture d'entreprise comprend :

• Portée de l'entreprise : motifs de niveau supérieur qui peuvent être appliqués à la structure globale de l'entreprise
• Portée de la solution : le motif qui peut être appliqué à une seule solution ou un seul système
• Portée du domaine : le motif qui peut être appliqué à un domaine spécifique

Une hiérarchie de motifs s'applique à tous les niveaux de portée, mais les variantes des motifs de niveau supérieur ajoutent des motifs intégrés supplémentaires qui peuvent être documentés comme un modèle d'architecture d'entreprise (EA) donné, lequel est décrit plus spécifiquement aux niveaux du portefeuille ou du système. Cela est similaire à la carte d'une ville faisant partie de la carte d'une région au sein de la carte du monde, comme le montre la Figure 10.2.

Figure 10.2 Un plan montre les niveaux d'entreprise descendants : entreprise, portefeuille, système et sous-système. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Motifs d'implémentation

Dans les langages de programmation orientée objet tels que Java, une classe singleton ne peut avoir qu'un seul objet à la fois. Le but d'une classe singleton est de restreindre le nombre de créations d'objets à un seul, ce qui assure le contrôle d'accès aux ressources. Une classe singleton Java (Figure 10.3) est un exemple axé sur l'implémentation correspondant d'un idiome qui implémente un patron de conception singleton et permet à une seule instance d'une classe Java d'exister, comme le montre la Figure 10.4.

Figure 10.3 La classe SingletonPatternDemo accède à la classe singleton Java SingleObject en utilisant la méthode getInstance() pour retourner l'objet. showMessage affichera le message. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Figure 10.4 Une classe singleton Java est un exemple axé sur l'implémentation correspondant d'un idiome qui implémente un patron de conception singleton et permet à une seule instance d'une classe Java d'exister. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Enjeux mondiaux de la technologie

Motifs de solutions

Les problèmes et le besoin de solutions varient selon la région du monde où se trouvent les gens. Par exemple, les régions en développement économique comme l'Afrique ou certaines parties du Moyen-Orient ne disposent pas de réseaux de fibre optique aussi sophistiqués que ceux déployés en Europe, où des investissements importants ont été réalisés dans les infrastructures. Cette disparité a un impact non seulement sur l'accès à Internet, mais aussi sur le potentiel de croissance dans les systèmes d'éducation, de technologie et de soins de santé. Par conséquent, les solutions à ces problèmes sont adaptées pour répondre aux besoins uniques de ces régions. Répondre à ces besoins pourrait impliquer le développement de solutions alternatives comme l'Internet par satellite ou les réseaux mobiles à large bande, qui peuvent fournir une connectivité. Cependant, ces solutions doivent être rentables et évolutives pour s'assurer qu'elles répondent aux besoins de la population.

Catalogues de motifs

D'un point de vue descendant (par exemple, entreprise, portefeuille ou projet), l'architecture peut apparaître à différents niveaux de focalisation. Les domaines d'architecture couvrent l'ensemble de l'entreprise et incluent divers domaines d'architecture, tels que les domaines d'affaires, d'information, d'application et de technologie. Les domaines d'entreprise dans les trois perspectives sont illustrés à la Figure 10.5.

Figure 10.5 Les domaines d'architecture s'étendent à l'ensemble de l'entreprise et incluent divers domaines d'architecture, tels que les domaines d'affaires, d'information, d'application et de technologie. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Les motifs peuvent être décrits à l'aide d'une taxonomie de motifs et stockés dans un dépôt ou un catalogue de motifs. Un catalogue de motifs (pattern catalog) est une collection de motifs organisés selon des caractéristiques spécifiques et selon la manière dont les relations entre eux sont définies. La Figure 10.6 illustre la structure générale d'un catalogue de motifs. Un catalogue de motifs permet la tenue de registres de grappes de motifs à divers niveaux de spécialisation (c'est-à-dire, motifs de modèle d'analyse et de conception versus motifs d'implémentation).

Figure 10.6 La structure générale d'un catalogue de motifs permet la tenue de registres des grappes. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Un exemple de patron d'architecture d'affaires qui inclut une généralisation de la composition de services d'affaires et un motif utilisé pour décrire le séquençage des services d'affaires est l'orchestration de services d'affaires (business service orchestration). Si les données n'incluent pas de présentation de données, alors l'orchestration de services d'affaires fournit une logique additionnelle pour traiter ce type de données. Un autre exemple de patron d'architecture d'affaires qui se concentre sur la séquence observée de messages échangés par des services pairs lors de l'exécution d'une unité de travail est appelé chorégraphie de services d'affaires (business service choreography). La Figure 10.7 illustre comment divers patrons de conception d'architecture d'affaires (par exemple, échange, expédition, commande et paiement) peuvent être combinés via l'héritage et la composition pour créer un patron de conception « acheteur-vendeur ».

Figure 10.7 Divers patrons de conception d'architecture d'affaires, tels que l'échange, l'expédition, la commande et le paiement, sont combinés via l'héritage et la composition pour créer un patron de conception acheteur-vendeur. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Les motifs d'implémentation sont généralement spécifiques aux piles technologiques sélectionnées dans le cadre de la spécialisation d'une conception de solution (c'est-à-dire, une transition du modèle d'analyse et de conception à l'architecture d'implémentation). La Figure 10.8 illustre comment un catalogue de motifs est utilisé pour sélectionner les motifs et finalement créer et déployer des produits de génie logiciel à différents niveaux de projet.

Figure 10.8 Un catalogue de motifs peut être utilisé pour sélectionner le motif en fonction de la vue d'architecture et de solution pour les perspectives d'entreprise. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Langages de motifs

Comme nous l'avons appris au Chapitre 9 Génie logiciel, un langage de motifs (pattern language) offre une vue connectée de la manière d'appliquer un motif en présence d'un autre.

État actuel de la gestion des motifs

Une série de « motifs » qui créent un organigramme pour le développement de logiciels est appelée gestion des motifs (patterns management). En génie logiciel (software engineering), l'étude détaillée de l'ingénierie pour concevoir, développer et maintenir des logiciels, Christopher Alexander, un architecte de bâtiments bien connu, est considéré comme le père du mouvement du langage de motifs. Eric Gamma, Martin Fowler et plusieurs autres contributeurs font tous partie de la vaste communauté qui se concentre sur la collecte et la documentation des motifs logiciels au cours des quarante dernières années. À titre d'information, le wiki original, la technologie derrière Wikipédia, est directement issu du travail d'Alexander, selon son créateur, Ward Cunningham. Le travail de Christopher Alexander a également influencé le développement du développement logiciel agile (Agile software development), qui est une approche interactive du développement logiciel afin de livrer de la valeur aux clients, et Scrum, qui est un cadriciel de gestion qui aide l'équipe de développement à organiser le travail pour atteindre un objectif spécifique. Un cadriciel (framework) est un sous-système squelettique spécifique à l'implémentation pour le travail de conception. Un sous-système (subsystem) est un ensemble de composants (component) collaboratifs qui exécutent une tâche donnée incluse dans les systèmes logiciels, et c'est une entité distincte au sein d'une architecture logicielle.

Les architectes d'entreprise utilisent quatre domaines d'architecture et des vues d'architecture pour gérer les domaines hybrides (par exemple, une architecture de systèmes d'information est une vue architecturale qui s'étend sur les architectures d'application et de données (data architecture) et gère les flux de contrôle et de données). Par conséquent, l'applicabilité des motifs peut être qualifiée en fonction du (ou des combinaisons de) domaine(s) d'architecture auxquels ils s'appliquent, qu'il s'agisse de patrons d'architecture d'affaires ou de patrons de systèmes d'information.

Une vue plus générale promeut la tenue de registres des architectures à divers niveaux d'abstraction dans le cadre d'un continuum d'architecture (architecture continuum), représentant une structure composée de blocs de construction pour réutiliser des actifs d'architecture qui sont conformes à un langage de motifs. Les spécialisations correspondantes sont ensuite organisées dans un continuum de solutions (architecture). Dans ce cas, les architectures utilisées au niveau de l'entreprise dans l'industrie et les organisations spécifiques sont dérivées des architectures de fondation et de systèmes communs, comme le montre la Figure 10.9, puis réalisées pratiquement comme des architectures de solution.

Figure 10.9 L'architecture de fondation de The Open Group Architecture Framework (TOGAF) est en contact avec les architectures de systèmes communs, qui sont en contact avec les architectures industrielles et d'organisation. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)