👴 🍬 👩‍🎤 La programmation est la matérialisation des idées. 😻 🕟 🕥

La thèse principale de cet article: Le développement logiciel doit être considéré comme la matérialisation des idées par la transformation de modèles mentaux en code programme.
L'article décrit le paradigme de la matérialisation des idées en génie logiciel (anglais: RPSE: Reification as Paradigm of Software Engineering).

Version anglaise de l'article: RPSE : Reification as Paradigm of Software Engineering . L'abréviation RPSE est utilisée plus loin dans le texte pour indiquer le paradigme décrit.

Définitions clés

Avant de procéder à une discussion des principaux points de cet article, il est nécessaire de s'entendre sur la signification des termes de base qui y sont utilisés.

Génie logiciel

Par génie logiciel, nous entendons la définition classique de la discipline de génie logiciel du dictionnaire IEEE [1]: Le génie logiciel est «l'application d'une approche systématique, disciplinée et quantifiable au développement, à l'exploitation et à la maintenance des logiciels».

Paradigm

Le terme paradigme utilisé dans cet article est basé sur la définition classique du paradigme Thomas Kuhn [2]: Un paradigme est un cercle de problèmes, un ensemble de concepts, des règles et des lois généralement acceptées, des méthodes pour résoudre des problèmes dans un certain domaine scientifique.

Plus sur les paradigmes

Pour déterminer plus précisément le concept de paradigme utilisé ci-dessous, il est utile de citer deux citations bien connues du livre de Kuhn:

Par paradigmes, j'entends des réalisations scientifiques reconnues qui donnent depuis un certain temps à la communauté scientifique un modèle pour poser des problèmes et leurs solutions ...

En introduisant ce terme, je voulais dire que certains exemples généralement acceptés de la pratique réelle de la recherche scientifique - des exemples qui incluent le droit, la théorie, leur application pratique et l'équipement nécessaire - nous donnent tous ensemble des modèles dont découlent des traditions spécifiques de la recherche scientifique.

Le dualisme de ce concept réside dans le fait que, d'une part, le paradigme se caractérise par une communauté de spécialistes qui le reconnaissent. Ce sont les spécialistes d'un certain domaine qui déterminent, créent et développent ses pièces. D'un autre côté, la reconnaissance d'un certain paradigme signifie pour un spécialiste qui rejoint une telle communauté.

Thomas Kuhn a considéré les paradigmes scientifiques dans son livre. Cependant, très peu de temps après la sortie de la première édition du livre, l'utilité d'utiliser ce concept dans la technologie et divers domaines de la vie sociale est devenue évidente. À cet égard, de nombreuses publications sur les paradigmes et leur évolution dans l'industrie automobile, l'urbanisme, le traitement de certaines maladies, etc. ont commencé à apparaître dans la littérature spéciale et populaire.

Le génie logiciel et en particulier son composant important - la programmation, ne faisaient pas exception. Il existe actuellement de nombreux paradigmes de programmation concurrents. Un article séparé sur Wikipedia [3], ainsi que des critiques intéressantes comme [4], sont consacrés à leur énumération.

À propos des limites des paradigmes de programmation

Les auteurs des paradigmes décrits dans [3] et [4] se concentrent sur un sous-domaine étroit du génie logiciel, à savoir l'écriture de programmes dans un langage de programmation particulier. Je pense que de nombreux professionnels s'accordent à dire que de vrais projets logiciels ne peuvent pas être réalisés dans le cadre d'un seul de ces paradigmes (par exemple, la programmation fonctionnelle).

Le paradigme décrit dans cet article, en revanche, est applicable à une grande variété de domaines et de phases de développement de logiciels.

Sur les limites des paradigmes de gestion de projets logiciels

Certains auteurs, par exemple, dans la revue [5], nomment diverses approches ou modèles d'organisation et de conduite de projets logiciels comme paradigmes. Par exemple, les modèles en cascade, les modèles en V ou les modèles agiles sont comparés. Il est peu probable que ces approches, contrairement aux paradigmes de programmation mentionnés ci-dessus, puissent être appelées paradigmes dans l'esprit de la définition de Kuhn en raison de leur relative simplicité théorique et de l'absence d'une large base théorique.

