Programmation modulaire - Modular programming

La programmation modulaire est une technique de conception logicielle qui met l'accent sur la séparation des fonctionnalités d'un programme en modules indépendants et interchangeables , de sorte que chacun contienne tout le nécessaire pour exécuter un seul aspect de la fonctionnalité souhaitée.

Une interface de module exprime les éléments fournis et requis par le module. Les éléments définis dans l'interface sont détectables par d'autres modules. L' implémentation contient le code de travail qui correspond aux éléments déclarés dans l'interface. La programmation modulaire est étroitement liée à la programmation structurée et à la programmation orientée objet , toutes ayant le même objectif de faciliter la construction de grands logiciels et systèmes par décomposition en morceaux plus petits, et toutes originaires des années 1960. Bien que l'utilisation historique de ces termes ait été incohérente, la « programmation modulaire » fait maintenant référence à la décomposition de haut niveau du code d'un programme entier en morceaux : de la programmation structurée à l'utilisation de code de bas niveau du flux de contrôle structuré et de l'objet- programmation orientée vers l' utilisation des données d' objets , une sorte de structure de données .

Dans la programmation orientée objet, l'utilisation d'interfaces comme modèle architectural pour construire des modules est connue sous le nom de programmation basée sur les interfaces .

Terminologie

Le terme assembly (comme dans les langages .NET comme C# , F# ou Visual Basic .NET ) ou package (comme dans Dart , Go ou Java ) est parfois utilisé à la place de module . Dans d'autres implémentations, ce sont des concepts distincts ; en Python, un package est une collection de modules, tandis que dans Java 9, l'introduction du nouveau concept de module (une collection de packages avec un contrôle d'accès amélioré) a été implémentée.

De plus, le terme « package » a d'autres usages dans les logiciels (par exemple les packages .NET NuGet ). Un composant est un concept similaire, mais fait généralement référence à un niveau supérieur ; un composant est une partie d'un système entier , tandis qu'un module est une partie d'un programme individuel. L'échelle du terme « module » varie considérablement d'une langue à l'autre ; en Python, il est à très petite échelle et chaque fichier est un module, tandis que dans Java 9, il est prévu d'être à grande échelle, où un module est une collection de packages, qui sont à leur tour des collections de fichiers.

D'autres termes pour les modules incluent unit , utilisé dans les dialectes Pascal .

Support linguistique

Les langages qui prennent officiellement en charge le concept de module incluent Ada , Algol , BlitzMax , C++ , C# , Clojure , COBOL , Common_Lisp , D , Dart , eC , Erlang , Elixir , Elm , F , F# , Fortran , Go , Haskell , IBM/360 Assembler , Control Language (CL), IBM RPG , Java , MATLAB , ML , Modula , Modula-2 , Modula-3 , Morpho, NEWP , Oberon , Oberon-2 , Objective-C , OCaml , plusieurs dérivés de Pascal ( Component Pascal , Pascal Objet , Turbo Pascal , Pascal UCSD ), Perl , PL/I , PureBasic , Python , R , Ruby , Rust , JavaScript , Visual Basic .NET et WebDNA .

Des exemples remarquables de langages qui ne prennent pas en charge les modules sont C et ont été C++ et Pascal dans leur forme originale, C et C++ permettent cependant de spécifier des interfaces de compilation et de déclaration séparées à l'aide de fichiers d'en-tête . Des modules ont été ajoutés à Objective-C dans iOS 7 (2013); à C++ avec C++20 , et Pascal a été remplacé par Modula et Oberon, qui incluaient des modules dès le début, et divers dérivés qui incluaient des modules. JavaScript a des modules natifs depuis ECMAScript 2015.

La programmation modulaire peut être effectuée même lorsque le langage de programmation manque de fonctionnalités syntaxiques explicites pour prendre en charge les modules nommés, comme, par exemple, en C. Cela se fait en utilisant des fonctionnalités de langage existantes, ainsi que, par exemple, des conventions de codage , des idiomes de programmation et le physique structure du code. IBM i utilise également des modules lors de la programmation dans l' environnement de langage intégré (ILE).

Aspects clés

Avec la programmation modulaire, les préoccupations sont séparées de telle sorte que les modules exécutent des fonctions logiquement discrètes, interagissant via des interfaces bien définies. Souvent les modules forment un graphe orienté acyclique (DAG) ; dans ce cas, une dépendance cyclique entre les modules est considérée comme indiquant que ceux-ci doivent être un seul module. Dans le cas où les modules forment un DAG, ils peuvent être organisés en hiérarchie, où les modules de niveau le plus bas sont indépendants, ne dépendent d'aucun autre module, et les modules de niveau supérieur dépendent de ceux de niveau inférieur. Un programme ou une bibliothèque particulière est un module de niveau supérieur de sa propre hiérarchie, mais peut à son tour être considéré comme un module de niveau inférieur d'un programme, d'une bibliothèque ou d'un système de niveau supérieur.

Lors de la création d'un système modulaire, au lieu de créer une application monolithique (où le plus petit composant est le tout), plusieurs modules plus petits sont écrits séparément de sorte qu'ils construisent le programme d'application exécutable lorsqu'ils sont composés ensemble. Typiquement, ceux-ci sont également compilés séparément, via une compilation séparée , puis liés par un éditeur de liens . Un compilateur juste-à-temps peut effectuer une partie de cette construction "à la volée" au moment de l'exécution .

Ces fonctions indépendantes sont généralement classées soit comme des fonctions de contrôle de programme, soit comme des fonctions de tâches spécifiques. Les fonctions de contrôle de programme sont conçues pour fonctionner pour un seul programme. Les fonctions de tâches spécifiques sont soigneusement préparées pour être applicables à divers programmes.

Cela rend les systèmes de conception modulaire, s'ils sont construits correctement, beaucoup plus réutilisables qu'une conception monolithique traditionnelle, puisque tous (ou plusieurs) de ces modules peuvent ensuite être réutilisés (sans changement) dans d'autres projets. Cela facilite également la "répartition" des projets en plusieurs projets plus petits. Théoriquement, un projet logiciel modularisé sera plus facilement assemblé par de grandes équipes, car aucun membre de l'équipe ne crée l'ensemble du système, ni même n'a besoin de connaître le système dans son ensemble. Ils peuvent se concentrer uniquement sur la plus petite tâche assignée.

Histoire

La programmation modulaire, sous la forme de sous-systèmes (en particulier pour les E/S) et de bibliothèques logicielles, remonte aux premiers systèmes logiciels, où elle était utilisée pour la réutilisation du code . Programmation modulaire en soi, avec un objectif de modularité, développée à la fin des années 1960 et dans les années 1970, en tant qu'analogue à plus grande échelle du concept de programmation structurée (années 1960). Le terme « programmation modulaire » date au moins du Symposium national sur la programmation modulaire, organisé à l'Institut de l'information et des systèmes en juillet 1968 par Larry Constantine ; d'autres concepts clés étaient la dissimulation d'informations (1972) et la séparation des préoccupations (SoC, 1974).

Les modules n'étaient pas inclus dans la spécification d'origine pour ALGOL 68 (1968), mais ont été inclus en tant qu'extensions dans les premières implémentations, ALGOL 68-R (1970) et ALGOL 68C (1970), et formalisés plus tard. L'un des premiers langages conçus dès le départ pour la programmation modulaire a été l'éphémère Modula (1975), de Niklaus Wirth . Un autre premier langage modulaire était Mesa (1970), par Xerox PARC , et Wirth s'est inspiré de Mesa ainsi que du Modula original dans son successeur, Modula-2 (1978), qui a influencé les langages ultérieurs, en particulier par son successeur, Modula-3 ( années 1980). L'utilisation par Modula de noms qualifiés par des points , comme M.afaire référence à un objet à apartir de module M, coïncide avec la notation pour accéder à un champ d'un enregistrement (et de même pour les attributs ou les méthodes d'objets), et est maintenant répandue, vue dans C#, Dart, Go, Java et Python, entre autres. La programmation modulaire s'est généralisée à partir des années 1980 : le langage Pascal original (1970) n'incluait pas de modules, mais les versions ultérieures, notamment UCSD Pascal (1978) et Turbo Pascal (1983) les incluaient sous la forme d'« unités », tout comme le Pascal -influence Ada (1980). La norme Extended Pascal ISO 10206:1990 s'est rapprochée de Modula2 dans son support modulaire. Standard ML (1984) possède l'un des systèmes de modules les plus complets, y compris des foncteurs (modules paramétrés) pour mapper entre les modules.

Dans les années 1980 et 1990, la programmation modulaire a été éclipsée et souvent confondue avec la programmation orientée objet , en particulier en raison de la popularité de C++ et Java. Par exemple, la famille de langages C prenait en charge les objets et les classes en C++ (à l'origine C avec Classes , 1980) et Objective-C (1983), ne prenant en charge que les modules 30 ans ou plus plus tard. Java (1995) prend en charge les modules sous forme de packages, bien que l'unité principale de l'organisation du code soit une classe. Cependant, Python (1991) a largement utilisé à la fois les modules et les objets, en utilisant les modules comme unité principale d'organisation du code et les « packages » comme unité à plus grande échelle ; et Perl 5 (1994) inclut la prise en charge à la fois des modules et des objets, avec une vaste gamme de modules disponibles auprès de CPAN (1993).

La programmation modulaire est maintenant répandue et présente dans pratiquement tous les principaux langages développés depuis les années 1990. L'importance relative des modules varie d'un langage à l'autre, et dans les langages orientés objet basés sur des classes, il y a toujours chevauchement et confusion avec les classes en tant qu'unité d'organisation et d'encapsulation, mais ces deux concepts sont bien établis en tant que concepts distincts.

Voir également

Remarques

Les références

Liens externes