en cours de redactions, évolution

introduction

Pour simuler des individus comme par exemples des animaux, des plantes, des personnages, ou meme des lieux, des planetes, des mondes virtuels, mais aussi par ailleurs des programmes, nous avons évidement detecter tres tot dans le projet la nécéssité de devoir les programmer, c'est a dire modéliser les comportements sous une forme logicielle. Naivement au départ sous forme de code et de données. Je dis naivement, mais c'est un point de vue d'aujourd'hui. A l'époque c'etait la seule approche accessible.

Cette modélisation des comportements et son adaptation en modèles informatiques sont également des concepts fondamentaux dans le domaine de la programmation informatique quand on les regardes de pret d'un point de vue sens.

L'idée générale derriere un programme, pour les plus néophites, consiste à représenter les comportements attendu avec des éléments d'un programme ( par exemple les procedures logicielle et les données stockées). On découpe les programmes pour les rendre plus comprehensibles, par exemple à l'aide de composants et de petite procedures qui savent faire des choses uniques et simples et dont la syntaxe est souvent lié a la sémantique de ce que l'on traite, plusieurs modeles existent (par exemple la programmation procedurale, objet, fonctionnelle, et il y en a quelques autres).

Plus de detail dans la section [Les grands concepts permettants d'aborder la partie comportementale] (ci apres)

Les grands concepts permettants d'aborder la partie comportementale

Qu'est ce qu'un programme:

Dans le domaine informatique, je décrirais simplement un programme comme cela :

Un programme est une suite, pas nécéssairement lineraire, c'est a dire un graphe, de comportements qui viennent changer l'état d'un systeme en fonction des contraintes que l'ont observe depuis ledit programme.

Methode

Afin de concevoir l'ensemble des informations et des processus qui interagissent avec les données et les acteurs (tel que les utilisateurs, mais sans se limiter a eux) il existe des methodes, au dela de l'algorithmie et des proposisions des langages de programmation. (par exemple merise, uml, UP) Ces methodes permettent de modeliser des ensembles complexes d'activités des programmes, jusque dans la maniere de documenter afin de partager une lecture ou une expression du comportement des programmes; cela au dela de l'aspect technique de la syntaxe du code.

Partage de procédé

Un autre aspect, il existe un grand nombre de manieres de faire chaque comportement. Fort heureusement certains sont à considérer largement réutilisables. Comme des manieres de faire ont deja été étudiées et sont applicables, applicables en tant qu'ensemble coherent permettant de réaliser des activités particulieres afin de gagner du temps, un programmeur ou un concepteur se doit d'envisager de les utiliser quand il distingue l'oportunité dans la conception. Cela demande tout de meme deux choses: les connaitres ou les chercher, et voir que le probleme a resoudre corresponds bien au sujet!). Les grands types au dela des programmes eux meme, sont les librairies par exemple : lombok, log4j, guava, etc. , mais aussi les design patterns (par exemple le visiteur, le decorateur, la facade, etc. ). Pour répondre au sujet il ne faut oublier qu'une partie du monde c'est tourné ou est en train de se tourner vers la notion de services, puis micro service. [ ndlr: Il semble avéré(je ne sais pas si des études formelle existent) que ces modeles ajoutent un degré non négligeable de consomation énergetiques, et a étudier ulterieurement]

Risques et incertitudes lié au futur.

On constate que les projets de logiciels, qui évoluent pour s'adapter a des nouvelles demandes, arrivent presque systematiquement a des difficultés (comprendre cout/temps/bug) de maintenances, d'évolution. En bref, une mort lente que l'on peut annoncer des l'idée de presque tout les projets logiciels. Il s'agit de l'incapacité initiale a embrasser une forme d'incertitude que je vais tenter de définir mieux. Cette incertitude dans ce cas peut etre désigné comme un risque (voir les travaux de frank knight) est accepté implicitement, voir occulté. Personne aujourd'hui n'ignore qu'on a toujours vu dans le passé des technologies arrivant (nouvelle, ou non vues), qui auraient pu etre utilisées et fait gagner du temps, bref déporter des besoins de travail aujourd'hui ou demain[maintenance?]. Mais, naivement du coté de l'investisseur [en temps, en argent avec un patron ou un client] comme on ne sait pas, on n'investit pas dans cette direction flou. Je pense que c'est une erreur fondamentale dans les décisions de nombreux dirigeants, et je suis certain qu'on doit pouvoir travailler ce sujet, si ce n'est pas deja fait[je me note de chercher].

difficulté d'évolutivité des codes et interactions complexes

Ces évolutions naturelles liés souvent a des besoins émergeants ensuite amene une difficulté générale a l'évolution par une complexité forte et des difficultées d'analyses globales qui rendre cahotique le programme, en particulier les éléments qui interagissent entre eux. (besoins émèrgeants : en dehors des notions de découpage de projet et cela reste ma perception : une fois qu'on voit ce qu'on a fait, on peut imaginer la suite, avoir un nouveau besoin, et mieux se rendre compte, C'est limité a quelques iterations courte chez la pluspart des gens que j'ai croisé)

conclusion

Les approches globale de conception, et de projets logiciels est généralement admise comme bonne et tout le temps nécéssaire pour les projets qui sont au dela d'aucune envergure. Et, a mon sens, ce n'est pas complement faux. Elle tente, et represente des dizaines d'années en temps multiplié par le nombre exponentielle d'experiences, de recherches, de confrontations ;et dans un certains point de vue, ne sont pas a remettre en question car elle permet de repondre a des concepts business avec des paradigmes plutot prédictible et souvent clair. On vise ce que l'on sait a un instant, pour un cout maitrisé. Cela semble donc naturellement nécéssaire en suivant les paradigmes utilisés généralement, et souvent considéré comme la seule voie disponible. Malheureusement ce n'est pas suffisant dans le cas d'un projet de type yokul. Nous avons besoin d'une évolution long terme, globale, systemique, rapide, dans un environnement d'interaction complexe, et ne pas réécrire milles fois milles interactions differentes. De ces besoins fondamentaux, émergait donc la nécéssité d'évolution de la maniere d'aborder la conception des projets afin de permettent de modeliser et de simuler n'importe quel programme, individu, chose du monde reel; tout en conservant dans le temps et dans l'étendu les choses déja pensées ou faites. Bref, faire ce que tout humain vise naturellement : en maximisant la dépense d'énergie la moindre [pour ses désirs] nottement lorsqu'on constate une évolution constante des technologies accessibles.

Sur yokul

Lors des conceptions initiale du projet yokul, nous avons identifié qu'il fallait conserver un investissement en temps le plus bas possible, qu'il fallait identifier les patterns utiles, et, en conséquence, adapter les méthodes existantes. En rajoutant comme nécéssité égale la capacité d'englober des nouvelles "technologie" ou des nouveaux comportement, et en poussant le raisonnement jusqu'a tolerer la capacité a accepter de nouveaux individus et comportements en cours d'execution de simulation ou de programme ( ou meme l'évolution d'un individu). Nous nous sommes contraint a le permettre en cherchant fondamentallement les éléments qui usuellement bloquaient dans les approches usuelles. A cause de ces differentes raisons, et en visant un modele général efficace en terme de temps de realisation, d'évolution, et de simplification global du passage de la pensée a l'execution nous avons donc fait évolué au fil du temps l'implementation et les concepts permettant de repondre a ces contraintes. :

separation of concern

Afin d'obtenir une forme acceptable et long terme, nous avons la modélisation des comportements sépare la partie sémantique et conceptuelle des systèmes informatiques (c'est-à-dire les idées et les concepts) de leur implémentation technique (c'est-à-dire le code informatique qui réalise l'action concrete sur quelque chose). Cette approche et surtout ces des formes sont manipulables par un programme (et non pas un dessin sur -pour faire court- du papier comme en uml) qui elle meme (la manipulation) peut etre considéré par un comportement. Cela permettra d'ouvrir la voie de la conception assisté par des IA qui est un domaine de recherche a part entiere.