Le paradigme proposé dans cet article n'a pas encore sa propre base théorique développée, mais aujourd'hui ses voies de développement sont déjà visibles.

Matérialisation des idées

Le terme matérialisation des idées (anglais: réification ) utilisé dans cet article est une extension de la définition classique de la réification en informatique: «La réification est le processus par lequel une idée abstraite d'un programme informatique est transformée en un modèle de données explicite ou un autre objet créé dans un langage de programmation» [6].

En savoir plus sur le monde des idées, le monde des choses et la matérialisation

L'essence de l'élargissement de la définition classique du concept de matérialisation utilisé dans cet article peut être définie comme suit.

Déjà dans les premiers tracts philosophiques qui nous sont parvenus, il était de coutume de comparer l'Idéal (le monde des idées) avec le Matériau (le monde des choses).

Nous pouvons ressentir l'idéal au mieux (ou penser que nous le ressentons). Un indicateur d'une telle sensation de l'idéal peut être un changement d'humeur ou de pensée après avoir écouté un morceau de musique, un fragment lu d'un livre, etc. Bien sûr, je veux dire l'effet indirect, par exemple de la musique, sur notre conscience, et non la subordination physiologique primitive du corps au rugissement d'un concert de rock ou au rythme d'une discothèque.

Les tentatives de formuler notre sens de l'idéal en règle générale ne mènent pas au succès.
Le grand poète russe Fedor Ivanovich Tyutchev l'a remarquablement remarqué:

Comment le cœur s'exprime-t-il?
Comment vous comprendre autrement?
Comprendra-t-il comment vous vivez?
La pensée prononcée est un mensonge ... [7]

Même des idées pratiques telles que des réparations mineures dans la maison ou la préparation d'une nouvelle variante d'un plat familier sont difficiles à formuler au début. Et seulement après délibération ou tentative d'explication à l'autre, l'idée prend des «contours» de plus en plus clairs.

Passons maintenant de l'examen du concept de l'Idéal à celui du Matériau. Nous pouvons détecter et enregistrer les objets matériels autour de nous, pour distinguer qualitativement leurs propriétés. Les propriétés de nombreux objets peuvent être mesurées objectivement. Nous pouvons également identifier objectivement les hiérarchies et autres structures d'objets matériels.

Pour évaluer ou mesurer (pour obtenir des caractéristiques quantitatives), il n'est pas nécessaire d'avoir un article. Il suffit d'avoir son modèle. De plus, dans de nombreuses situations pratiquement intéressantes, le modèle peut être utilisé sans objet. Les modèles peuvent être discutés avec d'autres. Des modèles peuvent être négociés. Les modèles peuvent être standardisés (formalisés).

Dans certains domaines de l'activité humaine, la normalisation des modèles est allée si loin que les pièces (par exemple, les boulons filetés) fabriquées sur la base d'un modèle standardisé (par exemple, un dessin) par différentes personnes ou mitrailleuses seront indiscernables d'un point de vue technologique.

Réalisant l'inexactitude relative de la définition proposée, plus loin dans cet article, je diviserai le monde des phénomènes de notre monde intérieur et extérieur U en deux parties:

U = M + I

où l'ensemble M consiste en leurs phénomènes qui peuvent être objectivement enregistrés ou mesurés (monde matériel) et I - tout le reste.

Que cette formule soit applicable à absolument tous les phénomènes du monde qui nous entoure est une question philosophique ouverte. Plus loin dans cet article, nous réduisons la portée de cette formule au monde des phénomènes du monde du génie logiciel.

Ou, en le formulant comme une thèse: l'ensemble des phénomènes liés au génie logiciel peut être divisé en un sous-ensemble de l'idéal et un sous-ensemble du matériau. De plus, les phénomènes matériels sont enregistrés ou mesurés en fonction de leurs modèles.
Le processus de création ou de modification d'un système logiciel se termine dans la plupart des cas par la création de l'un ou l'autre code qui, à l'aide d'un ordinateur, est affiché dans un processus physique (phénomène réel).

