Modèle de conception de logiciel

Les modèles de conception de logiciels font référence à une solution réutilisable et éprouvée à un problème spécifique et récurrent, généralement axé sur la conception au niveau des composants, bien qu'ils puissent parfois s'étendre à plusieurs composants. Les modèles de conception abordent des problèmes spécifiques liés à la création, à l'interaction ou au comportement des objets.

Les motifs sont apparus comme un concept architectural dès 1977 dans A Pattern Language de Christopher Alexander (cf. son article « The Pattern of Streets », JOURNAL OF THE AIP, septembre 1966, vol. 32, n° 5, pp. 273-278). En 1987, Kent Beck et Ward Cunningham ont commencé à expérimenter l'idée d'appliquer des motifs à la programmation – en particulier aux langages de motifs – et ont présenté leurs résultats à la conférence OOPSLA cette année-là. Au cours des années suivantes, Beck, Cunningham et d'autres ont poursuivi ces travaux.

Les modèles de conception ont gagné en popularité en informatique après la publication en 1994 du livre Design Patterns: Elements of Reusable Object-Oriented Software par le soi-disant « Gang of Four » (Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides), souvent abrégé en « GoF ». La même année, la première conférence Pattern Languages ​​of Programming a eu lieu et l'année suivante, le Portland Pattern Repository a été créé pour la documentation des modèles de conception. La portée du terme reste sujette à controverse. Parmi les livres notables dans le genre des modèles de conception, on peut citer :

• Gamma, Erich ; Helm, Richard ; Johnson, Ralph ; Vlissides, John (1994). Modèles de conception : éléments de logiciels orientés objet réutilisables . Addison-Wesley . ISBN 978-0-201-63361-0.
• Brinch Hansen, Per (1995). Études en sciences informatiques : paradigmes de programmation parallèle . Prentice Hall. ISBN 978-0-13-439324-7.
• Buschmann, Frank ; Meunier, Régine ; Rohnert, Hans; Sommerlad, Peter (1996). Architecture logicielle orientée modèles, Volume 1 : Un système de modèles . John Wiley et fils. ISBN 978-0-471-95869-7.
• Beck, Kent (1997). Modèles de bonnes pratiques Smalltalk . Prentice Hall. ISBN 978-0134769042.
• Schmidt, Douglas C. ; Stal, Michael ; Rohnert, Hans ; Buschmann, Frank (2000). Architecture logicielle orientée modèles, volume 2 : modèles pour objets concurrents et en réseau . John Wiley & Sons. ISBN 978-0-471-60695-6.
• Fowler, Martin (2002). Modèles d'architecture d'application d'entreprise . Addison-Wesley . ISBN 978-0-321-12742-6.
• Hohpe, Gregor ; Woolf, Bobby (2003). Modèles d'intégration d'entreprise : conception, création et déploiement de solutions de messagerie . Addison-Wesley . ISBN 978-0-321-20068-6.
• Freeman, Eric T. ; Robson, Elisabeth ; Bates, Bert ; Sierra, Kathy (2004). Modèles de conception Head First . O'Reilly Media . ISBN 978-0-596-00712-6.
• Larman, Craig (2004). Application d'UML et de modèles (3e éd., 1re éd. 1995) . Pearson. ISBN 978-0131489066.

Bien que les modèles de conception soient appliqués dans la pratique depuis longtemps, la formalisation du concept de modèles de conception a stagné pendant plusieurs années.

Les modèles de conception de logiciels offrent la granularité la plus fine par rapport aux modèles et styles d'architecture logicielle, car les modèles de conception se concentrent sur la résolution de problèmes de conception détaillés et de bas niveau au sein de composants ou de sous-systèmes individuels. Les exemples incluent Singleton, Factory Method et Observer.

Le modèle d'architecture logicielle fait référence à une solution réutilisable et éprouvée à un problème récurrent au niveau du système, qui répond aux préoccupations liées à la structure globale, aux interactions des composants et aux attributs de qualité du système. Les modèles d'architecture logicielle fonctionnent à un niveau d'abstraction plus élevé que les modèles de conception, résolvant des défis plus vastes au niveau du système. Bien que ces modèles affectent généralement les préoccupations au niveau du système, la distinction entre les modèles d'architecture et les styles d'architecture peut parfois être floue. Les exemples incluent le disjoncteur .

Le style d'architecture logicielle fait référence à une organisation structurelle de haut niveau qui définit l'organisation globale du système, en spécifiant comment les composants sont organisés, comment ils interagissent et les contraintes sur ces interactions. Les styles d'architecture incluent généralement un vocabulaire de types de composants et de connecteurs, ainsi que des modèles sémantiques pour interpréter les propriétés du système. Ces styles représentent le niveau le plus grossier d'organisation du système. Les exemples incluent l'architecture en couches , les microservices et l'architecture pilotée par les événements .

Les modèles de conception peuvent accélérer le processus de développement en fournissant des paradigmes de développement éprouvés. Une conception logicielle efficace nécessite de prendre en compte des problèmes qui peuvent ne pas devenir apparents avant plus tard dans la mise en œuvre. Le code fraîchement écrit peut souvent contenir des problèmes cachés et subtils qui prennent du temps à être détectés ; des problèmes qui peuvent parfois causer des problèmes majeurs par la suite. La réutilisation des modèles de conception peut aider à prévenir de tels problèmes, et améliorer la lisibilité du code pour ceux qui connaissent les modèles.

Les techniques de conception de logiciels sont difficiles à appliquer à une gamme plus large de problèmes. Les modèles de conception fournissent des solutions générales, documentées dans un format qui ne nécessite pas de spécificités liées à un problème particulier.