Cette approche de modelisation de comportements offre plusieurs avantages. Elle permet la réutilisation de parties de comportements conceptuels, facilitant ainsi le développement sans nécessiter de compétences approfondies en programmation. De plus, elle permet de réduire le temps nécessaire à la conception d'un programme en utilisant de facon implicite des briques d'exécution ou de comportement déjà existantes.

Un autre avantage important de cette approche est la capacité à générer rapidement et massivement des exemples de comportements similaires mais individualisés. Elle permet également de décrire des comportements courants et de les partager facilement. De plus, le choix des éléments implementant l'exécutiond'un modèle conceptuel qui décrit un ensemble de comportement dépend du contexte et de l'environnement dans lequel il est utilisé. (cela permet de choisir a la volée en fonction du contexte l'execution, la suite d'execution.

En adoptant cette approche, nous nous concentrons uniquement sur la signification des actions entreprises, plutôt que sur la façon dont elles sont réalisées. Cela réduit la dérivée syntaxique, et permet donc la comprehension et l'évolution d'un ensemble complexe de micro-programmes qui représentent eux meme des individus uniques (en tant qu'entité, programme, lieu, et autre éléments qui represent des choses actives), quelles que soient leur complexité et leur diversité.

Il est également intéressant de noter que la prochaine étape pourrait être la génération automatique d'ensembles de comportements en fonction d'objectifs spécifiques. Les IA génératives, qui sont devenues populaires en ce début d'année 2023, se prêtent particulièrement bien à cette évolution.

Pour les plus expert d'entres vous, j'ai mis quelques notes diverses ci apres, un peu dans un ordre arbitraire et chaotique apres une introduction pour les plus aguerris ci apres

introduction pour les nerds.

L'étude et la modélisation des comportements, ainsi que leur traduction en modèles informatiques, représentent un domaine d'une grande importance au sein de l'informatique avancée. Au-delà d'une vision rudimentaire où un programme se contente de décrire un comportement donné, une approche plus élaborée s'est développée au fil du temps sur yokul.

De nos jours, la modélisation des comportements permet de dépasser la simple exécution de codes pour embrasser une démarche conceptuelle plus vaste. Elle se distingue par la dissociation entre l'assemblage des concepts, porteurs de sens et de sémantique, et leur réalisation technique, s'exprimant par le biais du code informatique. Cette approche novatrice offre de multiples avantages qui satisferont les utilisateurs les plus aguerris.

En effet, elle facilite la réutilisation de composants conceptuels, permettant ainsi d'aborder la modélisation avec une perspective affranchie des contraintes de programmation. La possibilité de recourir à des approches "no code" ou "low code" pour la construction des modèles constitue l'un des aspects les plus séduisants de cette approche. Par ailleurs, elle engendre une réduction substantielle du temps consacré à la conception, en exploitant les briques d'exécution déjà existantes.

Un autre avantage majeur de cette approche réside dans sa capacité à générer des ensembles de comportements à la fois similaires et différenciés, répondant aux spécificités individuelles. Elle favorise également la description des comportements couramment observés, rendant possible leur partage sélectif et éclairé. Il convient de souligner que le choix des éléments constitutifs de l'exécution d'un modèle conceptuel est intrinsèquement lié au contexte et à l'environnement, prenant en compte l'héritage et les contraintes spécifiques à chaque utilisateur.

En adoptant cette approche, il est possible de se concentrer essentiellement sur la signification et l'intention des actions, en reléguant au second plan les détails techniques de leur réalisation. Cela favorise une évolution fluide d'un ensemble complexe de micro-programmes, représentant des individus aussi variés que complexes.

Enfin, il est intéressant d'envisager la prochaine étape dans cette évolution constante : la génération automatisée d'ensembles de comportements en fonction d'objectifs préalablement définis. Les intelligences artificielles génératives, qui ont émergé en ce début d'année 2023, semblent particulièrement adaptées à cet objectif ambitieux.

Ainsi, cette approche avant-gardiste de la modélisation des comportements offre une perspective fascinante, où le sens prévaut sur la méthode, et où l'évolution harmonieuse d'un ensemble complexe de micro-programmes constitue un véritable objectif à atteindre.

notes diverses

Dans le domaine informatique, il est courant d'associer un programme ou une méthode à un comportement, d'un point de vue strictement sémantique. L'objectif principal réside dans la facilité de description et d'utilisation de tout comportement et de ses réactions face à des stimuli et des changements d'état.

D'un point de vue purement technique, cela se rapporte principalement à partir de la version 2 de la modélisation des comportements, et jusqu'à la version 3, où la structure sérialisée (et le code correspondant) est liée à une syntaxe XML décrivant des graphes de comportements. Sur le plan de l'implémentation, ces deux modèles conceptuels sont fusionnés par l'inversion de contrôle :

Le modèle de description, qui renferme les données permettant de décrire un comportement spécifique, qu'il s'agisse d'une réponse à un stimulus particulier, d'une organisation de comportements en réponse à un type de stimulus, ou d'un acteur composé de toutes les possibilités et les utilisant. Le modèle d'exécution, qui définit la manière de réaliser le comportement (c'est-à-dire les effets secondaires du point de vue informatique) lorsqu'un stimulus est reçu. Les deux modèles sont assemblés lors de leur création et peuvent évoluer lorsque la "description" d'un comportement utilisé subit des changements au sein du graphe d'héritage. Sur le plan conceptuel, les modèles d'exécution n'ont pas d'état propre en soi (du point de vue informatique et conceptuel). Actuellement, c'est le modèle d'acteur qui possède l'état, incluant les caractéristiques, la mémoire et le génome. L'exécution d'un comportement s'effectue donc en utilisant un contexte qui englobe les acteurs impliqués (soi-même, éventuellement l'émetteur du stimulus) et surtout le stimulus lui-même.

En fin de compte, cette approche, où la séparation est réelle, tant sur le plan physique que conceptuel, rend le débogage traditionnel plus complexe. Cependant, elle semble considérablement réduire les anomalies de conception tout en accélérant les changements et les évolutions conceptuelles.

historique

Historiquement, dans la version 1.0, les modélisations de comportement, concept phare de Yokul, étaient réalisées par génération dynamique de code. Cependant, au fil des itérations et des recherches visant à résoudre les difficultés et les risques de sécurité inhérents à cette approche (tels que le remplacement de classes en mémoire, la compilation ou encore l'assemblage du code), une évolution était nécessaire pour mieux appréhender les multiples aspects de la conception d'un comportement et sa transformation en une exécution concrète.

Ainsi, à partir de la version 2.0, une nouvelle approche émergea, séparant distinctement les dimensions conceptuelle et technique de la modélisation des comportements. Cette rupture conceptuelle permit de dépasser les limitations inhérentes à la génération de code statique ou dynamique et de répondre aux besoins croissants des concepteurs en matière de clarté, de flexibilité et de maintenabilité des systèmes.

La version 2.0 marque une avancée significative, où la structure sérialisée, qui contenait auparavant le code informatique, fut remplacée par une syntaxe en XML permettant de décrire des graphes de comportements de manière plus intuitive et compréhensible. Cette évolution marqua également l'introduction de l'inversion de contrôle, un mécanisme crucial qui permit de réunir harmonieusement les modèles conceptuels de description et d'exécution.

L'ensemble de ces avancées, fruit d'une recherche constante d'efficacité et de fiabilité, a ouvert la voie à une modélisation des comportements plus robuste, réutilisable et adaptable. Les concepteurs, en embrassant cette approche novatrice, ont pu constater une réduction significative des erreurs de conception, une accélération des cycles de développement et une amélioration globale de la qualité des systèmes.

En conclusion, les librairies de modelisation de comportemetn de Yokul peuvent s'affirmer comme un framework et une plateforme visionnaire dans le domaine de la modélisation des comportements. À travers son évolution progressive, cette approche a permis de transcender les limites traditionnelles de developpement et ou la génération dynamique de code, en privilégiant une séparation claire entre les dimensions sémantiques et techniques. Aujourd'hui, les concepteurs peuvent tirer parti de cette approche pour créer des systèmes logiciels plus fiables, évolutifs et conformes aux exigences. Yokul incarne ainsi l'aspiration des informaticiens à repousser les frontières de l'ingénierie logicielle et à offrir des solutions qui inspirent et transforment notre façon de concevoir et de développer des systèmes informatiques avancés.

Exemple d'implication concrete : Dans l'exemple xml ci dessous, il s'agit de la description d'un chat bot tres tres simple. On reagit a des stimulis qui sont "entendre" des phrases dont le sens est bonjour, travail, adieu, ou on ne comprends rien (comportement par defaut).

Quand le stimuli est détécté on reponds par des phrases sans intelligence. Pour les plus attentif : c'est un type d'acteur qui est un "human", ce qui veut dire que tout les "human" ou leurs heritiers ont ce comportement.

C'est la version de description, et dont l'execution de 2009 est une implementation basique, as permis de présenter le moteur de comportement en vue de l'ouverture d'un des projets a des personnes qui ont travaillé dessus quelques années.

Aujourd'hui, on peut ne pas changer ce descripteur et l'implementer comme ceci (je ne l'ai pas fait encore !): On demande a une IA generative le meilleurs sens compte tenu d'une conversation en cours. puis ensuite on peut proposer une réponse qui s'apparente au sens du dialogue préparé initiallement, mais avec un style adapté a l'acteur éméteur en detail.

exemple de descripteur en xml (édulcoré, et date de 2010)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<eXtensibleBehavior name="human"
    xmlns="http://xsd.yokul.org/xbml/2.0"
    xmlns:ykd="http://xsd.yokul.org/memory_decision/1.0"
    xmlns:yk-ext="http://xsd.yokul.org/xbml-ext/2.0"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
    http://xsd.yokul.org/memory_decision/1.0    ../../cache/injected/xsd.yokul.org/memory_decision/1.0.xsd
    http://xsd.yokul.org/xbml/2.0   ../../cache/injected/xsd.yokul.org/xbml/2.0.xsd
    http://xsd.yokul.org/xbml-ext/2.0   ../../cache/injected/xsd.yokul.org/xbml-ext/2.0.xsd"
    >

    <parents>
        <id>live_being</id>
        <id>pnj_tactics</id>
        <id>action_bases</id>
    </parents>
    <domains>
        <aggregatableeXtensibleBehaviorDomain id="listening">
            <rule id="bonjour">
                <yk-ext:speak actor="self"
                    sentence="Bonjour l'ami. Vous avez besoin d'aide ?" />
            </rule>
            <rule id="travail">
                <yk-ext:speak actor="self"
                    sentence="Il ne manque plus qu'a utiliser la classe ObjectiveRuleSet, tu peux eventuellement passer par le contexte du result set qui te permet d'obtenir l'acteur du paramettre (on verra ensemble pour le reste de l'environnement necessaire a la mémoire et decision)" />
            </rule>
            <rule id="adieu">
                <yk-ext:speak actor="self"
                    sentence="A bientot. Forcement." />
            </rule>
            <rule id="default">
                <yk-ext:speak actor="self"
                    sentence="C'est pas faux!" />

            </rule>
            <domains/>
        </aggregatableeXtensibleBehaviorDomain>
        <eXtensibleBehaviorDomain id="environnement">
            <rule id="vieillir">
            <!-- called often -->

            </rule>
            <rule id="mourrir">
                <yk-ext:speak actor="self" target="self" sentence="argggh" />
                <!--  un dernier cri avant la fin de vie :) -->
            </rule>
        </eXtensibleBehaviorDomain>
    </domains>
</eXtensibleBehavior>

exemple de Graph de comportements