Ce processus commence par l'émergence de certaines idées sur le futur système dans l'esprit des clients ou des développeurs. Nous appellerons ces idées et ces idées un modèle mental .

À propos des modèles intermédiaires

Dans les systèmes simples ou avec de simples ajouts / modifications à de grands systèmes, le développeur écrit immédiatement du code ou configure le système en fonction de son modèle mental. Cependant, dans la plupart des cas, des modèles intermédiaires de complexité et de niveau de formalisation différents sont créés - d'une simple liste d'exigences à des modèles formels étendus (par exemple, des modèles UML ou BPMN).

Matérialisation des idées dans les domaines adjacents au génie logiciel

Il est clair que la définition ci-dessus n'est pas radicalement nouvelle et est largement utilisée (consciemment ou inconsciemment) dans les domaines du travail intellectuel adjacents à la programmation. Par exemple, considérons deux de ces domaines - le génie mécanique et les mathématiques.

Ces deux domaines utilisent la matérialisation des idées depuis longtemps et efficacement. Ils ont beaucoup à apprendre sur la programmation à cet égard.

En génie mécanique, nous voyons un cycle complet de la matérialisation des idées - de l'émergence d'une idée dans la tête du concepteur à travers sa réflexion, le détail, la cartographie dans un modèle, et enfin - la fabrication à partir d'un certain matériau.

La situation est différente en mathématiques.

Sur la matérialisation des idées en mathématiques

Des faits intéressants et des considérations concernant la matérialisation des idées en mathématiques peuvent être trouvés au paragraphe 7.3 du livre [8].

Le «produit final» des mathématiques est des modèles formels aux propriétés strictement éprouvées.

De ce point de vue, la programmation est au milieu. Cela peut être représenté graphiquement comme suit:

Ainsi, les mathématiques utilisent un plus grand nombre de modèles plus abstraits et ne s'appliquent presque pas au domaine des modèles extrêmement spécifiques tels que les dessins techniques.

Le génie mécanique, au contraire, utilise relativement peu de modèles abstraits, mais de nombreux modèles spécifiques. Par exemple, ceux pour lesquels des objets physiques peuvent être fabriqués sans ambiguïté.

De ce point de vue, la programmation est au milieu.

Pourquoi la programmation est-elle au milieu?

Le produit de programmation final est le code logiciel. Et bien que lorsqu'il est exécuté sur du matériel, il soit mappé à des objets physiques spécifiques (signaux électriques et champs de nature physique variée), ces objets sont difficiles à comparer avec les écrous, les engrenages et les carrosseries de voitures. En revanche, le code du programme est proche des formules mathématiques, et parfois c'est leur réflexion directe. Cependant, dans tout système logiciel réel, vous devez prendre en compte de nombreux aspects spécifiques de l'environnement et de l'interaction avec les utilisateurs ou d'autres systèmes. Cela rend le code de programme plus spécifique que les formules mathématiques.

Ce que le génie logiciel peut apprendre des régions voisines en termes d'utilisation de modèles

Considérez d'abord les mathématiques.

Multimodèle du monde

Pendant plusieurs milliers d'années de son développement, les mathématiques ont appris à décrire les mêmes phénomènes du monde réel ou imaginaire en des termes très différents. Les anciens Grecs ont appris à remplacer les descriptions purement verbales des tâches par des figures géométriques et à résoudre avec leur aide des problèmes pratiquement importants. Plus tard, une compréhension est apparue de l'interchangeabilité des segments sur le plan et des nombres. Puis le concept d'une variable algébrique et la réduction des problèmes géométriques aux systèmes d'équations algébriques se sont cristallisés.

Aujourd'hui, les élèves du secondaire savent déjà que le même problème peut être résolu de différentes manières (par exemple, géométriquement ou algébriquement) et que le même modèle mathématique, par exemple, une équation algébrique, décrit de nombreux différents physiques, chimiques, etc. phénomènes.

