mis à jour le : 26/12/2018
(Si l'ontologie existait, ceci en serait l'introduction)
Lois des systèmes
En informatique on observe les lois dynamiques de la nature en accéléré et en miniature
Introduction superficielle
La croissance en complexité est observable dans la suite numérique des atomes de la table périodique, dans la croissance d'une plante, des espèces animales, d'une civilisation, d'une idée qui vient à l'esprit autant que la recherche d'un souvenir, d'un projet, bref de tout accomplissement.
Elle s'exprime par une formule simultanément incrémentielle et multiplicative. toutes les innovations se fondent l'une sur l'autre tout en conservant actives l'usage des précédentes. C'est pourquoi il est souvent dommageable de croire qu'on peut se passer d'une ancienne technologie. Tous les niveaux de complexité coexistent et se répartissent des tâches. Si une technique moderne doit s'occuper des tâches simples en plus des complexes, cela cause une énorme déperdition d'énergie.
Un système est ordonnée comme une sphère allant du npyau, support de la complexité, à la périphérie, qu'occupent des dispositifs simples.
On peut seulement se demander, parmi toutes les évolutions qui conduisent à des échecs, comment se choisis une des seules solutions possibles. Puisque cette question est insoluble (car en haut de tout il y a Dieu, ce qui a créé les fondements) on est réduits à faire des observations statistiques, et à procéder à une réduction des possibilités au moyen de règles. De là naît l'Ontologie des Systèmes, l'ensemble des éléments, composants, procédures, techniques, et divers codes de bonne conduite sans lesquels un système n'en est pas un, dans la mesure où il n'atteint pas son objectif, à savoir d'être fonctionnel.
Avec cette définition on ne peut nommer "système" que ce qui marche, mais ce n'est pas le cas du langage courant, pour lequel ce terme revêt un aspect plus nuancé. En effet un système ne marche jamais que partiellement.
*
Les plus hauts sommets évolutifs sont ceux qui bénéficient du plus grand contrôle sur la structure sur laquelle ils reposent. Cela n'empêche pas que chaque sous-ensemble ait lui-même le contrôle sur les structures antérieures, et dont elles dépendent. Cette opposition entre contrôle et dépendance est une forme de conflit (entre les couches logicielles) dont l'ampleur grandit avec la complexité de l'organisme. Elle reste cependant rien d'autre que rhétorique, et psychologique, car on peut aussi les considérer, non comme des conflits, mais des indices d'une contradiction apparente, qui contribuent ensemble à l'amélioration.
Les différents sous-ensembles fonctionnent avec le meilleur rendement lorsqu'ils sont en harmonie avec leurs constituants et leur contexte. Leurs activations successives n'engendre pas de contradictions. Chaque ensemble ayant une influence sur ses sous-ensembles et ses sur-ensembles (en refusant de relayer une tâche), ils doivent finir par trouver des fonctionnements communs, tout en ne se connaissant pas les uns les autres. C'est ce en quoi on parle d'harmonie, pour des fonctions distantes qui soutiennent conjointement une activité. Ces fonctions sont fragiles et souvent si on y touche on ne sait pas pourquoi un problème apparaît ailleurs.
Les fonctions qui composent une harmonie sont contributives. C'est l'organisation, la structure logicielle qui donne son sens aux fonctions de base. Toute unité n'est qu'une association de sous-ensembles, d'unités. Leurs relations conforment l'unité dont ils font partie. Quand on dit "tout est relatif" on devrait dire "tout est relationnel, l'objet d'un ratio, d'une mise en rapport, d'une division". On peut concevoir l'univers comme la somme de toutes les mises en relation.
*
L'harmonie est un terme d'huilage des rouages d'un système. Parfois on peut la constater dans l'écriture, dans la rigueur de l'architecture, ou dans la régularité et le rythme de la puissance des calculs, tout au long de son exécution. Quand on clique, on doit pouvoir entendre le son du logiciel :)
Au-delà de cet aspect physique, l'aspect systémique du concept de l'harmonie a encore plus d'importance. Pour le comprendre il faut observer la nature, la contribution des gaz rares à la pérennité des organismes, les systèmes d'auto-régulation climatiques, etc... Ne sachant correctement la définir, malgré l'importance dont elle relève, il nous reste à affirmer que l'harmonie est ce que produit le respect le plus scrupuleux et efficace de la topologie des systèmes, dont la présente ontologie est le vocabulaire. (De cette manière il nous reste à adapter notre ontologie en conséquence des découvertes).
Il reste un dernier aspect à l'harmonie, qui est sa capacité à anticiper les évolutions futures (design intelligent). Cette « magie » semble rendue possible par le respect de lois qui appartiennent à des sur-ensembles très lointains, et qui doivent encore être fabriqués. C'est comme si on avait un écho d'un accomplissement futur, exactement comme quand calcule mentalement que 354*256 est supérieur = 10000. D'une certaine manière on a accès à une connaissance qui nous dépasse. Ces lois ne sont pas dictées mais indéniablement réelles. C'est à dire que existence s'exprime par une transcendance et une influence physique au second degrés. C'est à dire que leur non-respect n'est pas puni, mais les conséquences logiques s'en chargent elles-mêmes.
Ces lois semblent avoir de la vénération pour le chemin évolutif qui les a faites. C'est pourquoi elles tiennent à ce que les bons choix soient commis pour de bonnes raisons, qui sont immédiatement possibles à acquérir par la seule logique. Cependant il est également « logique » qu'il y ait des interférences à cause des dysharmonies.
Les lieux d'un logiciel qui semblent un summum de perfection relève d'un excellent rapport entre la capacité, le potentiel et la simplicité. Ils appartiennent nécessairement à un niveau de complexité considéré comme élevé, tout en offrant une grande souplesse évolutive. Ce sont des lieux qu'on peut adorer explorer comme les ruelles d'une belle ville.
L'inspiration qui guide le développement en complexité conduit à la conclusion que les meilleurs choix ont été antérieurement faits alors même qu'on l'ignorait. Pour atteindre cela il y a des règles de base :
- toujours garder à jour les ensembles qui pourraient bénéficier d'une nouvelle technologie, processus, dispositifs, ou éléments de noyau.
- ne pas hésiter à décliner des fonctions classiques génériques en fonctions propriétaires paramétrables, mais dans une très grande limite (une à deux fois). Sinon la fonction générique devra s'enrichir. Souvent le rapport d'usage des fonctions génériques et déclinées est le suivant : 80% de la masse de travail sur la fonction déclinée (simplifiée, optimisée), et 80% des usages (nombreux, variés, périphériques et potentiels) sur la fonction générique.
- toujours diviser au maximum les tâches. Une fonction ayant obtenu un double usage en génère trois : une générique et deux applications. Toutes les fonctions doivent servir le plus possible.
- se laisser guider par l'inspiration du moment ; ne pas oublier les idées non concrétisées. Ce sont ces dernières qu'on peut voir soudainement apparaître, un jour, au détour d'une simple jonction, alors que précédemment ce n'était qu'une utopie.
- toujours répondre aux problèmes du jour immédiatement, comme si c'était l'accomplissement de la meilleure destinée :)
- ne pas hésiter à occasionner des réformes majeures, quand le plaisir de la complexification commence à s'amenuiser, à cause des tâches lassantes.
- ne pas hésiter à uniformiser les protocoles, et donc, à être créatif et adaptatif dans la création de protocoles. En terme général on peut d'ores et déjà délimiter leur portée en fonction de leur poids, flexibilité, facilité de compréhension. Ces familles doivent orienter les uniformisations de protocoles (complexification puis simplification).
*
Tout logiciel est entropique dans un milieu évolutif : il a besoin d'une maintenance. Parfois une seule évolution peut engendrer des années de maintenance.
Mais aussi tout logiciel doit survivre, en explorant les limites de sa complexité, quitte à se réformer. Pour cela il doit profiter du temps libre occasionné par les succès de la maintenance, ainsi que les évolutions esthétiques, ou de commodité. C'est seulement le potentiel dégagé par la maîtrise de l'existant qui permet la créativité.
Toute réforme vise à dégager le potentiel de l'existant, dit aussi l'horizon évolutif.
Et toute innovation n'a que le succès qu'elle mérite. Il est contre-productif de réformer quelque chose qui marche bien et qu'on maitrise déjà. Le potentiel créatif n'a pas vocation à tout régenter, seulement à proposer des voies évolutives emplies de promesses.
Le succès d'une innovation se mesure à son aspect indispensable, à la quantité des processus qui en dépendent.
En fin de compte le schéma noyau-couches est lui-même reproduit dans les composants d'une couche. Seuls les noyaux les plus bas peuvent se vanter d'être inexpugnables.
Les noyaux d'une activité d'une couche logicielle peuvent devenir membre de la librairie globale s'ils deviennent utilisables par d'autres processus. C'est tout le succès qu'on leur souhaite, et ça allège le processus d'où il est natif. C'est ainsi seulement qu'on garanti que toute innovation est un bon investissement. (Notez en passant que l'apanage des frameworks est de créer une somme d'actions typiques alors qu'aucune, ou très peu, seront utiles au final).
*
Les composants des couches ont une vocation innée, avec leur complexification, à obtenir leur indépendance en tant que système.
Dès leur naissance, elles doivent être considérées comme optionnelles, désactivables.
Elles doivent en premier lieu bénéficier des procédures et protocoles existants.
Quand un composant devient indispensable hors du système où il a été créé, il peut acquérir sa propre autonomie en tant que logiciel. C'est à ce moment-là qu'on est contents d'avoir passé son temps à optimiser et maximiser les fonctions du noyau, car voilà alors qu'il devient une dépendance de son logiciel.
Comme dans le cas qu'on a vu, où une fonction en devient trois, l'indépendance d'un composant signe l'indépendance du noyau. Il devient une référence, consultable par exemple dans une API. Et tout le reste du logiciel est tenté d'en faire autant.
Cette première séparation inaugure une nouvelle architecture logicielle, faisant que les parois entre les composants deviennent de plus en plus étanches.
C'est ainsi que la naissance d'une cellule peut influencer les autres par voie systémique, alors qu'elles n'ont pas besoin d'être modifiées, en apparence.
*
Tout logiciel, en plus d'engendrer une entropie qui permet la néguentropie comme nous l'avons vu, exerce une pression temporelle. C'est la notion d'harmonie qui en est la cause. Il arrive souvent que pour être résolus, des problèmes supposent la résolution d'autres problèmes (et ainsi de suite) jusqu'au point où il faille d'abord résoudre le premier problème. Cela est dû à la nature des logiciels, nature qu'on peut supposer en observant que leur exécution n'est pas linéaire.
(par exemple)
Avant de continuer il faut faire un détour vers les systèmes de Boot. Au démarrage du logiciel, comme du système, comme de l'ordinateur, (comme le fait de créer des ordinateurs...) il faut s'affranchir de contradictions temporelles. En particulier il faut lire pour exécuter et exécuter pour lire. Les systèmes de boot sont des sous-systèmes qui chargent un paramètre, qui chargent une exécution, qui chargent des librairies et des paramètres, qui chargent des systèmes, des librairies et des paramètres, qui permettent l'exécution du logiciel dans sa phase par défaut.
Grâce à une mise en cache on garde le statu initial en mémoire de sorte à s'épargner de refaire tout ce processus à chaque exécution du logiciel.
(de la même manière)
La structure des logiciels n'est pas linéaire, mais modale.
L'exécution du code consiste en une arborescence d'activités. Cette arborescence est le fruit du paramétrage, qui est essentiellement automatique, et occasionnellement libre.
Il peut arriver que les données produites ne correspondant pas aux données attendues, en terme d'emplacement ou de type attendu.
Ce sont des sous-systèmes, ou systèmes satellites (comme des éléments de noyau mais chargés sur demande) qui se chargent de les accorder. En effet il n'est pas toujours possible de prévoir toutes les combinaisons d'activités du logiciel, même si en général les choses impossibles sont rendues interdites. Ces sous-systèmes sont délocalisés, éparpillés. On n'en voit que quelques fragments ici et là. Il permettent une validation a priori, et peuvent engendrer des paramétrages à la volée juste avant l'assemblage, qui est prévenu de ces cas de figure.
Ainsi on peut dire qu'entre les parties étanches des composants se situent des éléments pré-mathématiques, qui opèrent simultanément depuis différents lieux.
(On peut définir un mauvais logiciel comme étant exclusivement l'adjonction séquentielle de ces éléments inconsistants On y constatera des créations et destructions qui semblent inutiles. En outre, tout élément périphérique du logiciel, en phase de prototype, ressemble à cela).
Ainsi il arrive souvent que, dans l'Ontologie des systèmes, l'on fasse référence à des caractères qui n'ont pas encore été définis.
*
Quelques préceptes
Tout chantier doit rester à taille humaine
- On appelle « le sizing » le fait de dimensionner correctement l'application à ses besoins uniquement. Cela implique deux choses contradictoires, déléguer au maximum (pour augmenter le potentiel évolutif), et réduire au maximum la complexité du code périphérique (en périphérie du système) de façon à ce qui n'aie que l'utilité demandée.
- Ce genre de loi peut faire que certaines fonction très génériques et apparemment très utiles, n'ayant jamais eu à être utilisée, n'existe pas. Réciproquement si une fonction du noyau est inexistante, c'est que le potentiel pour l'émuler est suffisant.
La complexité
- Le rapport entre quantité et complexité doit préserver une dimension humaine. Il n'est autant pas possible de gérer une trop grande quantité qu'une trop grande complexité. En toute logique les choses répétitives doivent être généralisées, en commençant par celles qui occasionneraient la plus grande économie (de place, de temps d'exécution ou de temps de maintenance).
- C'est pourquoi il n'est pas urgent de régenter les fonctions périphériques. Elles doivent rester souples et faciles à comprendre.
- L'ensemble d'un logiciel est généralement composé de n grandes tâches, elles-mêmes et additionnellement à n² sous-tâches (et ainsi de suite), dont les dernières font référence au noyau.
- On peut nommer distinctement ces couches logicielles, par exemple, (et respectivement) les assembleurs, les constructeurs, et les générateurs (de flux de données).
Dans le graphique suivant on peut voir la composition de 3 niveaux de complexité (G=grande tâche, S=sous-tâche, N=noyau) :
GSN
SN
N
Note : ce sont ces niveaux qui, confusément, ont donné lieu au terme MVC, en associant à chacun un niveau d'expertise approprié (les débutants en haut, les architectes en bas, laissant au débutant la possibilité de toucher les quelques éléments du noyau, et des assembleurs qui les concernent). La couche intermédiaire est elle aussi bien connue, c'est celle des paramétrages (qui servent a toute une somme de professions).
L'optimisation
- On appelle « la densité du code » le fait d'obtenir que chaque fonction soit utilisée le maximum de fois (maximisée).
- Etant donné la large part de temps d'exécution consacré à la seule lecture du code, l'optimisation incluse également le fait de supprimer toutes les lignes et caractères inutiles. 40% de code en moins c'est 30% de vitesse d'exécution en plus.
- L'ensemble des règles de la topologie des systèmes relèvent de l'optimisation. C'est le facteur primordial de la néguentropie, c'est à dire la vocation du vivant, et l'acquisition de la maitrise.
dav