La séparation des préoccupations (SoC) est un principe de conception en informatique et en génie logiciel. Elle stipule qu'un problème complexe doit être divisé en préoccupations distinctes — aspects ou problèmes — qui peuvent être analysées, traitées ou gérées individuellement, même si elles appartiennent au même système. Cela permet de se concentrer sur un problème à la fois, réduisant ainsi la charge cognitive et la complexité.
La séparation des préoccupations peut être réalisée de plusieurs manières : temporellement (par exemple, en séquençant les activités dans un cycle de vie logiciel), par la qualité (par exemple, en traitant la correction séparément de l'efficacité ), par la vue (par exemple, en analysant le flux de données séparément du flux de contrôle) ou par la taille (modularité)
La modularité est une application spécifique du principe de séparation des préoccupations aux composants d'un système (séparation par taille). Dans les systèmes modulaires, chaque module encapsule une préoccupation unique et les modules sont conçus, implémentés et compris indépendamment avant d'être intégrés dans un système plus vaste. Bien que la modularité soit l'incarnation la plus courante et reconnaissable du SoC dans la structure du code, le principe de séparation des préoccupations est plus large. Par exemple, séparer l'analyse des exigences de l'implémentation dans le calendrier d'un projet, ou séparer les exigences fonctionnelles des exigences non fonctionnelles dans un cahier des charges, sont des formes valides de séparation des préoccupations qui n'impliquent pas nécessairement une conception modulaire.
Edsger W. Dijkstra, dans son article de 1974 intitulé « Sur le rôle de la pensée scientifique » , a inventé le terme de séparation des préoccupations en relation avec les qualités logicielles telles que l'exactitude et l'efficacité .
Carlo Ghezzi, dans son livre « Fondements du génie logiciel » promeut la séparation des préoccupations comme le principal moyen de s'attaquer à la complexité inhérente à la production de logiciels.
Philippe Kruchten, dans son article « Architectural Blueprints—The “4+1” View Model of Software Architecture » a utilisé un modèle composé de cinq vues principales pour aborder les grandes architectures ; il s’agit essentiellement d’une séparation des préoccupations basée sur les vues, où chaque vue se concentre sur un aspect différent de l’architecture.
Selon Carlo Ghezzi , le principal avantage de la modularité logicielle est qu'elle permet l'application du principe de séparation des préoccupations aux composants du système, ou « modules ». Les détails des modules peuvent être traités isolément ; de plus, l'intégration des modules est traitée comme une préoccupation distincte qui aborde les caractéristiques globales des modules logiciels et leurs relations.
Laplante, Phillip a également mentionné que la séparation des préoccupations peut être appliquée à la conception logicielle, au codage, au temps et aux qualités logicielles.
Origine
Le terme de séparation des préoccupations a probablement été inventé par Edsger W. Dijkstra dans son article de 1974 intitulé « Sur le rôle de la pensée scientifique ».
Permettez-moi de vous expliquer ce qui, à mon sens, caractérise toute pensée intelligente. Il s'agit de la volonté d'étudier en profondeur un aspect de son sujet d'étude, isolément, pour en vérifier la cohérence, tout en sachant qu'on ne se concentre que sur un seul aspect. Nous savons qu'un programme doit être correct et nous ne pouvons l'étudier que sous cet angle ; nous savons aussi qu'il doit être efficace et nous pouvons étudier son efficacité ultérieurement. Dans un autre état d'esprit, nous pouvons nous demander si, et si oui, pourquoi, ce programme est souhaitable. Mais on n'y gagne rien – bien au contraire ! – à aborder ces différents aspects simultanément. C'est ce que j'appelle parfois la « séparation des préoccupations », qui, même si elle n'est pas parfaitement réalisable, est la seule technique, à ma connaissance, permettant d'organiser efficacement sa pensée. C'est ce que j'entends par « concentrer son attention sur un aspect » : cela ne signifie pas ignorer les autres aspects, mais simplement reconnaître que, du point de vue de cet aspect, l'autre est sans importance. Il s'agit d'avoir une vision à la fois unique et multiple.
Quinze ans plus tard, il était évident que le terme Elements of Functional Programming qui décrit le SoC :
Le programmeur doit faire plusieurs choses en même temps, à savoir :
- décrire ce qui doit être calculé ;
- organiser le séquencement des calculs en petites étapes ;
- organiser la gestion de la mémoire pendant le calcul.
Reade poursuit en disant,
Idéalement, le programmeur devrait pouvoir se concentrer sur la première des trois tâches (décrire le calcul à effectuer) sans être distrait par les deux autres, plus administratives. Bien sûr, l'administration est importante, mais en la séparant de la tâche principale, on obtient généralement des résultats plus fiables et on simplifie la programmation en automatisant une grande partie des tâches administratives.
Les SoC présentent d'autres avantages. Par exemple, la validation de programmes est grandement facilitée lorsque les détails de séquencement et de gestion de la mémoire sont absents du programme. De plus, les descriptions des calculs à effectuer doivent être exemptes de descriptions détaillées étape par étape de leur exécution, si elles doivent être évaluées sur différentes architectures machine. Une séquence de petites modifications apportées à un objet de données stocké peut s'avérer inappropriée pour décrire le calcul sur une machine hautement parallèle dotée de milliers de processeurs répartis et d'un stockage local plutôt que global.
L'automatisation des aspects administratifs signifie que le développeur du langage doit s'en occuper, mais il a beaucoup plus de possibilités d'utiliser des mécanismes de calcul très différents avec des architectures de machines différentes.
Exemples
Pile de protocoles Internet
Le SoC est essentiel à la conception d'Internet. Dans la suite de protocoles Internet , des efforts considérables ont été déployés pour séparer les responsabilités en couches bien définies . Cela permet aux concepteurs de protocoles de se concentrer sur les aspects d'une couche et d'ignorer les autres. Le protocole SMTP de la couche application , par exemple, gère tous les détails du déroulement d'une session de messagerie électronique via un service de transport fiable (généralement TCP ), mais ne se préoccupe absolument pas de la manière dont ce service de transport garantit la fiabilité du service. De même, TCP ne gère pas le routage des paquets de données, qui est assuré au niveau de la couche Internet .
HTML, CSS, JavaScript
HTML , CSS et JavaScript sont des langages complémentaires utilisés pour le développement de pages web et de sites web. HTML sert principalement à organiser le contenu de la page, CSS à définir le style de présentation de ce contenu, et JavaScript à définir la manière dont le contenu interagit avec l'utilisateur. Historiquement, ce n'était pas le cas : avant l'introduction de CSS, HTML assurait à la fois la définition de la sémantique et du style.
Programmation axée sur les matières
La programmation orientée sujet permet de traiter des problématiques distinctes comme des constructions logicielles séparées, chacune étant considérée comme égale aux autres. Chaque problématique fournit sa propre structure de classes dans laquelle les objets communs sont organisés, et contribue à l'état et aux méthodes du résultat composite aux points d'interaction. Les règles de correspondance décrivent comment les classes et les méthodes des différentes problématiques sont liées entre elles, permettant ainsi de dériver un comportement composite pour une méthode à partir de plusieurs problématiques. Le SoC multidimensionnel permet de manipuler l'analyse et la composition des problématiques comme une « matrice » multidimensionnelle dans laquelle chaque problématique fournit une dimension où différents points de choix sont énumérés, les cellules de la matrice étant occupées par les artefacts logiciels appropriés.
Programmation orientée aspect
La programmation orientée aspect permet de traiter les problématiques transversales comme des problématiques principales. Par exemple, la plupart des programmes nécessitent une forme de sécurité et de journalisation . Or, la sécurité et la journalisation sont souvent des problématiques secondaires, la priorité étant généralement donnée à la réalisation des objectifs métier. Cependant, lors de la conception d'un programme, sa sécurité doit être intégrée dès le départ et non considérée comme une préoccupation secondaire. Appliquer la sécurité a posteriori aboutit souvent à un modèle de sécurité insuffisant, présentant de nombreuses failles et exposant le programme à des attaques futures. La programmation orientée aspect permet de résoudre ce problème. Par exemple, un aspect peut être défini pour garantir que les appels à une API spécifique sont toujours journalisés, ou que les erreurs sont toujours consignées lorsqu'une exception est levée, que le code procédural du programme gère ou non l'exception.
Niveaux d'analyse en intelligence artificielle
En sciences cognitives et en intelligence artificielle , on se réfère souvent aux niveaux d'analyse de David Marr . À un instant donné, un chercheur peut s'intéresser aux calculs nécessaires à un aspect de l'intelligence, à l'algorithme utilisé ou à son implémentation matérielle. Cette séparation des préoccupations est comparable à la distinction entre interface et implémentation en génie logiciel et matériel.