Morphisme des modèles et cohérence des concepts et notations

Les mathématiques ont bien appris non seulement à décrire les mêmes objets et processus réels ou imaginaires à l'aide de modèles de nature mathématique très différente. Une réalisation importante des mathématiques est la capacité de déterminer le degré de similitude des modèles de différentes branches des mathématiques, ainsi que la capacité de les transformer les uns en les autres. De nombreuses solutions révolutionnaires aux problèmes mathématiques les plus importants de ces dernières années sont essentiellement des chaînes de preuves distinctes, chacune utilisant un appareil spécialisé d'une section spéciale des mathématiques. À la jonction de ces preuves hautement spécialisées, les mathématiques transforment habilement les modèles d'une section de mathématiques en modèles d'une autre section. En programmation, quelque chose de similaire se produit maintenant lors de la compilation du code source d'un programme et lors de la génération de code à partir de DSL (Domain Specific Language) ou de métadonnées. Mais la culture de travailler avec des modèles dans le domaine du génie logiciel est loin derrière la mathématique.

Modèles en génie mécanique

Et que peut apprendre le génie logiciel de la matérialisation en ingénierie?
Dans de nombreuses industries, et même au sein de grandes entreprises, il existe des chaînes de modèles formels et semi-formels coordonnés. Ces chaînes se terminent par des modèles, sur la base desquels des objets physiques sont fabriqués et montés - des appareils et des machines. En règle générale, pour la plupart des types de modèles intermédiaires, il existe des méthodes formelles pour vérifier leur exactitude (normes techniques). Les modèles sont le principal langage de communication des spécialistes de différents profils dans le processus de conception et de fabrication de produits d'ingénierie.

Dans ce contexte, la situation informatique semble bien pire. Ce n'est qu'au cours de très grandes préoccupations informatiques ces dernières années que l'on a tenté de construire des ensembles comparables de modèles et de processus. Les petites entreprises et les startups informatiques, en règle générale, non seulement n'ont pas développé de modèles et de processus formels, mais ne soupçonnent même pas leur existence. Cette situation est actuellement déterminée par les facteurs suivants:

Le manque d'efficacité des modèles et processus existants
Le manque de notoriété de ces modèles en dehors des grandes préoccupations
Formation inadéquate pour les développeurs et en particulier les gestionnaires
L'arriéré de l'enseignement universitaire par rapport aux besoins réels du génie logiciel.

Définition et contours du paradigme de la matérialisation des idées (RPSE)

Nous avons identifié tous les concepts nécessaires pour donner une définition de base du paradigme proposé. Le voici:

Le développement logiciel est la matérialisation des idées par la transformation de modèles mentaux en code exécuté sur ordinateur.

Dans le cadre du paradigme proposé:

Tous les principaux processus de développement logiciel sont des variantes spécifiques (implémentations) du processus de construction de chaînes de modèles mentaux et matériels. Le dernier modèle le plus spécifique de cette chaîne est, en règle générale, le code de programme.
L'essence du développement logiciel est de créer de telles chaînes.
Tous les principaux enjeux de l'optimisation du développement, de la réduction de son coût et de l'amélioration de sa qualité peuvent être réduits à l'optimisation de la construction de la chaîne de modèles correspondante.

Pourquoi la matérialisation et non la modélisation?

A noter que bien que la définition de RPSE se réfère à la construction de chaînes de modèles, il est néanmoins proposé d'appeler la matérialisation du paradigme plutôt que la modélisation. Ainsi, on cherche à souligner la particularité des chaînes de modèles qui deviennent de moins en moins abstraits / idéaux et de plus en plus concrets / matériels.

La définition ci-dessus a ses propres caractéristiques et variations dans différents domaines du génie logiciel. Ce n'est que dans un très petit nombre de cas que, dans la tête d'un programmeur, une idée claire de la façon de résoudre la tâche avant lui est complètement mûrie, qu'il traduit ensuite en un code de langage de programmation en peu de temps. Dans la plupart des projets du monde réel, le processus de recherche d'une solution et sa mise en œuvre coexistent, se développent en parallèle et interagissent les uns avec les autres. C'est-à-dire les modèles mentaux, le code et souvent les modèles intermédiaires (sous forme de test, les images, les modèles formels tels que UML) grandissent et changent en parallèle, s'influençant mutuellement.