En 1996, Christopher Alexander a été invité à prononcer un discours d'ouverture à la convention OOPSLA de 1996. Il y a évoqué la manière dont son travail sur les modèles en architecture s'est développé et ses espoirs quant à la manière dont la communauté de conception de logiciels pourrait aider l'architecture à étendre les modèles pour créer des structures vivantes qui utilisent des schémas génératifs qui ressemblent davantage à du code informatique.

Un modèle décrit un motif de conception , également appelé microarchitecture prototypique , comme un ensemble de constituants du programme (par exemple, des classes, des méthodes...) et leurs relations. Un développeur adapte le motif à sa base de code pour résoudre le problème décrit par le modèle. Le code résultant a une structure et une organisation similaires au motif choisi.

Des efforts ont également été faits pour codifier les modèles de conception dans des domaines particuliers, y compris l'utilisation de modèles de conception existants ainsi que de modèles de conception spécifiques à un domaine. Les exemples incluent les modèles de conception d'interface utilisateur , la visualisation d'informations , la conception sécurisée, la « facilité d'utilisation sécurisée », la conception Web et la conception de modèles commerciaux.

Les actes de la conférence annuelle Pattern Languages ​​of Programming incluent de nombreux exemples de modèles spécifiques à un domaine.

Les modèles de conception orientés objet montrent généralement les relations et les interactions entre les classes ou les objets , sans spécifier les classes ou les objets d'application finaux impliqués. Les modèles qui impliquent un état mutable peuvent ne pas être adaptés aux langages de programmation fonctionnels . Certains modèles peuvent être rendus inutiles dans les langages qui ont un support intégré pour résoudre le problème qu'ils tentent de résoudre, et les modèles orientés objet ne sont pas nécessairement adaptés aux langages non orientés objet.

Les modèles de conception peuvent être organisés en groupes en fonction du type de problème qu'ils résolvent. Les modèles de création créent des objets. Les modèles structurels organisent les classes et les objets pour former des structures plus grandes qui fournissent de nouvelles fonctionnalités. Les modèles comportementaux assurent la communication entre les objets et la réalisation de ces modèles.

La documentation d'un modèle de conception décrit le contexte dans lequel le modèle est utilisé, les forces au sein du contexte que le modèle cherche à résoudre et la solution suggérée. Il n'existe pas de format unique et standard pour la documentation des modèles de conception. Au contraire, une variété de formats différents ont été utilisés par différents auteurs de modèles. Cependant, selon Martin Fowler , certaines formes de modèles sont devenues plus connues que d'autres et sont donc devenues des points de départ courants pour de nouveaux efforts de rédaction de modèles. Un exemple de format de documentation couramment utilisé est celui utilisé par Erich Gamma , Richard Helm , Ralph Johnson et John Vlissides dans leur livre Design Patterns . Il contient les sections suivantes :

• Nom et classification du modèle : un nom descriptif et unique qui aide à identifier et à référencer le modèle.
• Intention : Une description de l’objectif derrière le modèle et la raison de son utilisation.
• Également connu sous le nom : Autres noms du modèle.
• Motivation (Forces) : Un scénario composé d’un problème et d’un contexte dans lequel ce modèle peut être utilisé.
• Applicabilité : Situations dans lesquelles ce modèle est utilisable ; le contexte du modèle.
• Structure : représentation graphique du modèle. Des diagrammes de classes et des diagrammes d'interaction peuvent être utilisés à cette fin.
• Participants : Une liste des classes et des objets utilisés dans le modèle et leurs rôles dans la conception.
• Collaboration : une description de la manière dont les classes et les objets utilisés dans le modèle interagissent les uns avec les autres.
• Conséquences : une description des résultats, des effets secondaires et des compromis causés par l’utilisation du modèle.
• Implémentation : description d'une implémentation du modèle ; la partie solution du modèle.
• Exemple de code : une illustration de la manière dont le modèle peut être utilisé dans un langage de programmation.
• Utilisations connues : Exemples d'utilisations réelles du modèle.
• Modèles apparentés : Autres modèles qui ont une certaine relation avec le modèle ; discussion des différences entre le modèle et des modèles similaires.

Certains suggèrent que les modèles de conception peuvent être un signe que des fonctionnalités manquent dans un langage de programmation donné ( Java ou C++ par exemple). Peter Norvig démontre que 16 des 23 modèles du livre Design Patterns (qui est principalement axé sur C++) sont simplifiés ou éliminés (via un support de langage direct) dans Lisp ou Dylan . Des observations similaires ont été faites par Hannemann et Kiczales qui ont implémenté plusieurs des 23 modèles de conception en utilisant un langage de programmation orienté aspect (AspectJ) et ont montré que les dépendances au niveau du code ont été supprimées des implémentations de 17 des 23 modèles de conception et que la programmation orientée aspect pouvait simplifier les implémentations des modèles de conception. Voir également l'essai de Paul Graham « Revenge of the Nerds ».

L'utilisation inappropriée de modèles peut augmenter inutilement la complexité. FizzBuzzEnterpriseEdition offre un exemple humoristique de la complexité excessive introduite par les modèles de conception.

Par définition, un modèle doit être reprogrammé dans chaque application qui l'utilise. Certains auteurs y voyant un pas en arrière par rapport à la réutilisation de logiciels telle que fournie par les composants , les chercheurs ont travaillé à transformer les modèles en composants. Meyer et Arnout ont pu fournir une componentisation complète ou partielle des deux tiers des modèles qu'ils ont essayés.

Afin d'obtenir une certaine flexibilité, les modèles de conception peuvent introduire des niveaux d' indirection supplémentaires , ce qui peut compliquer la conception résultante et diminuer les performances d'exécution .