Options de définition

Très souvent, plusieurs personnes travaillent sur un problème en même temps. Chacun d'eux a son propre modèle mental et, éventuellement, ses modèles intermédiaires et ses fragments de code.

Souvent, le code dans certains langages de programmation est pratiquement absent, car la création d'une nouvelle solution revient à gérer les masques des configurateurs ou des générateurs, comme lorsque vous travaillez avec des outils de développement dans des systèmes tels que SAP ou WebSphere.

Les options pour transformer du code écrit manuellement ou généré automatiquement en code exécutable sont également devenues très diverses de nos jours.

Et enfin, le concept même du processeur sur lequel le code est exécuté s'est également considérablement développé ces dernières années. Si auparavant c'était des processeurs qui étaient sur les cartes, qui à leur tour ont été insérés dans les coques des ordinateurs de bureau, des ordinateurs portables et des racks de serveurs, maintenant cet ensemble a été élargi par diverses puces de différentes tailles qui sont intégrées dans les téléphones mobiles, les consoles de jeux, les caméras de surveillance, " appareils électroménagers intelligents, etc. Sans parler des ordinateurs quantiques.

Néanmoins, le RPSE, en raison de sa généralité, est applicable à tous les domaines énumérés ci-dessus.

Que peut-on dire d'autre à propos d'un certain paradigme aujourd'hui, est-il possible de décrire plus précisément ses contours?

La prochaine étape pour affiner le paradigme après avoir essayé de donner sa définition principale est une tentative d'énumérer les principales catégories de phénomènes qu'il affecte. Rappelant la définition de Kuhn, nous devons essayer de lister les types de modèles que RPSE introduit et utilise.

Les modèles RPSE peuvent être divisés en trois catégories principales:

Modèles mentaux
Code dans les langages de programmation ou ses équivalents comme modèles de code exécutable.
Modèles intermédiaires.

Les modèles les moins explorés dans cette triade sont les modèles mentaux. Qu'entend-on exactement par eux?

Les modèles mentaux sont un terme pour des idées qui existent dans la tête des clients, des programmeurs et des autres participants au processus et sur la base desquelles le code exécutable émerge finalement. La présence de tels modèles est incontestable et peut être enregistrée au niveau mental, par exemple par le programmeur lui-même.Au niveau actuel de développement technologique, ces modèles ne peuvent pas être mesurés de manière fiable par des instruments.

L'un des moyens efficaces de fixer et de mesurer de tels modèles est d'utiliser le support de l'idée. De toute évidence, le processus d'entrevue ou des processus similaires affectent considérablement le modèle mental lui-même. Chacun de nous doit avoir vécu plus d'une fois une situation où une tentative de formuler un problème afin de consulter un collègue seul a conduit à une «perspicacité», et souvent à une solution au problème.

L'entretien permet, sur la base de questions correctement formulées, de construire de manière relativement objective des modèles de complexité variable. Les plus courants sont
les suivants: Modèles structurels:

Répertorie les valeurs binaire, énumération, numérique, chaîne et autres.
Graphiques et structures de données réseau

Modèles de description comportementale:

Modèles sept formels pour déterminer le comportement
Modèles formels pour déterminer le comportement (par exemple, machines à états finis)

Sur la théorie des modèles mentaux

Ces schémas reflètent les schémas mentaux. Le degré de proximité des modèles mentaux avec les modèles réels devrait être traité par la psychologie ou la pédagogie théorique. Malheureusement, l'auteur n'a pas connaissance d'un travail sérieux dans ce domaine. (Cela ne signifie pas qu'un tel travail n'existe pas).

Pourquoi le génie logiciel a-t-il besoin d'un paradigme de bout en bout?

La présence d'un paradigme «transversal» ouvre les possibilités suivantes aux participants utilisant le paradigme du processus de création, de modification et d'utilisation du logiciel:

La possibilité pour tous les participants au processus d'utiliser la même terminologie.
La capacité de construire un processus de bout en bout de création de nouveaux logiciels.
La capacité d'évaluer ses paramètres de processus, ses résultats intermédiaires et de les gérer.

Les principaux objectifs du développement du paradigme

Problèmes théoriques

Comme cela a été noté à plusieurs reprises, y compris dans le livre de Kuhn [2], dans la plupart des cas, les scientifiques sont impliqués dans la résolution des problèmes potentiels qui sont résolus, et ils sont moins susceptibles de s'attaquer à ceux dont l'approche n'est pas très claire. Mais ce sont exactement nos tâches. En voici les principaux:

Définition constructive du concept de modèle mental.
Trouver des critères constructifs pour évaluer le degré d'abstraction / d'idéalité par rapport à spécificité / matérialité des modèles.
Recherche de critères de sélection des candidats pour le rôle de modèles intermédiaires et supplémentaires.
Sélection et développement de critères et de méthodes pour comparer des modèles de différents types, y compris leur traçage direct et inverse.
Développement de méthodes de transformation automatisée et automatique de modèles.

Tâches pratiques

Parallèlement aux tâches théoriques pour le développement et la mise en œuvre du paradigme décrit dans la pratique du génie logiciel, il est nécessaire de résoudre au moins les problèmes pratiques suivants:

Création d'outils pour: a) Extraction et fixation de modèles mentaux. b) Transformation automatisée et automatique des modèles mentaux en modèles intermédiaires. c) Traces et estimations des changements dans le contenu des modèles transformables
Création de la documentation technique et pédagogique nécessaire et d'autres matériels pédagogiques internes.
Organisation de forums et conférences sur ce sujet

Conclusion

Cet article tente de définir le paradigme du génie logiciel comme la matérialisation des idées. Le mot définir (et non ouvert) n'est pas utilisé ici par hasard. En fait, les participants aux projets informatiques sont depuis longtemps engagés dans la création, la transformation et l'utilisation de modèles, peut-être sans s'en rendre compte.

Au sens strict de la définition de Kuhn, l'approche décrite jusqu'à présent ne peut pas revendiquer le droit d'être appelé un paradigme, mais seulement un candidat pour un paradigme, car il n'a pas une vaste communauté de personnes qui le soutiennent et aussi un système développé de modèles interconnectés. Cependant, je veux croire que les lacunes seront bientôt surmontées.

Il s'agit du premier article d'une série d'articles prévue. Dans les articles suivants, je vais parler des modèles mentaux et intermédiaires.

Littérature

1. Glossaire standard IEEE de terminologie du génie logiciel, IEEE std 610.12-1990, 1990.
2. Kuhn, Thomas S. The Structure of Scientific Revolutions. 3e éd. Chicago, IL: University of Chicago Press, 1996.
3. Paradigme de programmation: en.wikipedia.org/wiki/Programming_paradigm (état - 27/08/2018)
4. Peter A. Henning, Holger Vogelsang Taschenbuch Programmiersprachen. Carl Hanser Verlag GmbH & Co. KG; Auflage: 2., neu bearbeitete (5. septembre 2007). ISBN-13: 978-3446407442.
5. Paradigmes et modèles de génie logiciel Essai sur les technologies de l'information
www.uniassignment.com/essay-samples/information-technology/software-engineering-paradigms-and-models-information-technology-essay.php (état - 08.28.2018 )
6. Réification (informatique) en.wikipedia.org/wiki/Reification_ (computer_science) (état - 27/08/2018)
7. Fedor Ivanovich Tyutchev. Silentium! (Silence (lat.), 1829.
8. Borovik, Alexandre. Les mathématiques au microscope: notes sur les aspects cognitifs de la pratique mathématique. American Mathematical Society. ISBN-13: 978-0821847619.

Illustration: geralt

La programmation est la matérialisation des idées.