est rattachée à une instance et une seule de Population. Cette dernière a, en plus de ce
qui a été décrit dans la classe Population, son patrimoine génétique. Une instance de
PatrimoineGenetique est constituée d'un ensemble de références d'instances
d'Attributs et de Methode. Elle peut donc être constituée et complétée selon les
besoins, en manipulant les différentes classes de la même population.

De manière plus précise, toute instance de PatrimoineGenetique est définie pour une
instance de Population et est définie par l'ensemble des références (sans redondance)
des gènes particuliers constituant le génotype fondamental commun à toutes les
classes, et des gènes constituants le GH et le GS de chaque classe de la population.

3) - ClasseGtype

Toute classe détient un ensemble d'attributs et de méthodes constituant ses gènes.
Toute classe est décrite par trois blocs de gènes distincts : le génotype fondamental, le
génotype hérité et le génotype spécifique.

La classe ClasseGtype représente toute classe décrite dans notre modèle. Elle est
caractérisée par un nom. L'attribut GF de ClasseGtype est une référence vers une
instance de Population. Ainsi, le GF est défini dans chaque classe et est hérité par ses
éventuelles sous-classes. Ceci permet également d'assurer l'appartenance de ces sous-
classes à la même population.

Le GH définit les attributs et méthodes hérités qui peuvent être redéfinis ou
surchargés. Le GS définit les attributs et méthodes définis localement. Le GH de toute
classe est en fait le GS et le GH de sa super-classe (Figure 3-2), éventuellement redéfinis
ou surchargés.

4) - Attributs

Dans un état stable, tous les attributs sont des composants de classes et font partie intégrante des patrimoines génétiques existants dans le modèle. Un attribut peut faire partie des structures de différentes classes, voire de différentes populations.

Durant un processus d'évolution, certains attributs peuvent ne pas appartenir
pleinement à un patrimoine génétique donné. Ces attributs sont ceux nouvellement
introduits par un objet ayant évolué. Tant que le processus n'a pas abouti, ces
nouveaux attributs ne sont référencés par aucune classe ni par aucun patrimoine
génétique. Ils ont un statut particulier, le statut *transitoire*, contrairement aux attributs
particiulant aux spécifications de classes, et par conséquent de patrimoines génétiques,
ont un statut *permanent*. C'est à la fin de la phase d'exploitation que leur statut peut
changer. Si le concepteur décide, au vu des résultats de l'exploitation, de garder des
attributs de ce type, ils intègrent alors définitivement le modèle. Leur statut passe alors
de transitoire vers permanent. Le patrimoine génétique de la population à laquelle
appartient la classe est mis à jour pour l'intégrer. Les éventuelles sous-classes, de la
classe détenant ces nouveaux attributs, sont également modifiées pour le prendre en
compte dans leur GH (confère processus de développement-chapitre 5). Par contre si le
concepteur décide de ne pas les intégrer, ils sont alors rejetés et donc détruits sans
incidence aucune sur le modèle existant.
L'intégration d'un nouvel attribut au sein d'une classe influence également les schèmes permanents concernés. En effet, cela implique automatiquement la mise à jour de tous les schèmes concernés de la population : le schème de la classe concernée aura la valeur à 1 ou # selon le cas ; les schèmes de ses sous-classes également, sauf restriction explicite du concepteur.

### 5) - Methode

Dans un état stable, toutes les méthodes sont des composants de classes et font partie intégrante des patrimoines génétiques existants dans le modèle. Une méthode peut faire partie des spécifications de différentes classes, voire de différentes populations.

### 6) - Scheme

Un schème est constitué d'un ensemble de couplets (*Attribut* ; *ValeurGène*), *Attribut* est la référence de l'attribut représenté et *ValeurGène* est la valeur de ce gène dans le schème. Chacune de ces valeurs est prise dans l'ensemble {0, 1, #} pour exprimer respectivement l'absence, la présence ou l'indifférence de l'attribut référencé.

Un schème (donc une instance de la classe Scheme) peut être permanent ou temporaire. Un schème permanent est complètement dépendant de la classe à laquelle il est associé. Pour un schème permanent, les attributs référencés sont ceux de sa classe.

Il est à rappeler que la valuation des attributs du GF au niveau des schèmes sont identiques pour tous les schèmes permanents de la même population.

### 7) - InstanceClasseGtype

Cette classe est représentée dans le modèle pour exprimer le fait que les instances de la classe ClasseGtype soient également des classes, même si elles sont représentées dans un premier temps par des instances (cet aspect ne fait pas partie des objectifs de ce chapitre. Nous proposons au lecteur de se référer au chapitre implémentation pour de plus amples éclaircissements).

### 3.7.1.4. Définition des différents liens

Les liens entre concepts qui sont porteurs d'une sémantique particulière pour la compréhension du modèle sont définis ci-après. Chaque lien est défini par son nom et les deux classes qu'il relie :

#### 1) - 'faitPartie' entre classe ClasseGtype et classe Population

'faitpartie' est une association entre ClasseGtype et Population. Ce lien est en fait véhiculé par l'attribut GF de ClasseGtype, et qui réfère à une instance de Population qui définit le GF. Ce lien est explicitement nommé pour exprimer cette appartenance d'une classe à une population. Cette appartenance peut être directe si une classe hérite directement de sa population ou indirecte si elle hérite d'une autre classe de la même population.
## 2) - 'son PG' entre classe Population et classe PatrimoineGenetique

La relation 'sonPG' est une association entre Population et PatrimoineGenetique. Il exprime qu'une population a un et un seul patrimoine génétique, et qu'un patrimoine génétique revient à une et une seule population.

## 3) - 'AttributsGF' entre classe Population et classe Attributs

'AttributsGF' est un lien de composition. Une population définit un GF. Un GF est constitué d'un ensemble d'attributs.

## 4) - 'MethodesGF' entre classe Population et classe Methode

'MethodesGF' est également un lien de composition. Une population définit un GF. Un GF est constitué également d'un ensemble de méthodes définies sur les attributs constituants le GF.

## 5) - 'is-a' entre classe ClasseGtype

Le lien 'is-a' est une association réflexive sur la classe ClasseGtype. Elle représente le lien d'héritage qui peut exister entre une classe et sa super-classe. Les rôles expriment un peu plus la sémantique du lien d'héritage :

- sous-classe : cardinalité : 0..1. Une classe peut au plus être sous-classe d'une autre classe.

- super-classe : cardinalités : 0..*. Une classe peut avoir aucune ou plusieurs sous-classes.

## 6) - 'MethodesGH' entre classe ClasseGtype et classe Methode

Le lien 'MethodesGH' est un lien de composition. Une classe a son GH composé de méthodes définies sur les attributs constituants le GH de la classe. Ces méthodes sont celles constituant les méthodes du GS et celles du GH de la super-classe. Une méthode peut participer plusieurs fois à la constitution de GH différents.

## 7) - 'MethodesGS' entre classe ClasseGtype et classe Methode

Le lien 'MethodesGS' est un lien de composition. Une classe a son GS composé de méthodes définies sur les attributs constituants le GS de la classe. Ces méthodes sont définies localement au sein de la classe. Une méthode peut participer plusieurs fois à la constitution de GS différents.

## 8) - 'AttributsGH' entre classe ClasseGtype et classe Attributs

Le lien 'AttributsGH' est un lien de composition. Une classe a son GH composé d'attributs du GS et d'attributs du GH de sa super-classe. Un attribut peut participer plusieurs fois à la constitution de GH différents.

## 9) - 'AttributsGS' entre classe ClasseGtype et classe Attributs

Le lien 'AttributsGS' est un lien de composition. Une classe a son GS composé d'attributs définis par la classe. Un attribut peut participer plusieurs fois à la constitution de GS différents.
10) - 'aPourSchemePermanent' entre classe ClasseGtype et classe Scheme

Le lien 'aPourSchemePermanent' est un lien de composition. Une classe est également constituée d'un schème permanent qui permet de compléter sa structure et, par la suite, celle de ses instances. Une classe n'a qu'un seul schème permanent et un schème permanent ne peut être associé qu'à une seule classe.

11) - 'estAssocieA' entre classe ClasseGtype

L'association 'estAssocieA' est une association réflexive définie sur ClasseGtype. Elle permet d'exprimer une association que peut avoir une classe avec une autre classe.

12) - 'lienEvolution' entre classe ClasseGtype

Ce lien est une association porteuse de propriétés, et elle est représentée par une classe nommée 'evolueVers', ce qui permet d'exprimer le lien d'évolution. Une instance peut évoluer d'une classe vers une autre en suivant un lien d'évolution. Pour exprimer cette sémantique, le lien 'lienEvolution' définit deux rôles :

- source : représente quelle classe est la source du lien d'évolution. Une classe peut ne pas être une classe source d'un lien d'évolution ou peut l'être pour différents liens d'évolutions ;

- cible : représente quelle classe est la cible du lien d'évolution. Une classe peut ne pas être une classe cible d'un lien d'évolution ou peut l'être pour différents liens d'évolutions.

Cette association est navigable, puisque orientée vers la classe cible. Cette association est instanciée lorsqu'un objet de la classe (classe source) a eu à évoluer, comme résultat du processus d'évolution, et à être rattaché à une nouvelle classe ou une classe existante (classe cible).

La classe 'evolueVers' a pour attributs :

- attributsPerdus : l'ensemble des références des attributs perdus par une instance de la classe source ;

- methodesPerdus : l'ensemble des références des méthodes perdues, c'est-à-dire celles ayant ces attributs présents dans la signature et perdus par une instance (c'est-à-dire qui ne se retrouveront pas dans la classe cible), et par conséquent l'ensemble des méthodes auxquelles elle ne réagira plus ;

- attributsAcquis : l'ensemble des références des attributs de la classe cible à acquérir par l'instance qui évolue vers cette classe cible ;

- methodesAcquises : l'ensemble des références des méthodes acquises, c'est-à-dire celles ayant ces attributs présents dans la signature et acquis par l'instance (c'est-à-dire qui se retrouveront dans la classe cible), et par conséquent l'ensemble des méthodes auxquelles elle devra réagir.
## 3.8 - Conclusion

Ce chapitre est le premier des trois chapitres qui présentent le modèle GENOME : ses concepts. Ses processus d'évolution et son modèle de métriques pour le contrôle de l'émergence sont définis dans les chapitres suivants. Ils sont définis pour permettre d'appréhender l'évolution d'un modèle à objet à partir de l'évolution structurelle dynamique d'instances. Ces changements sont exprimés directement sur les instances par le concepteur. Ces processus sont itératifs et auto-adaptatifs : lorsqu'une classe évolue et provoque des impacts, il s'agit d'un processus de développement (section 3.3.1) ; lorsqu'une instance évolue dans sa structure et peut influencer les classes, il s'agit d'un processus d'émergence (section 3.3.2). Cela fait l'objet des deux prochains chapitres.

Les concepts de GENOME font donc l'objet du présent chapitre. Les concepts sont définis de manière à pouvoir manipuler aussi bien les classes et leurs spécifications et liens, que les instances. Pour cela les concepts sont tous réifiés.

Pour les mêmes raisons, nous définissons pour le modèle des concepts de base et des concepts avancés. Les concepts de base (section 3.4 - ) sont plus une définition des concepts objet de base sous l'optique de l'Évolution Artificielle : une classe-GTYPE (section 3.4.2) détient le génotype de ses instances alors qu'une instance-PTYPE (section 3.4.3) représente le phénotype de sa classe, c'est-à-dire sa réalisation dans un environnement donné. Un gène (section 3.4.1) est la partie d'information que sont l'attribut et la méthode. Les classes qui déclinent les différentes possibilités d'une abstraction complexe du monde réel constituent une population (section 3.4.4). L'ensemble des gènes définis par ses classes constitue le patrimoine génétique (section 3.4.4) de la population.

Les concepts avancés (section 3.5 - ) sont spécifiques à GENOME. Une classe est définie au travers de trois groupes de gènes : le GF (section 3.5.1) qui défini l'essence de toute population et qui est immuable pour toutes ses classes, le GH (section 3.5.2) qui définit l'héritage des ancêtres (les super-classes directe et indirectes) et qui peut être redéfini et enfin le GS (section 3.5.3) qui définit les spécificités de chaque classe. Le schème (section 3.5.4) quant à lui est une entité qui transcrit la structure de classes : c'est le schème permanent (section 3.5.4.1), ou la structure d'une instance : c'est le schème temporaire (section 3.5.4.2). Il est décrit de façon simple au travers de trois valeurs possibles : 1, 0 ou # (section 3.5.4.3). L'indéniable avantage du schème est de considérer de la même manière classes et instances dans des processus d'évolution complètement automatisés, et de pouvoir faire du calcul symbolique.

Tous ces concepts et toutes ces notions sont représentés dans le méta-modèle de GENOME (Section 3.7 - ).
# Chapitre 4 : GENOME : LES PROCESSUS D'EVOLUTION

<figure><img src="image_23.png" /></figure>
## 4.1 - Introduction

Après avoir abordé et défini les concepts du modèle ainsi que son contexte, nous abordons dans le présent chapitre les *processus d'évolution* du modèle GENOME.

Les processus d'évolution sont définis dans le cadre de l'émergence et du développement. Comment ?

### 4.1.1. L'évolution gérée au travers de processus d'évolution

Un processus d'évolution est généralement déclenché pour faire face et répondre à une situation de changement. Un processus d'évolution est le reflet opératoire de la politique d'évolution d'une stratégie donnée.

Dans le cadre de notre travail, et toujours au vu de nos objectifs, nous nous intéressons à la gestion de l'évolution lorsqu'une ou plusieurs instances sont modifiées dans leur structure. Nous définissons des processus d'évolution qui sont déclenchés lorsqu'un changement, prévu ou non, survient sur des instances.
<figure><img src="image_24.png" /><figcaption>Figure 4-1: les processus d'évolution entre deux états stables du modèle.</figcaption></figure>

Le processus d'évolution doit être en mesure de détecter ce changement ainsi que son type, de retrouver les entités impliquées dans l'évolution et de répercuter ce changement de manière adéquate sur les classes existantes.

### 4.1.2. Formalisme utilisé

Tout au long de ce chapitre, nous présentons les différentes étapes d'un processus d'évolution, après l'avoir défini et avoir expliqué son utilité. Nous optons pour une représentation graphique des différentes étapes de chaque processus afin d'en donner une vision plus claire. Cette représentation est accompagnée d'explications. Le formalisme graphique que nous choisissons d'utiliser est celui des diagrammes d'états-transitions d'UML [Muller 97] pour spécifier les différentes étapes de chaque phase. Le formalisme est décrit en Figure 4-2 :
<figure><img src="image_25.png" /><figcaption>Figure 4-2. Formalisme du diagramme Etats-Transitions d'UML</figcaption></figure>

Ce diagramme s'inspire des statecharts [Harel 87, Harel 96]. Il est adapté à nos besoins car il permet de représenter :

- les différents états par lesquels peut passer une entité. Il existe trois différents types d'états, chacun ayant un formalisme graphique précis :

- un seul état initial ●

- un ou plusieurs états intermédiaires avec des actions

<figure><img src="image_26.png" /></figure>

- un ou plusieurs états finaux

<figure><img src="image_27.png" /></figure>

- les transitions entre deux états. Une transition est représentée par une flèche entre deux états successifs. Cette flèche est orientée de l'état précédent vers l'état suivant. Outre le nom de la transition, le formalisme offre également la possibilité d'exprimer des conditions sur l'exécution de ces transitions ainsi que les actions menées et les événements émis :

- [condition]

- /Action sur Condition

- ^Émission Événements

### 4.1.3. Niveau d'abstraction considéré

Les diagrammes d'états-transitions sont définis pour être utilisés avec des classes. En effet, selon UML, un diagramme d'états-transitions, dit également *automate*, est attaché à une classe pour décrire les différents états, ainsi que leur séquence, par lesquels passent les objets de cette classe. Concernant GENOME, nous avons besoin de décrire les différents états par lequel passe un modèle donné, donc un schéma de classes. Aussi, les automates que nous présentons ne décrivent pas les états des objets *d'une* classe donnée mais les états des objets des classes définies au sein d'un modèle de classes. Les processus d'évolution sont donc représentés par des automates et peuvent impliquer toutes les entités (classe, instance, lien, attribut) présentes dans le modèle de classes.
## 4.2 - Les trois phases d'un processus d'évolution : définition

Nous considérons que tout processus d'évolution d'une instance s'exécute en trois phases :

- une phase d'extraction ;

- une phase d'exploration ;

- une phase d'exploitation.

### 4.2.1. Présentation

Chacune de ces trois phases est déclenchée par un événement particulier et nouveau. Ces trois phases se succèdent. Comment est-ce que le début et la fin d'une phase sont matérialisés ?

Le diagramme d'états-transitions suivant (Figure 4-3) met en évidence l'enchaînement des trois phases :
<figure><img src="image_28.png" /><figcaption>Figure 4-3: Les trois phases d'un processus d'évolution</figcaption></figure>

A ce stade de description, le diagramme est volontairement peu détaillé. L'objectif est de mettre en évidence ce que fait globalement chaque phase, préfixé par un 'do :', et ce qui ressort de l'exécution de chacune, préfixé par un 'exit :'.

D'une manière globale :

- L'évènement déclencheur de la phase d'extraction est l'évolution d'un objet dans sa structure initiale. L'événement en sortie est le schème temporaire associé ;

- L'évènement déclencheur de la phase d'exploration est la spécification du schème temporaire. L'événement en sortie est l'ensemble des classes sélectionnées ;

- L'évènement déclencheur de la phase d'extraction est l'ensemble des classes sélectionnées. L'évènement en sortie est l'achèvement de l'évolution.

Nous définissons de manière plus précise chaque phase dans ce qui suit, avant de définir leur automate respectif dans la section 4.4 - .
### 4.2.2. Phase d'extraction

La phase d'extraction survient dès que l'évolution d'un objet (voire plusieurs objets) dans sa structure est effectuée et détectée. Étant dans un cadre de simulation de l'évolution, nous laissons le soin au concepteur de choisir de déclencher lui-même le processus d'évolution. S'il ne le souhaite pas, le déclenchement sera automatique dès qu'une instance est modifiée dans sa structure. L'objectif de cette phase est d'extraire le code génétique de cet ou ces objets. Le code génétique de tout objet ayant évolué est extrais au sein d'un schème temporaire (défini au chapitre 4). Il a la même structure que l'objet ayant évolué car il spécifie la présence ou non d'un attribut dans la structure de l'instance. En effet, si un attribut du patrimoine génétique de la population est présent dans sa structure, il est référencé par le schème. La façon dont il est valué est alors spécifiée : à 1 (donc obligatoirement présent), à 0 (donc obligatoirement absent) ou à # (donc optionnel).

Ces schèmes temporaires (un par instance ayant évolué) sont les entités sur lesquelles s'appliquent les deux autres phases du processus d'évolution. Son expression est simple. Il peut donc être aisément manipulé de façon automatisée, ce qui est beaucoup moins évident si l'on travaillait directement sur les instances.

### 4.2.3. Phase d'exploration

La phase d'exploration se déclenche lorsque les schèmes temporaires sont spécifiés. Comme son nom l'indique, l'objectif de cette phase est d'explorer l'ensemble des structures conceptuelles présentes dans le modèle, dans le but de trouver celles qui sont complètement ou partiellement adaptées à l'instance ayant évolué. En effet, les différentes structures conceptuelles constituent un espace de solutions potentielles en terme d'adéquation entre les schèmes temporaires et les schèmes permanents (en d'autres termes, l'adéquation entre une instance et une classe).

L'exploration s'exécute sur les schèmes temporaires et les schèmes permanents. Elle se fait en deux principales étapes :

- La première étape consiste à explorer l'ensemble des populations existantes pour détecter la population (voire les populations dans le cas d'objets complexes) à laquelle l'instance peut potentiellement appartenir ;

- La seconde étape consiste à explorer l'ensemble des classes définies au sein de la population sélectionnée afin de déterminer les classes qui détiennent une partie ou la totalité des gènes de l'instance.

### 4.2.4. Phase d'exploitation

La phase d'exploitation se déclenche lorsque la population et les classes plus ou moins adaptées à l'instance sont sélectionnées. L'objectif de cette phase est d'exploiter les différentes entités : les classes sélectionnées, représentées par les schèmes permanents,
et les instances ayant évoluées, représentées par les schèmes temporaires ainsi que les différentes autres données présentes dans le modèle, telles que par exemples des contraintes. Le but ultime de l'exploitation est de tenter de tirer le meilleur parti possible des toutes les informations présentes dans le modèle et celles introduites par les instances.

L'exploitation permet de mettre en évidence la façon la plus appropriée de faire évoluer le modèle au vu des spécifications de classes et d'instances. L'exploitation peut mener à terme l'un des deux principaux processus d'évolution, le *développement* ou l'émergence :

### 4.2.4.1. Processus de développement

Un processus de développement est tout processus d'évolution de classes aussi bien en intention qu'en extension :

- *L'évolution en intention* : cela consiste à faire évoluer les propriétés (attributs et méthodes) au sein d'une classe. Nous incluons également dans l'évolution en intention, les impacts de l'évolution des spécifications d'une classe vers les autres classes concernées par le lien d'héritage, en l'occurrence les sous-classes, ou par les liens de composition, ainsi que les différents impacts sur les classes d'une hiérarchie lorsque cette dernière est réorganisée ;

- *L'évolution en extension* : cela consiste à faire évoluer les instances d'une classe. Il existe différentes possibilités :

- Dans le cadre de l'évolution en intention d'une classe, plus précisément des attributs, dits également variables d'instances, les instances d'une classe peuvent nécessiter d'être adaptées au nouvel état de leur classe. L'évolution en extension de la classe vient comme conséquence de son évolution en intention ;

- Dans le cadre de l'évolution des valeurs des instances dans leurs variables d'instances définies dans leur classe ;

- Dans le cadre de l'évolution d'une instance à partir d'une classe vers une autre (migration d'instances). Dans ce cas, il s'agit d'évolution en extension des deux classes source et cible de la migration.

### 4.2.4.2. Processus d'émergence

Un processus d'émergence est tout processus d'évolution d'instances avec des impacts sur les spécifications de classes. Il concerne toute émergence d'une nouvelle structure conceptuelle à partir d'instances. Il y a deux issues possibles à cette évolution :

- *Émergence locale* : concerne l'émergence de nouvelles informations au sein de classe(s) existante(s). Le code génétique de l'objet a été modifié et peut faire modifier celui de sa classe ou celui d'une classe sémantiquement voisine.
– Émergence globale : concerne l'émergence d'une nouvelle structure conceptuelle (donc de classe(s)) soit par projection directe à partir de l'objet ayant évolué, soit par croisement de structures existantes.

Avant d'expliquer de manière plus détaillée le fonctionnement de chaque phase au sein d'automates (section 4.4 - ), nous définissons et présentons les opérateurs de base qui sont nécessaires à l'exécution de ces différentes phases dans la section suivante.

## 4.3 - Les Opérateurs Génétiques Objets

Nous définissons les opérateurs de GENOME qui s'appliquent et manipulent les concepts du modèle (population, classe-GTYPE, instance-PTYPE, schème permanent, schème temporaire, gène et patrimoine génétique). Ces opérateurs sont utilisés lors des trois phases d'évolution.

Les opérateurs utilisés sont ceux de sélection, de reproduction, de croisement et de mutation. Ces opérateurs s'appliquent différemment. Nous faisons cette distinction selon leur action sur l'entité ou les entités concernées.

### 4.3.1. Introduction

L'idée principale des opérateurs que nous définissons est de pouvoir manipuler indifféremment les spécifications de classes et les spécifications d'instances. Cette indifférence est rendue possible grâce au concept de schème. Les opérateurs s'exécutent en effet uniquement sur les schèmes permanents et/ou temporaires, donc sur les gènes ; ils diffèrent selon leur application : sur un schème, sur deux schèmes ou sur un gène.

Les opérateurs que nous proposons sont inspirés des opérateurs des Algorithmes Génétiques. De la même manière que nous avons procédé pour les concepts, certains opérateurs sont une interprétation d'actions sous une transcription Évolution Artificielle, alors que d'autres sont nouvellement introduits (tels que la sélection et principalement le croisement).

Leur exécution est ainsi aisément automatisée durant tout le processus d'évolution.

Nous rappelons que les processus d'évolution sont définis à des fins de simulation d'évolution. Les entrées sont les besoins qu'exprime le concepteur et les résultats en réponse à ces besoins sont donnés au concepteur. Ce dernier aura alors la charge des choix conceptuels définitifs.
### 4.3.2. Sélection

De manière générale, la *sélection* nécessite de travailler sur l'adaptation d'une entité à un problème ou une application donnés. Dans GENOME, l'opérateur de sélection est défini pour déterminer, après l'évolution structurelle d'une instance, quelles sont les classes qui détiennent une partie ou la totalité de ses gènes. Cet opérateur est inspiré des Algorithmes Génétiques. L'opérateur de sélection que nous proposons revient donc à choisir des classes en comparant la structure de la classe avec celle de l'instance, au travers des schèmes permanents et du schème temporaire. Cette sélection se base sur leur adaptation par rapport à un critère d'adéquation partielle ou totale de deux schèmes. Cette adéquation se calcule au travers de la *valeur d'adaptation* (confère section 4.3.6), grâce à une *fonction d'adaptation*.

### 4.3.3. Reproduction

La *reproduction* revient à la création d'un individu par rapport à un code génétique. Au vu des concepts de classe-GTYPE et instance-PTYPE et de leur définition, nous considérons que dans un modèle à objet, la reproduction revient au processus d'instanciation. L'instance a donc le code génétique de sa classe qu'elle value. Cette valuation est différente d'une instance à une autre et donne ainsi des individus différents constitutifs du PTYPE de la classe.

### 4.3.4. Croisement

L'opérateur de *croisement* est défini dans les Algorithmes Génétiques (chapitre 2). Il reprend le principe du croisement de codes génétiques en biologie. Le croisement s'applique sur deux schèmes. Il permet d'interchanger des portions de codes génétiques. Le résultat du croisement est défini dans deux nouveaux schèmes, généralement appelés *enfants*. Les deux schèmes ayant ainsi été croisé sont généralement appelés *parents*. Les schèmes enfants ont la même longueur de code génétique que leurs parents.

Dans le cadre de GENOME, nous définissons l'opérateur de croisement pour permettre à deux schèmes d'interchanger leur code génétique. Le croisement s'applique sur les schèmes permanents de l'ensemble des classes sélectionnées lors de la phase d'exploration, et qui sont partiellement adaptées à une instance ayant évolué. Le principal objectif est de tenter de parvenir, par cet inter changing de gènes, à constituer d'autres structures conceptuelles plus adaptées aux instances ayant évolué, donc plus adaptées au nouveau contexte. Ces structures conceptuelles résultantes sont également représentées sous forme de schèmes.

Le but recherché n'est pas d'arriver en définitive à un schème représentant une instance, mais de dégager un ou plusieurs schèmes, dits *émergents*, pouvant englober l'instance, et par conséquent répondant aux nouveaux besoins. Ces schèmes émergents
seront des structures nouvelles plus riches que celles portées par l'instance. Ils permettent de faire apparaître et de mettre en évidence des structures conceptuelles nouvelles qui étaient peut être noyées dans les structures existantes ou qui étaient peut être complètement méconnues.

Le détail du fonctionnement de l'opérateur de croisement est défini dans la section 4.5.2.2 au travers de l'automate qui lui est associé.

### 4.3.5. Mutation

Nous considérons comme mutation toute apparition d'une nouvelle information, au sein d'un objet ou d'une classe, auparavant inexistante, et qui provoque le changement du patrimoine génétique de la population.

L'opérateur de mutation est donc défini comme toute action pouvant modifier les caractéristiques des instances et des classes. La mutation revient à activer ou à désactiver la présence d'un gène au sein d'un schème, c'est-à-dire mettre à 1 ou à 0, voire même à #, un gène dans un schème. L'opérateur de croisement seul ne peut pas toujours empêcher la perte d'informations prometteuses pour l'évolution. L'opérateur de mutation est utilisé pour introduire ou modifier des gènes nécessaires lors de processus d'évolution, voire même lorsque la sélection et le croisement ne donnent pas de résultats intéressants. L'objectif est alors double :

- cerner une autre partie du modèle pour effectuer des recherches ;

- tenter de restaurer éventuellement des structures génétiques perdues ou nécessaires.

Cet opérateur n'est pas systématiquement utilisé et ne s'applique pas de manière automatique. Son application est ponctuelle et est généralement déclenchée par le concepteur pour modifier spécifiquement les gènes qu'il juge bon de faire muter.

### 4.3.6. Valeur d'Adaptation

La valeur d'adaptation $Va$ permet de calculer l'adaptation de classes à un objet. Le calcul de cette valeur se fait grâce à une fonction dite *fonction d'adaptation* et ayant comme paramètres d'entrée deux schèmes de même longueur. Le premier schème représente l'instance ayant évoluée et le deuxième schème en paramètre représente soit un schème permanent (donc une classe de la population sélectionnée), soit un schème intermédiaire. En notant :

- le schème de l'objet ayant évolué $Sch_{obj}$

- et le schème en paramètre par $Sch_{param}$,

nous définissons la fonction d'adaptation utilisant l'opérateur $\wedge$ (ou_logique dont la table de vérité est le Tableau 4-1) comme suit :
$$Va(\text{Sch}_{\text{param}}) = \sum_{i=1 \to n} \{ \text{Sch}_{\text{obj}[i]} \wedge \text{Sch}_{\text{param}[i]} \} / n$$

Où :

- n est le nombre de gènes spécifiés dans l'objet ayant évolué ;

- i est l'indice variant de 1 à n définissant à chaque passage la position des deux gènes respectifs des schèmes analysés.

Le principe est qu'à chaque fois que deux gènes sont identiques, la valeur d'adaptation de Sch<sub>param</sub>, initialement à zéro, augmente de 1. Si deux gènes sont contradictoires, la valeur n'augmente pas. A la fin, la valeur d'adaptation est divisée par le nombre de gènes spécifiés, c'est-à-dire valués à 1, dans le schème de l'objet ayant évolué. Elle est ainsi toujours comprise dans l'intervalle [0, 1]. Lorsqu'un schème Sch<sub>param</sub> a une valeur d'adaptation égale à 1, cela implique qu'il est complètement adapté à Sch<sub>obj</sub>. Il est alors dit *Schème Émergent*.

Les gènes spécifiés sont tous les gènes ayant leur présence obligatoire, donc valués à 1. Les gènes obligatoirement absents ne sont pas pris en compte, et les gènes optionnels dans Sch<sub>obj</sub> ne sont pas déterminants dans les choix. Ils ne sont par conséquent pas considérés, contrairement aux gènes optionnels dans Sch<sub>param</sub>. Les différentes combinaisons des valeurs pour un gène à la position i dans chacun des deux schèmes, et leur interprétation sont récapitulées dans la table suivante :

<table><caption>Tableau 4-1: table de vérité de l'opérateur ∧.</caption><thead><tr><th>Sch<sub>obj</sub>[i]<br>Sch<sub>param</sub>[i]</th><th>0</th><th>1</th><th>#</th></tr></thead><tbody><tr><th>0</th><td>0</td><td>0</td><td>0</td></tr><tr><th>1</th><td>0</td><td>1</td><td>0</td></tr><tr><th>#</th><td>0</td><td>1</td><td>0</td></tr></tbody></table>

Pour que deux schèmes puissent être comparés en terme d'adaptation, ils doivent avoir la même structure. En effet, étant donné que le but est de calculer si un schème Sch<sub>1</sub> est adapté et dans quelle mesure il l'est à un autre schème Sch<sub>2</sub>, il faut pouvoir comparer si un gène est spécifié ou non dans les deux schèmes. Pour cela, une première phase d'uniformisation des deux schèmes est effectuée par comparaison deux à deux des gènes. Cette uniformisation se base sur la concordance de la position du même gène à la même position dans les deux schèmes (indépendamment de la façon dont il est évalué). Nous imposons qu'un gène soit à la même position lorsque deux schèmes sont comparés.

Par exemple, les deux schèmes Sch<sub>2</sub> et Sch<sub>1</sub> suivants sont à comparer. On désire connaître l'adaptation de Sch<sub>2</sub> à Sch<sub>1</sub>. Sch<sub>1</sub> est constitué des gènes (attributs) a<sub>1</sub>, a<sub>4</sub>, a<sub>7</sub>, a<sub>9</sub>. Sch<sub>2</sub> est constitué des gènes (attributs) a<sub>1</sub>, a<sub>7</sub>, a<sub>10</sub>.
<figure><img src="image_29.png" /><figcaption>Tableau 4-2: deux schèmes à comparer.</figcaption></figure>

Pour que ces deux schèmes puissent être comparés et donc avoir la valeur d'adaptation de Sch₂ à Sch₁, ils doivent avoir la même structure. Les deux schèmes sont donc reconstruits au vu de cette contrainte, sans pour autant perdre une information déjà présente ni gagner une information déjà absente. Ils deviennent :

<figure><img src="image_30.png" /><figcaption>Tableau 4-3: les deux schèmes uniformisés.</figcaption></figure>

Le '0' permet de dire 'attention! Ce gène n'est pas présent dans le schème!'. La valeur d'adaptation de Sch₂ est : Va(Sch₂)= 2/3. L'interprétation de cette valeur est :

- 2 : représente le nombre de gènes présent dans Sch₁ et présent également dans Sch₂. Il s'agit des gènes a₁ et a₇.

- 3 : représente le nombre de gènes réellement spécifiés dans Sch₁. Il s'agit des gènes a₁, a₇ et a₉.

Il est également important de noter qu'au vu de l'importance du GF, la comparaison de ce dernier diffère de celles des GH et GS présents dans les schèmes permanents. En effet, pour que deux entités puissent être comparées, il faut qu'il y ait une concordance entre leur GF respectif. Donc deux schèmes voient d'abord leurs GF comparés et l'adaptation doit être totale. Les autres gènes sont ensuite comparés grâce à la fonction d'adaptation présentée ci-dessus.

### 4.3.7. Distance Sémantique

La distance sémantique d.s permet de calculer l'écart qu'il y a entre un schème émergent et les schèmes permanents sélectionnés. La d.s est utile pour trouver l'endroit où insérer la structure conceptuelle véhiculée par le schème émergent au sein d'une hiérarchie de classes d'une population. La distance sémantique est calculée avec la même fonction d'adaptation que celle utilisée pour calculer la valeur d'adaptation.
Plus un schème permanent est proche du schème émergent, plus la classe qui lui est associée a des chances de devenir une super-classe de la structure conceptuelle véhiculée par le schème émergent.

Nous définissons la distance sémantique comme une première mesure structurelle simple. Elle peut être évaluée rapidement et automatiquement. Elle présente également l'avantage de s'appliquer directement sur la structure des entités comparées. Nous la considérons comme une mesure de base nécessaire aux processus d'évolution.

Nous abordons maintenant la classification et l'utilisation des opérateurs :

### 4.3.8. Classification et utilisation des opérateurs

#### 4.3.8.1. Classification des opérateurs

Nous classifions les opérateurs selon leur action :

<table><caption>Tableau 4-4 : Classification des opérateurs objets</caption><thead><tr><th></th><th>Produit<br>Opérateur</th><th>Schème</th><th>Gène</th></tr></thead><tbody><tr><td rowspan="2">Pas de<br>modification</td><td>Sélection</td><td>S'appuie sur l'adaptation d'un schème à un autre par calcul de la Va</td><td>-</td></tr><tr><td>Reproduction</td><td>Agit sur une classe pour en créer une instance</td><td>-</td></tr><tr><td rowspan="2">Modification</td><td>Croisement</td><td>Agit sur deux schèmes pour les croiser et transmettre leurs gènes dans deux schèmes enfants</td><td>Transmission<br>des gènes</td></tr><tr><td>Mutation</td><td>Agit sur un gène pour changer sa valuation</td><td>Modifie un<br>gène</td></tr></tbody></table>

Ce tableau met en évidence l'action de chaque opérateur selon qu'il modifie ou non l'entité concernée. Il apparaît que la sélection et la reproduction ne modifient pas le code génétique, alors que le croisement et la mutation le font. Le croisement modifie la population de croisement en créant deux nouveaux schèmes à partir de deux schèmes parents, qu'ils remplacent dans la population. La mutation agit sur un gène pour permettre d'acquérir (1) ou de perdre (0) un gène spécifique. Cela modifie donc la structure du schème contenant ce gène.
### 4.3.8.2. Utilisation des opérateurs

Les opérateurs définis sont utilisés durant les processus d'évolution. L'illustration de leur utilisation respective est abordée dans la section 4.4 - qui présente les automates associés à chaque phase ainsi que les différentes étapes, le tout ponctué par des illustrations de leur déroulement sur des exemples simples. Avant cela, et afin d'en donner un aperçu général, nous situons dans le tableau suivant l'utilisation des opérateurs pour chaque phase :

<table><caption>Tableau 4-5: Utilisation des opérateurs durant les phases des processus d'évolution.</caption><thead><tr><th rowspan="2">Opérateur</th><th rowspan="2">Extraction</th><th rowspan="2">Exploration</th><th colspan="2">Exploitation</th></tr><tr><th>Développement</th><th>Émergence</th></tr></thead><tbody><tr><td>Sélection</td><td></td><td>x</td><td>x</td><td>x</td></tr><tr><td>Reproduction</td><td></td><td></td><td>x</td><td>x</td></tr><tr><td>Croisement</td><td></td><td></td><td></td><td>x</td></tr><tr><td>Mutation</td><td></td><td></td><td>x</td><td>x</td></tr><tr><td>Valeur d'Adaptation</td><td></td><td>x</td><td>x</td><td>x</td></tr><tr><td>Distance Sémantique</td><td></td><td></td><td>x</td><td>x</td></tr></tbody></table>

Les opérateurs ne sont pas tous utilisés en même temps dans une même phase, mais au fur et à mesure que leur besoin est ressenti.

## 4.4 - Les trois phases de tout processus d'évolution : Les automates

Nous présentons en premier l'exemple qui est utilisé à titre illustratif tout au long des processus d'évolution. Il permet de mettre en exergue le déroulement des étapes de chacune des trois phases. Ensuite, chaque phase est présentée au travers de ce qu'elle prend en entrée, de ce qu'elle produit en sortie, ainsi que son automate qui montre les différentes étapes. Les automates sont représentés grâce au formalisme des états-transitions présenté en section 4.1.2.
### 4.4.1. L'exemple

Considérons les instances suivantes, de la population Membre-Université déjà introduite dans le chapitre 3, dans leur état initial :

<table><caption>Tableau 4-6: l'état initial des instances de l'exemple.</caption><thead><tr><th rowspan="2"></th><th rowspan="2"></th><th colspan="3">Instances de Eleve-Chercheur</th><th colspan="2">Instances d'Ater</th></tr><tr><th>O<sub>1</sub></th><th>O<sub>2</sub></th><th>O<sub>3</sub></th><th>O<sub>4</sub></th><th>O<sub>5</sub></th></tr></thead><tbody><tr><td rowspan="10">GF</td><td>Num-Identification</td><td>#3</td><td>#8</td><td>#4</td><td>#7</td><td>#1</td></tr><tr><td>Nom</td><td>N1</td><td>N2</td><td>N3</td><td>N4</td><td>N5</td></tr><tr><td>Prénom</td><td>P1</td><td>P2</td><td>P3</td><td>P4</td><td>P5</td></tr><tr><td>Thème-Recherche</td><td>Auto</td><td>Math</td><td>Info</td><td>Contraintes</td><td>EIAO</td></tr><tr><td>Laboratoire</td><td>L1</td><td>L2</td><td>L3</td><td>L4</td><td>L5</td></tr><tr><td>Nbr-Publications</td><td></td><td>1</td><td>4</td><td>3</td><td></td></tr><tr><td>Spécialité</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Modules</td><td></td><td></td><td></td><td>RO</td><td>GL</td></tr><tr><td>Durée</td><td>4</td><td>3</td><td>2</td><td>1</td><td>1</td></tr><tr><td>Date-début</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Nbr-heures</td><td></td><td></td><td></td><td>88</td><td>96</td></tr><tr><td>Année</td><td></td><td>1<sup>ère</sup></td><td>2<sup>ème</sup></td><td>3<sup>ème</sup></td><td></td><td></td></tr><tr><td>Directeur-Thèse</td><td></td><td>Dupont</td><td>Durant</td><td>Dupond</td><td></td><td></td></tr><tr><td>Equipe-Recherche</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Projet-Recherche</td><td></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

Chacune de ces instances a la structure définie par sa classe d'appartenance ($O_1$, $O_2$ et $O_3$ sont des instances de la classe Eleve-Chercheur ; $O_4$ et $O_5$ sont des instances de la classe Ater). Le Tableau 4-6 met en évidence les attributs du patrimoine génétique valués par ces instances. Ces dernières non seulement évoluent dans leur structure initiale mais introduisent en plus de nouveaux attributs :
<table><caption>Tableau 4-7: les instances dans leur nouvel état.</caption><thead><tr><th colspan="2">Patrimoine Génétique</th><th colspan="5">Les instances deviennent</th></tr><tr><th></th><th></th><th>O<sub>1</sub></th><th>O<sub>2</sub></th><th>O<sub>3</sub></th><th>O<sub>4</sub></th><th>O<sub>5</sub></th></tr></thead><tbody><tr><td rowspan="10">GF</td><td>Num-Identification</td><td>#3</td><td>#8</td><td>#4</td><td>#7</td><td>#1</td></tr><tr><td>Nom</td><td>N1</td><td>N2</td><td>N3</td><td>N4</td><td>N5</td></tr><tr><td>Prénom</td><td>P1</td><td>P2</td><td>P3</td><td>P4</td><td>P5</td></tr><tr><td>Thème-Recherche</td><td>Auto</td><td>- Math</td><td>Objet</td><td>Contraintes</td><td>Objet</td></tr><tr><td>Laboratoire</td><td>L1</td><td>- L2</td><td>L3</td><td>L1</td><td>L5</td></tr><tr><td>Nbr-Publications</td><td></td><td>- 1</td><td>4</td><td>6</td><td></td></tr><tr><td>Spécialité</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Modules</td><td></td><td></td><td></td><td></td><td>CSI</td></tr><tr><td>Durée</td><td></td><td>- 4</td><td>- 3</td><td>- 2</td><td>1</td><td>- 1</td></tr><tr><td>Date-début</td><td></td><td>+ 01-10-2000</td><td></td><td>+ 01-10-2000</td><td></td><td>+01-09-2000</td></tr><tr><td>Nbr-heures</td><td></td><td></td><td></td><td></td><td>- 88</td><td>- 96</td></tr><tr><td>Année</td><td></td><td>- 1<sup>ère</sup></td><td>- 2<sup>ème</sup></td><td>- 3<sup>ème</sup></td><td></td><td></td></tr><tr><td>Directeur-Thèse</td><td></td><td>- Dupont</td><td>- Durant</td><td>- Dupond</td><td></td><td></td></tr><tr><td>Equipe-Recherche</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Projet-Recherche</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td rowspan="5">Nouveaux attributs</td><td>Grade</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Poste</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Responsabilité</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Responsable</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td></td><td></td><td></td><td></td><td></td><td>++ Mr X</td></tr></tbody></table>

<table><tr><td>Avec :</td><td>Attribut : attribut existant</td></tr><tr><td></td><td>- attribut : attribut perdu</td></tr><tr><td></td><td>+ attribut : attribut acquis</td></tr><tr><td></td><td>++ attribut : nouvel attribut</td></tr></table>

Ainsi, les instances gardent certains attributs (représentés par attribut), en perdent d'autres (représentés par attribut), acquièrent des attributs déjà existants dans le patrimoine génétique de la population (représentés par attribut) et en introduisent de nouveaux (représentés par ++ attribut). Ces derniers ont donc le statut transitoire (confère chapitre 3).

### 4.4.2. Notion d'invariant

Lorsque le concepteur fait évoluer les instances, il peut agir sur deux types d'attributs : les attributs existants et les nouveaux attributs. Pour chaque attribut existant, il peut exprimer une des possibilités suivantes :

- Un attribut existant et obligatoire est représenté par un 1 dans le schème associé à l'instance ;

- Un attribut non désiré est représenté par un 0 dans le schème associé à l'instance ;

- Un attribut indifférent n'est pas représenté ou est représenté par un # dans le schème associé à l'instance.
Ainsi, les deux premières éventualités (présence obligatoire ou absence obligatoire) sont des *contraintes* ou des *invariants* qu'exprime le concepteur sur ce qu'il veut ou ne veut pas voir apparaître sur son instance, donc dans la structure conceptuelle finale. Par exemple, l'attribut *Date-début* et l'attribut *Durée* sont considérés comme contradictoires. Le premier exprime la date d'embauche d'un permanent, alors que le second exprime la durée du contrat d'un temporaire. Ces attributs caractérisent respectivement un permanent et un temporaire. Ainsi, le concepteur a exprimé que les objets O₁, O₃ et O₅ ont évolué et valuent, entre autre, l'attribut *Date-début*. Ces objets ne peuvent plus valuer l'attribut *Durée*, étant donné qu'ils sont contradictoires. Autrement une exception est levée.

Cet invariant peut avoir été exprimé dans le modèle ou, s'il en est absent, il peut être exprimé sur l'instance par le concepteur. Le processus d'évolution doit respecter cet invariant.

Nous abordons maintenant en détails chaque phase :

### 4.4.3. Phase d'extraction

La phase d'extraction est définie en section 4.2.2. Son automate est décrit ci-après :

#### 4.4.3.1. Automate

L'automate représentant les différentes étapes de la phase présente en entrée et en sortie les évènements suivants :

- **En entrée** : l'instance ayant évolué dans son nouvel état.

- **En sortie** : le schème temporaire associé ; les attributs nouveaux créés avec un statut transitoire au sein du patrimoine génétique.

- **Corps de l'automate** : le cas d'une simple modification de valeurs de l'objet qui respecte toujours la définition de sa classe ne nécessite aucun traitement. Le cas qui nous intéresse est celui de modification de la structure de l'objet (ajout ou retrait d'attributs). L'automate se déroule pour chaque instance ayant évolué :
<figure><img src="image_31.png" /><figcaption>Figure 4-4. Étapes de la phase d'Extraction</figcaption></figure>

Les attributs rajoutés au sein de l'objet peuvent être :

- déjà définis par d'autres classes du modèle, donc déjà présents dans le patrimoine génétique ;

- être nouvellement introduits par l'objet modifié ou encore ce dernier perd quelques attributs (il ne les value donc plus).

Dans le cas de nouveaux attributs introduits, le concepteur provoque en fait la création de ces attributs lorsqu'il modifie l'objet. Lorsqu'un attribut est créé par le concepteur durant la modification de la structure d'une instance, le système crée l'attribut en positionnant son statut à l'état transitoire.

Les attributs sont donc analysés, et le schème temporaire est créé au fur et à mesure. Pour chaque attribut, quatre cas de figures sont possibles :

1. L'attribut existe déjà et reste dans l'instance : le gène correspondant est défini dans le schème temporaire de la même manière qu'il l'est dans le schème permanent de la classe d'appartenance initiale de l'instance ;

2. L'attribut est acquis et est déjà existant dans le P.G (Patrimoine Génétique) de la population, mais n'est pas défini dans sa classe d'appartenance initiale : le processus en extrait la référence dans le gène correspondant. Sa valuation est par défaut à #. Elle est soumise à la validation ou à la modification du concepteur (qui peut éventuellement la faire muter) ;
3. L'attribut est nouvellement introduit par l'instance (par le biais du concepteur). Cet attribut doit donc être créé. Il aura un statut transitoire. Sa valuation est par défaut égale à 1. Son intégration complète dans le P.G. au même titre que les autres attributs (ou son rejet) devient effective (effectif) à la fin du processus d'évolution ;

4. L'attribut n'est plus valué par l'instance : le gène correspondant est mis à 0, mais il n'est en aucun cas supprimé du P.G.

Ainsi, au fur et à mesure que l'état des attributs de l'instance est détecté, le schème temporaire est construit. Chaque gène détient la référence de l'attribut représenté du patrimoine génétique et sa valuation (1, 0 ou #). A la fin de la phase, le schème temporaire est créé. Les éventuels nouveaux attributs également l'auront été.

Une fois le schème temporaire ainsi construit, il est soumis à la validation du concepteur. Ce dernier peut changer, au vu de ses besoins, les situations 2 et 3 car les gènes présentent des valuations par défaut.

### 4.4.3.2. Exemple

Les schèmes temporaires des instances ayant évolué sont :

<table><caption>Tableau 4-8: résultat de la phase d'extraction: les schèmes temporaires</caption><thead><tr><th></th><th>Patrimoine Génétique</th><th colspan="5">Les schèmes temporaires sont</th></tr><tr><th></th><th></th><th>O<sub>1</sub></th><th>O<sub>2</sub></th><th>O<sub>3</sub></th><th>O<sub>4</sub></th><th>O<sub>5</sub></th></tr></thead><tbody><tr><th rowspan="10">GF</th><th>Num-Identification</th><td>1</td><td>1</td><td>1</td><td>1</td><td>1</td></tr><tr><th>Nom</th><td>1</td><td>1</td><td>1</td><td>1</td><td>1</td></tr><tr><th>Prénom</th><td>1</td><td>1</td><td>1</td><td>1</td><td>1</td></tr><tr><th>Thème-Recherche</th><td>1</td><td>0</td><td>1</td><td>1</td><td>1</td></tr><tr><th>Laboratoire</th><td>1</td><td>0</td><td>1</td><td>1</td><td>1</td></tr><tr><th>Nbr-Publications</th><td>#</td><td>0</td><td>1</td><td>1</td><td>#</td></tr><tr><th>Spécialité</th><td>#</td><td>0</td><td>0</td><td>#</td><td>#</td></tr><tr><th>Modules</th><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td></tr><tr><th>Durée</th><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td></tr><tr><th>Date-début</th><td>1</td><td>0</td><td>1</td><td>0</td><td>1</td></tr><tr><th>Nbr-heures</th><td>0</td><td>0</td><td>#</td><td>0</td><td>0</td></tr><tr><th>Année</th><td>0</td><td>0</td><td>0</td><td>#</td><td>0</td></tr><tr><th>Directeur-Thèse</th><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr><tr><th>Equipe-Recherche</th><td>1</td><td>0</td><td>1</td><td>#</td><td>#</td></tr><tr><th>Projet-Recherche</th><td>#</td><td>0</td><td>#</td><td>#</td><td>#</td></tr><tr><th rowspan="4">Nouveaux attributs</th><th>Grade</th><td>1</td><td></td><td></td><td></td><td></td></tr><tr><th>Poste</th><td></td><td>1</td><td></td><td></td><td></td></tr><tr><th>Responsabilité</th><td></td><td></td><td>1</td><td></td><td></td></tr><tr><th>Responsable</th><td></td><td></td><td></td><td>1</td><td></td></tr></tbody></table>

Nous remarquons que chaque schème temporaire représentant un objet diffère du schème permanent de la classe d'appartenance initiale du même objet.

Une fois les schèmes temporaires spécifiés, la phase d'exploration est déclenchée.
### 4.4.4. Phase d'exploration

La phase d'exploration est définie en section 4.2.3. La spécification du schème temporaire obtenu à la fin de la phase d'extraction déclenche la phase d'exploration. La phase se déroule sur chaque schème temporaire :

#### 4.4.4.1. Automate

L'automate représentant les différentes étapes de la phase présente en entrée et en sortie les évènements suivants :

- **En entrée** : le schème temporaire issu de la phase d'extraction.

- **En sortie** : le schème temporaire, les classes sélectionnées (y compris leur schème permanent).

- **Corps de l'automate** :

<figure><img src="image_32.png" /></figure>
<caption>Figure 4-5. Étapes de la phase d'Exploration</caption>

L'exploration se déroule en deux principales étapes :

– L'exploration commence par explorer l'ensemble des populations spécifiées. Le but est de rechercher à quelle population le schème temporaire pourrait appartenir. La comparaison se fait donc entre le Génotype Fondamental du schème temporaire et le Génotype Fondamental représentant une population. Chaque population est passée en revue, en commençant par la population initiale. L'adaptation entre les GF doit être totale. Une fois la population sélectionnée (initiale ou autre), la seconde étape est déroulée. Nous soulignons à ce niveau, que le concepteur peut amorcer la création d'une nouvelle population s'il définit un GF totalement nouveau sur l'instance. Cela ne fait pas partie du cadre actuel de notre étude.

– L'exploration se poursuit en explorant les classes appartenant à cette population, en recherchant cette fois l'adaptation des différentes classes. La valeur d'adaptation Va de chacune est calculée. Il est important de noter que les nouveaux attributs (marqués transitoires) ne sont pas concernés dans la sélection étant donné qu'aucune classe ne les détient. De plus, le GF n'intervient pas dans le calcul de l'adaptation des classes étant donné qu'il est identique pour chacune d'entre elles. Il permet, lors de l'exploration, uniquement de sélectionner les populations, et il n'est pas utilisé au sein d'une même population.

Une fois l'exploration menée à terme, les Va (valeurs d'adaptation) sont analysées afin de détecter quel type d'évolution doit être exécutée. Cela déclenche la phase d'exploitation.

### 4.4.4.2. Exemples

Nous remarquons (Tableau 4-8) que pour chaque objet, le schème temporaire associé détient toujours le même GF que la population d'appartenance initiale. La première conclusion est que tous les objets doivent a priori rester dans la même population de Membre-Université. L'exploration est alors menée pour chaque schème temporaire dans cette même population. Nous rappelons qu'à cette étape, le GF et les nouveaux attributs ne sont pas considérés. Les seuls gènes considérés sont généralement définis de façon plus ou moins différentes au sein des Génotypes Hérités (GH) et des Génotypes Spécifiques (GS) des classes.

Nous présentons pour chaque objet ayant évolué, l'adaptation, donc la Va, de chaque classe de la population Membre-Université au schème permanent.

#### 1) - Objet O₁

* Exploration
<table><caption>Tableau 4-9 : exploration de classes pour O<sub>1</sub>.</caption><thead><tr><th>Entité</th><th colspan="10">Schèmes Temporaire et Permanents</th><th>Va</th></tr><tr><th>Objet O<sub>1</sub></th><th>1</th><th>1</th><th>#</th><th>#</th><th>1</th><th>0</th><th>1</th><th>0</th><th>0</th><th>0</th><th>1</th><th>#</th></tr></thead><tbody><tr><th>Membre-Université</th><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0/5</td></tr><tr><th>Chercheur</th><td>1</td><td>1</td><td>#</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>2/5</td></tr><tr><th>Enseignant</th><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td><b>1/5</b></td></tr><tr><th>Temporaire</th><td>1</td><td>1</td><td>#</td><td>0</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>2/5</td></tr><tr><th>Permanent</th><td>1</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>3/5</td></tr><tr><th>Ater</th><td>1</td><td>1</td><td>#</td><td>0</td><td>1</td><td>1</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td><b>3/5</b></td></tr><tr><th>Eleve-Chercheur</th><td>1</td><td>1</td><td>#</td><td>0</td><td>0</td><td>1</td><td>0</td><td>0</td><td>1</td><td>1</td><td>0</td><td>0</td><td><b>2/5</b></td></tr><tr><th>Senior-Chercheur</th><td>1</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>#</td><td><b>4/5</b></td></tr></tbody></table>

Ainsi, les différents blocs de gènes sont représentés graphiquement par :

Génotype Hérité ☐ et Génotype Spécifique ☐

L'objet O<sub>1</sub> a :

- 5 gènes spécifiés (gènes à 1),

- 3 gènes indifférents (gènes à #),

- 4 gènes obligatoirement absents (gènes à 0).

L'adaptation nulle de Membre-Université est logique étant donné qu'elle représente la population et ne détient que le GF qui est ignoré à ce niveau. L'adaptation de cette classe est la même pour tous les autres objets.

- L'adaptation de chaque classe de la hiérarchie est mise en évidence par :

<figure><img src="image_33.png" /><figcaption>Figure 4-6: adaptation des classes à O<sub>1</sub>.</figcaption></figure>

Conclusion : quatre classes sont partiellement adaptées.
## 2) - Objet O₂

* Exploration

<table><caption>Tableau 4-10: exploration de classes pour O₂.</caption><thead><tr><th>Entité</th><th colspan="10">Schèmes Temporaire et Permanents</th><th>Va</th></tr></thead><tbody><tr><td>Objet O₂</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr><tr><td>Membre-Université</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr><tr><td>Chercheur</td><td>1</td><td>1</td><td>#</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr><tr><td>Enseignant</td><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr><tr><td>Temporaire</td><td>1</td><td>1</td><td>#</td><td>0</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr><tr><td>Permanent</td><td>1</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td></tr><tr><td>Ater</td><td>1</td><td>1</td><td>#</td><td>0</td><td>1</td><td>1</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td></tr><tr><td>Eleve-Chercheur</td><td>1</td><td>1</td><td>#</td><td>0</td><td>0</td><td>1</td><td>0</td><td>0</td><td>1</td><td>1</td><td>0</td></tr><tr><td>Senior-Chercheur</td><td>1</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td></tr></tbody></table>

* L'adaptation de chaque classe de la hiérarchie est mise en évidence par :

<figure><img src="image_34.png" /><figcaption>Figure 4-7: adaptation des classes à O₂.</figcaption></figure>

*Conclusion : aucune classe ne présente d'adaptation.*

## 3) - Objet O₃

* Exploration
<table><caption>Tableau 4-12: exploration de classes pour O<sub>4</sub>.</caption><thead><tr><th>Entité</th><th colspan="12">Schèmes Temporaire et Permanents</th><th>Va</th></tr><tr><th>Objet O<sub>4</sub></th><th>1</th><th>1</th><th>1</th><th>#</th><th>0</th><th>1</th><th>0</th><th>0</th><th>#</th><th>0</th><th>#</th><th>#</th><th></th></tr></thead><tbody><tr><td>Membre-Université</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0/4</td></tr><tr><td>Chercheur</td><td>1</td><td>1</td><td>#</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>3/4</td></tr><tr><td>Enseignant</td><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0/4</td></tr><tr><td>Temporaire</td><td>1</td><td>1</td><td>#</td><td>0</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>4/4</td></tr><tr><td>Permanent</td><td>1</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>3/4</td></tr><tr><td>Ater</td><td>1</td><td>1</td><td>#</td><td>0</td><td>1</td><td>1</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>4/4</td></tr><tr><td>Eleve-Chercheur</td><td>1</td><td>1</td><td>#</td><td>0</td><td>0</td><td>1</td><td>0</td><td>0</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>4/4</td></tr><tr><td>Senior-Chercheur</td><td>1</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>1</td><td>#</td><td>3/4</td></tr></tbody></table>

* L'adaptation de chaque classe de la hiérarchie est mise en évidence par :

<figure><img src="image_35.png" /><figcaption>Tableau 4-13: adaptation des classes à O<sub>4</sub>.</figcaption></figure>

Conclusion : trois classes sont pleinement adaptées.

5) - Objet O<sub>5</sub>

* Exploration
<table><caption>Tableau 4-16: résultats de l'exploration.</caption><tr><td>O<sub>4</sub></td><td>Trois classes pleinement adaptées</td><td>Temporaire, Ater, Eleve-Chercheur</td></tr><tr><td>O<sub>5</sub></td><td>Quatre classes partiellement adaptées</td><td>Enseignant, Ater, Eleve-Chercheur, Senior-Chercheur</td></tr></table>

Ces résultats permettent de mener à terme la troisième et dernière phase : l'exploitation.

### 4.4.5. Phase d'exploitation

La phase d'exploitation est définie en section 4.2.4. La phase d'exploitation permet de déclencher le processus de développement ou d'émergence. Pour savoir lequel des processus est mis en marche, elle s'appuie sur les résultats de la phase d'exploration. L'algorithme présenté ci-après précise les différentes étapes suivies et celles qui suivront au vu des résultats obtenus jusque là :
**Si** GF(instance) = GF(Population i)

**Alors** les classes de la population i sont considérées. Le GF n'est plus pris en compte
dans la suite du processus

**Si** un schème permanent a une Va=1

**Alors** émergence locale dans sa classe :

+ intégration de l'instance dans son nouvel état

+ adaptation de cette instance à sa nouvelle classe par éventuel ajout de la
différence dans les attributs

+ adaptation si nécessaire des instances existantes

+ répercussion sur les sous-classes et leurs instances

**Sinon**

**Si** plusieurs schèmes ont une Va=1

**Alors**

- 1er *cas* : la Va de la racine d'une sous-branche de la hiérarchie est égale à 1 ainsi que ses sous-classes : l'instance exprime une variante de cette même racine. Cette dernière est généralement abstraite. La structure émergeant de l'instance est proposée comme une sous-classe de cette racine

- 2ème *cas* : des classes disjointes ayant une Va=1 porte à penser qu'il y a un problème de conception.

**Sinon** des Va sont strictement comprises entre 0 et 1 : croisement :

Constitution de la population de départ avec tous les schèmes partiellement adaptés et significatifs.

- Adapté : 0<Va<1

- *Significatif* : dans une même sous-branche de la hiérarchie, la classe la plus adaptée est sélectionnée. Pourquoi ? Étant donné que se sont des spécialisations d'une même classe, elles détiennent une partie commune. Il est inutile et redondant de la dupliquer, mais il est préférable de sélectionner la sous-classe la plus adaptée.

<caption>Tableau 4-17 : l'algorithme permettant d'exploiter, dans un premier temps, les résultats de la phase d'exploration.</caption>

### 4.4.5.1. Automates

Les différents automates que nous définissons pour les processus d'évolution ont tous
les mêmes entités en entrée et l'achèvement de l'évolution en sortie :

- **En entrée** : les schèmes émergents, en plus des entités déjà présentes : les schèmes temporaires, les schèmes permanents, le patrimoine génétique.

- **En sortie** : l'évolution achevée, c'est-à-dire :

La classe à modifier en cas d'émergence locale ;

La ou les nouvelles structures conceptuelles à insérer et son ou leur emplacement
dans la hiérarchie en cas d'émergence globale.
– **Corps de l'automate** : nous définissons un automate par type de processus d'évolution. Ils sont explicités séparément dans ce qui suit.

Nous présentons en premier lieu le constat des résultats obtenus jusque là suite à
l'exécution des deux premières phases :

4.4.5.2. Exemple

– *Conclusion O*₁: des classes partiellement adaptées. Le processus d'évolution adéquat est l'émergence globale par croisement.

– *Conclusion O*₂: aucune classe ne présente d'adaptation. Le processus d'évolution adéquat est l'émergence globale par création directe de la structure conceptuelle.

– *Conclusion O*₃: une seule classe pleinement adaptée et l'objet *O*₃ introduit de nouveaux gènes. Le processus d'évolution adéquat est:

- *l'émergence locale* au sein de la classe qui est pleinement adaptée si cette dernière n'est pas une classe abstraite;

- *l'émergence globale par création directe* de la structure conceptuelle comme sous-classe de la classe pleinement adaptée si cette dernière est abstraite.

– *Conclusion O*₄: trois classes pleinement adaptées et l'objet *O*₄ introduit de nouveaux gènes. Le processus d'évolution adéquat est :

- *l'émergence locale* au sein de la classe qui est pleinement adaptée si cette dernière n'est pas une classe abstraite;

- *l'émergence globale par création directe* de la structure conceptuelle comme sous-classe de la classe pleinement adaptée si cette dernière est abstraite.

– *Conclusion O*₅: des classes partiellement adaptées. Le processus d'évolution adéquat est l'émergence globale par croisement.

En résumé :
<table><caption>Tableau 4-18: Processus d'évolution pour chaque objet.</caption><thead><tr><td>Objet</td><td>Résultat de l'exploration</td><td>Processus d'évolution adéquat</td></tr></thead><tbody><tr><td>O<sub>1</sub></td><td>Quatre classes partiellement adaptées</td><td>Émergence globale par croisement des classes partiellement adaptées</td></tr><tr><td>O<sub>2</sub></td><td>Aucune classe adaptée</td><td>Émergence globale par création directe de la structure conceptuelle</td></tr><tr><td>O<sub>3</sub></td><td>Une seule classe pleinement adaptée</td><td>Émergence locale ou Émergence Globale directe</td></tr><tr><td>O<sub>4</sub></td><td>Trois classes pleinement adaptées</td><td>Émergence locale ou Émergence Globale directe</td></tr><tr><td>O<sub>5</sub></td><td>Quatre classes partiellement adaptées</td><td>Émergence globale par croisement des classes partiellement adaptées</td></tr></tbody></table>

Ces différents processus sont présentés ci-après. Nous présentons la politique adoptée pour le processus de développement en section 4.6 - .

## 4.5 - L'émergence

Nous distinguons les automates en définissant un automate par type d'émergence : l'émergence locale et l'émergence globale. Cette dernière distingue deux automates : celui de l'émergence globale directe et celui de l'émergence globale par croisement.

### 4.5.1. L'émergence locale

L'émergence locale permet de faire émerger des gènes nouvellement introduits dans une ou plusieurs classes pleinement adaptées. En effet, aussi bien pour l'objet $O_3$ que $O_4$, des classes ont leur $Va=1$, mais cette adaptation est valable uniquement sur les gènes déjà existants. Elle ne concerne pas les nouveaux gènes. Ces derniers, après que le concepteur accepte de mener une émergence locale, doivent émerger au sein de ces classes, avant que l'objet correspondant ne lui soit rattaché.

#### 4.5.1.1. L'automate

L'automate représentant les différentes étapes de la phase :
<figure><img src="image_36.png" /><figcaption>Figure 4-9. Étapes de l'Émergence Locale</figcaption></figure>

L'émergence locale permet de faire évoluer la classe existante dans le modèle et qui est
adaptée à l'instance pour lui permettre de prendre en compte les nouveaux attributs
présents dans l'instance. Pour cela, la classe doit évoluer pour s'adapter pleinement.
L'instance doit également s'adapter à sa nouvelle classe le cas échéant. Ainsi, outre les
attributs qui émergent dans la classe, l'instance doit prendre les attributs de la classe et
qu'elle ne détient pas.

Le concepteur doit également s'assurer de la complétude du schème permanent. En
effet, ce dernier prend par défaut les valuations mentionnées dans le schème
temporaire pour les nouveaux attributs. Le schème permanent est soumis à la
validation du concepteur. Les instances de la classe doivent s'adapter. Cela se fera au
travers du processus de développement (section 4.6 - ). La dualité classe/instance est à
nouveau respectée dans un état stable du modèle (Figure 4-1).

4.5.1.2. L'exemple

Pour les objets O₃ et O₄, le processus d'émergence peut a priori être soit de l'émergence locale soit de l'émergence globale par création directe de la structure conceptuelle. Analysons les deux cas :
* **Objet O<sub>3</sub>**: Senior-Chercheur est la seule classe ayant une Va adaptée à l'objet O<sub>3</sub>. De plus, cette classe peut avoir des instances. Il s'agit donc d'émergence locale. L'objet O<sub>3</sub> est proposé comme instance de Senior-Chercheur, moyennant l'émergence locale du nouvel attribut *Responsabilité* introduit par l'instance, dans cette classe. Le lien d'évolution (introduit dans le chapitre 4 et traité en détails dans la section 4.7 - ) est créé de la classe initiale de l'objet O<sub>3</sub>, à savoir Eleve-Chercheur vers la nouvelle classe de l'objet O<sub>3</sub>, à savoir Senior-Chercheur. L'objet lui est rattaché.

* **Objet O<sub>4</sub>**: trois classes ont une Va égale à 1. Les classes correspondantes sont donc en mesure d'être ou de contenir la structure conceptuelle sous-jacente à l'instance, donc l'instance à proprement parler. Laquelle choisir ? Des trois classes, la classe *Temporaire* est la plus éligible car elle représente la racine de la sous-population des temporaires. C'est une classe abstraite et elle est utilisée pour factoriser des caractéristiques communes à ses différentes sous-classes. Elle ne peut donc pas contenir l'instance O<sub>4</sub>. Celle-ci représente une nouvelle catégorie de temporaire et introduit un nouvel attribut. Il ne s'agit donc pas d'émergence locale mais d'émergence globale directe. L'exemple doit donc être traité dans ce cadre (section 4.5.2.1).

## 4.5.2. L'émergence globale

L'émergence globale concerne l'émergence d'une nouvelle structure conceptuelle. Celle-ci peut être une simple structure conceptuelle représentée par une classe ou une association entre deux classes, ou une structure conceptuelle plus complexe, représentée par des classes liées entre elles. Cela est le cas des objets complexes. Nous nous intéresserons principalement à l'émergence de structures conceptuelles simples.

Il existe deux principaux types d'émergence : l'émergence globale par création directe de la structure conceptuelle, que nous qualifions également d'émergence directe, et l'émergence globale par croisement.

### 4.5.2.1. L'émergence directe

L'émergence globale directe revient à extraire la spécification d'une nouvelle structure conceptuelle directement d'une instance. Elle est adaptée pour les situations suivantes :

- Aucune classe n'est adaptée à une instance et cette dernière appartient tout de même à la population ;

- La classe qui est adaptée est une classe abstraite. Cette situation porte à croire que l'instance exprime une nouvelle structure conceptuelle de cette classe.
## 1) - L'automate

La phase s'applique pour une instance. L'automate représentant les différentes étapes de la phase est :

<figure><img src="image_37.png" /><figcaption>Figure 4-10. Étapes de l'Émergence Globale Directe.</figcaption></figure>

L'objectif de cet automate est de détecter l'emplacement de la nouvelle structure conceptuelle dans la hiérarchie de la population :

Soit aucune classe n'est adaptée, auquel cas cela revient à créer la structure conceptuelle comme une sous-classe de la classe racine de la hiérarchie. Dans ce cas, outre le GF qui reste inchangé, les nouveaux attributs sont intégrés dans le P.G en perdant leur statut transitoire. Ils constituent le GS de la structure conceptuelle. Il n'y a pas de GH dans la structure.

Soit la classe adaptée est une classe abstraite, auquel cas cela revient à créer la structure conceptuelle comme une sous-classe de la classe abstraite adaptée. Dans ce cas, outre le GF qui reste inchangé, les nouveaux attributs sont intégrés dans le P.G en perdant leur statut transitoire. Ils constituent le GS de la structure conceptuelle. Le GS de la super-classe est hérité par la classe nouvellement créée et constitue ainsi son GH.
Le résultat final est soumis au concepteur pour validation. Il lui est également demandé de compléter la structure conceptuelle en spécifiant les méthodes qui invoquent ces attributs (section 4.5.3). Celui-ci doit valider et compléter selon ses besoins les spécifications de la structure conceptuelle.

## 2) - Les exemples

* *Objet O₂ : émergence globale par création directe de la structure conceptuelle - lieu d'insertion?* Dans ce cas, la structure n'a rien de commun avec les autres classes sauf le GF. Elle appartient donc à la même population. Elle sera donc créée comme sous-classe de Membre-Université, car le GF est le seul point commun avec la population. L'attribut *Poste* introduit par l'instance fait maintenant partie intégrante du PG. Cet attribut constitue le GS de la nouvelle classe. Il est valué par la valeur 'Ingénieur'. Cette structure conceptuelle représente une nouvelle catégorie de Membre-Université, à savoir celle d'Ingénieur. L'objet O₂ lui est rattaché. Un lien d'évolution (confère section 4.7 - ) est créé de sa classe d'appartenance initiale, à savoir Eleve-Chercheur, vers sa nouvelle classe. Le résultat de l'évolution, à savoir la classe Ingénieur, est proposé au concepteur, y compris le schème permanent qui n'est autre que le schème temporaire. Il est également demandé au concepteur de spécifier les méthodes nécessaires (aussi bien dans la signature que le corps).

* *Objet O₄ : émergence globale par création directe de la structure conceptuelle - lieu d'insertion ?* Trois classes ont leur Va égale à 1. Les classes correspondantes sont donc en mesure d'être ou de contenir la structure conceptuelle sous-jacente à l'instance, donc l'instance à proprement parler. Des trois classes, la classe *Temporaire* est la plus éligible car elle représente la racine de la sous-population des temporaires. C'est une classe abstraite et elle est utilisée pour factoriser des caractéristiques communes à ses sous-classes. Elle détient les attributs de l'instance O₄, sauf les nouveaux attributs qu'elle introduit. Elle ne peut pas contenir l'instance O₄ mais peut généraliser la structure conceptuelle représentée. Celle-ci représente une nouvelle catégorie de temporaire et introduit un nouvel attribut *Responsable*. La classe correspondante est créée comme sous-classe de *Temporaire*.

L'attribut *Responsable* introduit par l'instance fait maintenant partie intégrante du PG. Cet attribut constitue le GS de la nouvelle classe. Il est valué par la valeur 'Mr X' dans l'exemple. Le GS de Temporaire est hérité par la nouvelle classe. Il constitue son GH. Cette structure conceptuelle représente une nouvelle catégorie de Membre-Université, à savoir celle de Post-Doc. L'objet O₄ lui est rattaché. Un lien d'évolution (confère section 4.7 - ) est créé de sa classe d'appartenance initiale, à savoir Ater, vers sa nouvelle classe. Le résultat de l'évolution est proposé au concepteur, à savoir la classe Post-Doc, y compris le schème permanent qui n'est autre que le schème temporaire. Il est également demandé au concepteur de spécifier les méthodes nécessaires (aussi bien dans la signature que le corps).
### 4.5.2.2. L'émergence globale par croisement

L'émergence globale par croisement est exécutée lorsque plusieurs classes sont partiellement adaptées à l'instance. Le croisement permet alors de tirer profit au maximum des propriétés définies au sein de ces classes partiellement adaptées et de l'instance. Le croisement se fait au vu des propriétés (ou gènes) présentes dans l'instance, et en respectant les contraintes et invariants présents dans le modèle.

Les classes sélectionnées voient leurs schèmes permanents constituer la population de départ pour le croisement. La population est de taille fixe tout au long du processus d'évolution. Les nouveaux schèmes remplaceront leurs parents, permettant ainsi de garder la taille de la population fixe tout en variant et changeant sa composition.

#### 1) - Définition détaillée du croisement

Deux schèmes sont choisis aléatoirement dans la population de croisement pour être croisés. Le choix de points de croisement est important. Il existe les croisements classiques dits à n-points (chapitre 3), mais l'aspect de scinder en groupes des gènes ne nous satisfait pas, car il n'y a pas de sémantique particulière dans la séparation des gènes. Nous sommes plus intéressés par une sélection aléatoire des gènes. Pour ces raisons, nous nous sommes plutôt inspirés du croisement uniforme des Algorithmes Génétiques [Syswerda 89]. Car ce type de croisement permet d'introduire de l'aléa dans le choix du gène à transmettre au descendant. Ce type de croisement permet de ne pas se confiner trop rapidement dans un même espace de solutions et permet plutôt de diversifier les descendants, donc les structures conceptuelles. Quant à l'aspect groupe de gènes, nous préférons appliquer les groupes de gènes du modèle, à savoir les GH et les GS.

Le principe du croisement uniforme est d'accorder un poids relatif à chacun des deux parents pour la transmission de gènes dans un des enfants. Nous déterminons et calculons ce poids en fonction de la valeur d'adaptation de chaque schème parent (cf. l'exemple). Afin d'uniformiser ces Va, nous pondérons ces deux Va entre elles de manière à ce que leur somme fasse 1. Nous les dénommons Vap pour Valeur d'Adaptation Pondérée. Ainsi, nous savons sans ambiguïté quel schème aura plus de chances d'influencer les générations futures. Nous considérons également que le schème parent 1 influence le schème enfant 1 et que le schème parent 2 influence le schème enfant 2.
<figure><img src="image_38.png" /><figcaption>Figure 4-11: prédominance d'un parent sur un enfant.</figcaption></figure>

Ensuite, un nombre aléatoire compris entre 0 et 1 est généré pour chaque position de gène. Ce nombre est comparé au poids du premier parent. S'il lui est inférieur, le gène du schème parent 1 est transmis à l'enfant 1 et le gène du schème parent 2 est transmis à l'enfant 2. Dans le cas contraire, la permutation de gènes est faite : c'est-à-dire que le gène du parent 1 est transmis à l'enfant 2 et le gène du parent 2 est transmis à l'enfant 1.

En notant $Vap_1$ la Va pondérée du schème parent 1 et $Vap_2$ la Va pondérée du schème parent 2, nous illustrons la procédure précédente de la manière suivante :

<figure><img src="image_39.png" /><figcaption>Figure 4-12: Transmission des gènes lors du croisement</figcaption></figure>

Cette opération de tirage aléatoire se répète jusqu'à ce que tous les gènes soient passés en revue.

Les schèmes enfants remplacent respectivement leurs parents dans la population de croisement. Une nouvelle génération est ainsi définie. Le croisement est relancé depuis le début sur cette nouvelle génération. Le critère d'arrêt est l'émergence de schèmes pleinement adaptés ou la dégradation des performances du croisement.
## 2) - La contrainte de blocs de gènes dans le croisement

Une fois le croisement fait, nous imposons une contrainte que nous qualifions de contrainte de blocs de gènes. En effet, la définition d'un attribut au sein d'une classe est plus riche sémantiquement qu'en étant défini avec le groupe d'attributs auquel il appartient. Ainsi, l'attribut *Nbr-Publications* défini dans la classe Chercheur, présente une sémantique restreinte, alors que s'il est accompagné de tous les attributs définis avec lui dans le GS, à savoir *Thème-Recherche* et *Laboratoire*, sa sémantique est plus riche. Nous imposons pour cela que les blocs de GH et de GS doivent être conservés lors d'un croisement. Cette contrainte évite surtout de retrouver au bout d'un certain nombre de croisements, des schèmes avec des structures complètement disloquées.

Pour qu'un bloc GH ou GS soit conservé, la contrainte est que si un attribut est présent dans un schème résultant d'un croisement et que ce même attribut appartient à un bloc GH ou GS de son schème parent, alors tous les attributs du bloc doivent être présents dans le schème résultant du croisement. Par contre, si aucun gène du bloc GH ou GS n'est présent dans le schème issu du croisement, les gènes du bloc ne lui sont pas imposés, mais la structure du bloc est toujours transmise aux schèmes enfants.

Comme le schème parent 1 influence le schème enfant 1 et que le schème parent 2 influence le schème enfant 2, le schème enfant 1 devra respecter les blocs GH et GS du schème parent 1 et le schème enfant 2 devra respecter les blocs GH et GS du schème parent 2.

## 3) - L'automate

L'automate représentant les différentes étapes de la phase :
<figure><img src="image_40.png" /><figcaption>Figure 4-13. Le croisement : cœur du processus d'émergence globale</figcaption></figure>

Tant qu'aucun des critères d'arrêts n'est atteint, les schèmes enfants sont introduits dans la population de croisement en remplacement de leurs parents. Une nouvelle génération est ainsi définie. Le processus de croisement reprend sur cette population.

Le critère d'arrêt est l'émergence de schèmes pleinement adaptés ou la dégradation des performances du croisement. En effet, le croisement peut aboutir à des schèmes émergents (Va=1). Le croisement se sera donc déroulé avec succès. Cependant, le processus ne peut pas durer indéfiniment si aucun schème émergeant n'apparaît. Le
critère d'arrêt peut donc être une dégradation constatée des résultats du croisement :
les schèmes obtenus sont de moins en moins adaptés.

D'autres critères d'arrêt peuvent dépendre du concepteur. L'arrêt du croisement peut être du à l'intervention du concepteur pour arrêter explicitement le croisement. L'arrêt du croisement peut également arriver si un certain nombre d'itérations autorisé est défini par le concepteur. Dans le cas où aucun schème émergeant n'apparaîtrait, les schèmes les plus adaptés sont proposés au concepteur. Celui-ci peut alors décider de faire muter quelques gènes des schèmes de façon à obtenir des schèmes pleinement adaptés. Cette mutation est entièrement laissée à la charge du concepteur.

A la fin, le schème de la nouvelle structure conceptuelle a ainsi émergé. Les parents « géniteurs » permettent de construire par blocs la nouvelle structure conceptuelle dont le code génétique est détenu par le schème émergent.

Le croisement est illustré sur deux exemples :

## 4) - Les exemples

Le croisement est déroulé sur les objets nécessitant de déclencher une émergence globale par croisement, en l'occurrence $O_1$ et $O_5$ :

* **Objet $O_1$ : croisement** : la population de départ pour le croisement est constituée des schèmes permanents des classes partiellement adaptées que sont Enseignant, Ater et Senior-Chercheur. Le schème permanent de la classe Elève-Chercheur n'est pas considéré car elle est moins adaptée que sa consœur Ater dans la même sous-population Temporaire (au vu de ce qui est expliqué dans la section 4.4.5).

- Le croisement est effectué sur autant de générations de population que nécessaire. Nous présentons le croisement pour chaque génération séparément, ce qui nous permet d'expliquer chaque étape, la première génération est constituée des schèmes permanents sus-cités.

- Les schèmes sont préalablement uniformisés lors de la phase d'exploration. Nous remarquons que deux gènes du patrimoine génétique sont absents aussi bien du schème temporaire de $O_1$ que des schèmes permanents de la population de croisement. Il s'agit du 9ème et du 10ème gènes (Année et Directeur-Thèse). Il est inutile d'appliquer le croisement sur ces gènes. Ils ne sont donc pas considérés. Ils sont représentés comme suit :

<table><tr><td>0</td><td>Gène absent de tous les schèmes. Il n'est pas pris en compte dans le processus de croisement car il n'a aucune signification</td></tr></table>

- Le tirage aléatoire est fait. Il est toujours compris entre 0 et 1. Il y a un tirage aléatoire par gène.
- Deux schèmes sont choisis aléatoirement de la population de croisement : Enseignant et Ater. Ils sont mis en évidence dans la population de croisement par un soulignement.

- Ils ont pour Va respectivement 1/5 et 3/5. Leurs Va sont pondérées entre elles. Leur Vap respective est : 1/4 et 3/4. Leur somme fait bien 1.

- Les deux schèmes choisis sont mis en place pour effectuer le croisement au vu des différents tirages aléatoires. Les schèmes enfants (donc issus du croisement) sont notés Eᵢ, i étant le numéro séquentiel de l'apparition du schème enfant :

<table><caption>Tableau 4-19: Les deux étapes de toute itération d'un croisement au travers d'un exemple</caption><thead><tr><th rowspan="2">Population de départ<br>(1ère génération)</th><th colspan="14">Croisement</th></tr><tr><th>O<sub>1</sub></th><th>1</th><th>1</th><th>#</th><th>#</th><th>1</th><th>0</th><th>1</th><th>0</th><th>0</th><th>1</th><th>#</th><th></th></tr></thead><tbody><tr><td>1ère étape : croisement</td><td>Tirage<br>aléatoire</td><td>0.34</td><td>0.59</td><td>0.42</td><td>0.70</td><td>0.15</td><td>0.60</td><td>0.50</td><td>0.43</td><td></td><td></td><td>0.10</td><td>0.90</td><td>Vap</td></tr><tr><td>Enseignant</td><td>Enseignant</td><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td></td><td></td><td>0</td><td>0</td><td>1/4</td></tr><tr><td>Ater</td><td>Ater</td><td>1</td><td>1</td><td>#</td><td>0</td><td>1</td><td>1</td><td>0</td><td>1</td><td></td><td></td><td>0</td><td>0</td><td>3/4</td></tr><tr><td rowspan="2">Senior-Chercheur</td><td>E1</td><td>1</td><td>1</td><td>#</td><td>0</td><td>1</td><td>1</td><td>0</td><td>1</td><td></td><td></td><td>0</td><td>0</td><td></td></tr><tr><td>E2</td><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td></td><td></td><td>0</td><td>0</td><td></td></tr></tbody></table><table><thead><tr><th rowspan="2">2ème étape :<br>contrainte<br>des blocs</th><th colspan="14">Croisement</th></tr><tr><th>O<sub>1</sub></th><th>1</th><th>1</th><th>#</th><th>#</th><th>1</th><th>0</th><th>1</th><th>0</th><th>0</th><th>1</th><th>#</th><th></th></tr></thead><tbody><tr><td>Enseignant</td><td>Tirage<br>aléatoire</td><td>0.34</td><td>0.59</td><td>0.42</td><td>0.70</td><td>0.15</td><td>0.60</td><td>0.50</td><td>0.43</td><td></td><td></td><td>0.10</td><td>0.90</td><td>Va</td></tr><tr><td>Ater</td><td>Enseignant</td><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td></td><td></td><td>0</td><td>0</td><td></td></tr><tr><td>Ater</td><td>Ater</td><td>1</td><td>1</td><td>#</td><td>0</td><td>1</td><td>1</td><td>0</td><td>1</td><td></td><td></td><td>0</td><td>0</td><td></td></tr><tr><td rowspan="2">Senior-Chercheur</td><td>E1</td><td>1</td><td>1</td><td>#</td><td>1</td><td>1</td><td>1</td><td>0</td><td>1</td><td></td><td></td><td>0</td><td>0</td><td>3/5</td></tr><tr><td>E2</td><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td><td>0</td><td>0</td><td>1</td><td></td><td></td><td>0</td><td>0</td><td>1/5</td></tr></tbody></table>

- La première étape consiste à effectuer le croisement gène à gène en fonction du tirage aléatoire et des deux Vap.

- La seconde étape consiste à faire appliquer les contraintes de blocs. Ainsi, les gènes modifiés suite à l'application de la contrainte des blocs sont ceux pointés par une flèche. Ils ont été modifiés de façon à avoir les blocs GS des deux parents respectifs (Enseignant pour E1 et Ater pour E2). Par contre, le GH de E1 n'est pas modifié puisqu'il est entièrement spécifié. Par contre, les gènes du GH de E2 restent à zéro étant donné qu'aucun gène du GH de Ater n'y est spécifié, mais sa structure est transmise.

La Va des deux schèmes enfants ainsi obtenus est calculée. Elles sont toutes les deux inférieures à 1. Le croisement continue. Les schèmes enfants remplacent leurs parents respectifs. Nous remarquons que la taille de la population est toujours la même. La
deuxième génération est prête pour une itération du croisement. Nous regroupons ensemble dans la suite de l'illustration du croisement, le croisement à proprement parler et la contrainte de blocs. Deux schèmes sont choisis aléatoirement : E2 et Senior-Chercheur.

- La seconde génération connaît le croisement suivant :

<table><caption>Tableau 4-20: la seconde génération est croisée.</caption><thead><tr><th>2ème génération</th><th colspan="12">Croisement</th></tr><tr><th>Schèmes sélectionnés</th><th>O<sub>1</sub></th><th>1</th><th>1</th><th>#</th><th>#</th><th>1</th><th>0</th><th>1</th><th>0</th><th>0</th><th>0</th><th>1</th><th>#</th><th></th></tr><tr><th>Tirage aléatoire</th><td>0.05</td><td>0.12</td><td>0.20</td><td>0.10</td><td>0.49</td><td>0.79</td><td>0.37</td><td>0.25</td><td></td><td></td><td></td><td>0.85</td><td>0.12</td><td>Vap</td></tr></thead><tbody><tr><th>E1</th><td>E2</td><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td><td>0</td><td>0</td><td>1</td><td></td><td></td><td>0</td><td>0</td><td>1/5</td></tr><tr><th>E2</th><td>SeniorChercheur</td><td>1</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td></td><td></td><td>1</td><td>#</td><td>4/5</td></tr><tr><th>E3</th><td>E3</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td>0</td><td>1</td><td>0</td><td></td><td></td><td>1</td><td>0</td><td>2/5</td></tr><tr><th>E4</th><td>E4</td><td>1</td><td>1</td><td>1</td><td>0</td><td>1</td><td>0</td><td>1</td><td>0</td><td></td><td></td><td>1</td><td>#</td><td>5/5</td></tr></tbody></table>

À la fin de cette deuxième itération de croisement, il y a un schème émergent : E4. Le croisement continue de façon à donner également des chances à d'autres éventuels schèmes émergents. Les schèmes enfants remplacent leurs parents respectifs dans la population. La troisième génération est prête pour une autre itération du croisement.

- La troisième génération connaît le croisement suivant :

<table><caption>Tableau 4-21: troisième et dernière itération du croisement</caption><thead><tr><th>3ème génération</th><th colspan="12">Croisement</th></tr><tr><th>Schèmes sélectionnés</th><th>O<sub>1</sub></th><th>1</th><th>1</th><th>#</th><th>#</th><th>1</th><th>0</th><th>1</th><th>0</th><th>0</th><th>0</th><th>1</th><th>#</th><th></th></tr><tr><th>Tirage aléatoire</th><td>0.34</td><td>0.19</td><td>0.02</td><td>0.70</td><td>0.15</td><td>0.60</td><td>0.50</td><td>0.33</td><td></td><td></td><td></td><td>0.80</td><td>0.90</td><td>Vap</td></tr></thead><tbody><tr><th>E1</th><td>E1</td><td>1</td><td>1</td><td>#</td><td>1</td><td>1</td><td>1</td><td>0</td><td>1</td><td></td><td></td><td>0</td><td>0</td><td>3/5</td></tr><tr><th>E3</th><td>E3</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td>0</td><td>1</td><td>0</td><td></td><td></td><td>1</td><td>0</td><td>2/5</td></tr><tr><th>E5</th><td>E5</td><td>1</td><td>1</td><td>#</td><td>1</td><td>1</td><td>0</td><td>1</td><td>1</td><td></td><td></td><td>1</td><td>0</td><td>5/5</td></tr><tr><th>E6</th><td>E6</td><td>1</td><td>1</td><td>1</td><td>1</td><td>0</td><td>1</td><td>0</td><td>0</td><td></td><td></td><td>0</td><td>0</td><td>2/5</td></tr></tbody></table>

Le processus de croisement s'achève car tous les schèmes ont participé au croisement et au moins un schème émergent est apparu. Il y a en fait deux schèmes émergents : E4 et E5.

Le même processus est appliqué sur le schème temporaire de l'objet $O_5$:

* *Objet* $O_5$ : croisement : la population de départ pour le croisement est constituée de : Enseignant, Ater et Senior-Chercheur. La classe Eleve-Chercheur n'est pas considérée car elle est moins adaptée que sa consœur Ater dans la même sous-population Temporaire.
<table><caption>Tableau 4-22: les étapes du croisement sur le schème temporaire représentant $O_5$</caption><thead><tr><th>N°Population</th><th colspan="15">Croisement</th></tr></thead><tbody><tr><td rowspan="3">1 :</td><td>O<sub>5</sub></td><td>1</td><td>1</td><td>#</td><td>#</td><td>1</td><td>0</td><td>1</td><td>0</td><td>0</td><td>#</td><td>#</td><td></td></tr><tr><td>Tirage aléatoire</td><td>0.23</td><td>0.68</td><td>0.54</td><td>0.95</td><td>0.32</td><td>0.71</td><td>0.48</td><td>0.78</td><td></td><td></td><td>0.48</td><td>0.74</td><td>Vap</td></tr><tr><td>Enseignant</td><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td></td><td></td><td>0</td><td>0</td><td>1/4</td></tr><tr><td rowspan="2">Ater</td><td>Ater</td><td>1</td><td>1</td><td>#</td><td>0</td><td>1</td><td>1</td><td>0</td><td>1</td><td></td><td></td><td>0</td><td>0</td><td>3/4</td></tr><tr><td>E1</td><td>0</td><td>1</td><td>#</td><td>0</td><td>0</td><td>0</td><td>0</td><td>1</td><td></td><td></td><td>0</td><td>0</td><td>1/4</td></tr><tr><td>Senior-Chercheur</td><td>E2</td><td>1</td><td>1</td><td>#</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td></td><td></td><td>0</td><td>0</td><td>3/4</td></tr><tr><td rowspan="5">2 :</td><td>O<sub>5</sub></td><td>1</td><td>1</td><td>#</td><td>#</td><td>1</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>#</td><td>#</td><td></td></tr><tr><td>Tirage aléatoire</td><td>0.54</td><td>0.28</td><td>0.15</td><td>0.78</td><td>0.46</td><td>0.51</td><td>0.91</td><td>0.85</td><td></td><td></td><td>0.71</td><td>0.15</td><td>Vap</td></tr><tr><td>E1</td><td>0</td><td>1</td><td>#</td><td>0</td><td>0</td><td>0</td><td>0</td><td>1</td><td></td><td></td><td>0</td><td>0</td><td>1/4</td></tr><tr><td>S'Chercheur</td><td>1</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td></td><td></td><td>1</td><td>#</td><td>3/4</td></tr><tr><td>E3</td><td>1</td><td>1</td><td>#</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td></td><td></td><td>1</td><td>0</td><td>3/4</td></tr><tr><td>Senior-Chercheur</td><td>E4</td><td>1</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td><td></td><td></td><td>1</td><td>#</td><td>3/4</td></tr><tr><td rowspan="5">3 :</td><td>O<sub>5</sub></td><td>1</td><td>1</td><td>#</td><td>#</td><td>1</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>#</td><td>#</td><td></td></tr><tr><td>Tirage aléatoire</td><td>0.42</td><td>0.62</td><td>0.13</td><td>0.19</td><td>0.45</td><td>0.18</td><td>0.73</td><td>0.61</td><td></td><td></td><td>0.85</td><td>0.12</td><td>Vap</td></tr><tr><td>E3</td><td>1</td><td>1</td><td>#</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td></td><td></td><td>0</td><td>0</td><td>1/2</td></tr><tr><td>E4</td><td>1</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td><td></td><td></td><td>1</td><td>#</td><td>1/2</td></tr><tr><td>E5</td><td>1</td><td>1</td><td>#</td><td>1</td><td>1</td><td>0</td><td>1</td><td>1</td><td></td><td></td><td>1</td><td>0</td><td>4/4=1</td></tr><tr><td>E6</td><td>E4</td><td>1</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td></td><td></td><td>1</td><td>#</td><td>3/4</td></tr><tr><td rowspan="6">4 :</td><td>O<sub>5</sub></td><td>1</td><td>1</td><td>#</td><td>#</td><td>1</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>#</td><td>#</td><td></td></tr><tr><td>Tirage aléatoire</td><td>0.12</td><td>0.56</td><td>0.47</td><td>0.81</td><td>0.41</td><td>0.52</td><td>0.23</td><td>0.74</td><td></td><td></td><td>0.21</td><td>0.51</td><td>Vap</td></tr><tr><td>E3</td><td>1</td><td>1</td><td>#</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td></td><td></td><td>1</td><td>0</td><td>1/2</td></tr><tr><td>E6</td><td>1</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td></td><td></td><td>1</td><td>#</td><td>1/2</td></tr><tr><td>E7</td><td>1</td><td>1</td><td>#</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td></td><td></td><td>1</td><td>#</td><td>3/4</td></tr><tr><td>E8</td><td>1</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td></td><td></td><td>1</td><td>#</td><td>3/4</td></tr></tbody></table>

Le croisement s'achève sur la quatrième population. Ce dernier croisement ne présente pas de schème émergent, mais le croisement précédent a donné lieu au schème émergent E5.

### 4.5.3. Discussion sur l'émergence

Nous avons vu que nous déclinons l'émergence en :

- émergence locale,

- émergence globale

- par création directe de la structure conceptuelle,
- par croisement.

Ces différents types d'émergence ont été illustrés au travers des exemples traités. Le type d'émergence à appliquer, en déclenchant le processus d'évolution correspondant, est déterminé au vu des résultats de la phase d'exploration. Dans le cadre de l'émergence locale d'un attribut et de l'émergence directe d'une structure conceptuelle, l'endroit d'insertion (au sein d'une classe ou de la hiérarchie) est généralement aisément détectable. Dans le cadre de l'émergence globale par croisement, la détection de l'endroit de la modification, c'est-à-dire le lieu d'insertion dans la hiérarchie, n'est pas triviale.

Ainsi, pour chaque objet ayant évolué, le type d'émergence a été détecté en s'appuyant sur les valeurs d'adaptation :

- l'émergence locale pour l'objet $O_3$,

- l'émergence globale par création directe de la structure conceptuelle pour les objets $O_2$ et $O_4$,

- l'émergence globale par croisement pour les objets $O_1$ et $O_5$.

Les dernières étapes pour finaliser l'évolution dans chaque cas sont présentées ci-après au travers toujours des mêmes exemples :

#### 4.5.3.1. L'émergence locale

L'objet $O_3$ doit être rattaché à sa nouvelle classe *Senior-Chercheur* moyennant l'émergence locale du nouvel attribut *Responsabilité*. Une fois cette émergence validée par le concepteur, le processus lui recommande de préciser les méthodes pouvant manipuler cet attribut (section 4.5.3.3). Une fois la structure conceptuelle complétée, son évolution déclenchera l'adaptation de ses éventuelles sous-classes et de leurs instances. La gestion de ce type d'impacts rentre dans le cadre d'un processus de développement (section 4.6 - ).

#### 4.5.3.2. L'émergence globale

Le choix quant à l'endroit d'insertion d'une nouvelle structure conceptuelle est important. Il doit refléter la part d'influence de ses parents mais également la sémantique portée par la structure conceptuelle émergente :

1) - L'émergence globale par création directe de la structure conceptuelle

Les objets $O_2$ et $O_4$ provoquent chacun l'émergence d'une nouvelle structure conceptuelle. La première sera sous-classe de *Membre-Université* alors que la seconde sera sous-classe de *Temporaire*. Plusieurs stratégies peuvent prendre en compte ce type d'insertion et gérer les différents impacts. Cela est pris en charge dans le cadre d'un
processus de développement (section 4.6 - ). Ces structures conceptuelles doivent également être complétées en termes de méthodes afin de spécifier le comportement de leurs instances (section 4.5.3.3).

## 2) - L'émergence globale par croisement

Concernant les objets O₁ et O₅, un croisement a été déclenché pour chacun des schèmes temporaires les représentant. Dans le cas de O₁, le processus a permis l'émergence de deux schèmes émergents : E4 et E5.

Dans le cas de O₂, le processus a permis l'émergence d'un schème émergent : E5 (qui est différent du schème émergent E5 précédemment cité, étant donné que les deux processus de croisement sont complètement distincts).

Le processus d'émergence globale par croisement se poursuit en recherchant l'endroit d'insertion de la nouvelle structure conceptuelle représentée par le schème émergent. Pour déterminer l'endroit d'insertion, il faut rechercher la classe existant dans la hiérarchie qui se rapproche le plus du schème émergent et qui présente le plus de similitudes en terme de constitution du GH. Une telle classe présenterait les caractéristiques nécessaires et voire même suffisantes pour représenter la super-classe de la structure conceptuelle émergente.

L'espace de recherche d'une telle classe n'est en aucun cas celui de la population. Il se cantonnera uniquement à l'ensemble des classes sélectionnées par la phase d'exploration et utilisées dans le croisement en phase d'exploitation.

En effet, elles sont les seules à avoir transmis un maximum de gènes aux schèmes émergents, il est logique qu'elles peuvent présenter des caractéristiques recherchées, contrairement aux classes qui ne sont pas adaptées au schème temporaire.

L'indéniable avantage est celui d'avoir un espace de recherche déjà cerné, et qui de surcroît est restreint aux seules classes potentiellement candidates. Dans le cas de l'objet O₁ et de l'objet O₅, il s'agit des classes Enseignant, Ater et Senior-Chercheur.

Ensuite, pour choisir parmi ces classes laquelle est plus adaptée à être la super-classe de la structure conceptuelle émergente, nous utilisons la *distance sémantique d.s*, définie en section 4.3.7. La d.s permet de détecter les classes les plus proches sémantiquement du schème émergent parmi la population initiale du croisement, et de déterminer par conséquent l'emplacement de la nouvelle structure conceptuelle dans la hiérarchie de classes.

## 3) - L'exemple de l'objet O₁

Nous devons calculer la d.s pour chacun des deux schèmes émergents :

- Les d.s du schème émergent E4 :

Le nombre de gènes spécifiés dans E4 est de 6 (gènes à '1').
<table><caption>Tableau 4-23: calcul de la d.s pour chaque schème permanent ayant participé au croisement pour E4</caption><thead><tr><th rowspan="2">Schème Émergent E4</th><th colspan="8">Schèmes</th><th rowspan="2">1 #</th><th rowspan="2">d.s</th></tr><tr><th>1</th><th>1</th><th>1</th><th>0</th><th>1</th><th>0</th><th>1</th><th>0</th></tr></thead><tbody><tr><th>Enseignant</th><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>1/6</td></tr><tr><th>Ater</th><td>1</td><td>1</td><td>#</td><td>0</td><td>1</td><td>1</td><td>0</td><td>1</td><td>0</td><td>4/6</td></tr><tr><th>Senior-Chercheur</th><td>1</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td>1</td><td>5/6</td></tr></tbody></table>

En conclusion, la classe Senior-Chercheur a la plus grande distance sémantique. De plus, le bloc de GH de E4 est le même que celui de Senior-Chercheur. Senior-Chercheur est donc candidate pour être la super-classe de la structure conceptuelle émergente véhiculée par E4. Elle exprime ainsi une catégorie de Senior-Chercheur.

**Remarque :** nous mettons en évidence à ce niveau une seconde utilité à la contrainte de blocs de gènes. Elle nous permet en effet de remarquer la similitude, la différence et voire même l'exclusion dans la constitution d'un schème émergent avec un schème permanent.

### - Les d.s du schème émergent E5 :

Le nombre de gènes spécifiés dans E5 est de 7 (gènes à '1').

<table><caption>Tableau 4-24: calcul de la d.s pour chaque schème permanent ayant participé au croisement pour E5</caption><thead><tr><th rowspan="2">Schème Émergent E5</th><th colspan="8">Schèmes</th><th rowspan="2">1 0</th><th rowspan="2">d.s</th></tr><tr><th>1</th><th>1</th><th>#</th><th>1</th><th>1</th><th>0</th><th>1</th><th>1</th></tr></thead><tbody><tr><th>Enseignant</th><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>2/7</td></tr><tr><th>Ater</th><td>1</td><td>1</td><td>#</td><td>0</td><td>1</td><td>1</td><td>0</td><td>1</td><td>0</td><td>4/7</td></tr><tr><th>Senior-Chercheur</th><td>1</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td>1</td><td>4/7</td></tr></tbody></table>

La classe Ater et la classe Senior-Chercheur présentent la même distance sémantique. La classe Enseignant a la plus faible d.s, pourtant elle détient le même GS que le schème émergent E5.

### Conclusion :

Avant d'aller plus loin, une question plus importante s'impose : lequel des deux schèmes émergents E4 et E5 sera le schème véhiculant la structure conceptuelle émergente ? En effet, l'émergence de la structure conceptuelle se fera sur un seul schème émergent.

Pour le schème émergent E4, la classe Senior-Chercheur a la plus grande d.s. La classe Ater vient en seconde position car elle présente également une forte d.s. La structure conceptuelle serait donc a priori dans la catégorie des chercheurs.
Pour le schème émergent E5, les deux classes Ater et Senior-Chercheur ont la même d.s. La seule conclusion à laquelle nous pouvons arriver est que la structure conceptuelle émergente est une sous-classe, directe ou indirecte, de la classe Chercheur.

En l'état actuel, nous ne disposons pas encore des outils nécessaires pour faire un tel choix. Cela fait l'objet du chapitre suivant (chapitre 6).

## 4) - L'exemple de l'objet O₅

La distance sémantique est calculée entre le schème émergent et la population initiale du croisement. Le nombre de gènes spécifiés dans E5 est de 7 :

<table><caption>Tableau 4-25: calcul de la d.s pour chaque schème permanent ayant participé au croisement pour E5</caption><thead><tr><th rowspan="2">Schème Émergent E5</th><th colspan="10">Schème</th><th rowspan="2">d.s</th></tr><tr><th>1</th><th>1</th><th>#</th><th>1</th><th>1</th><th>0</th><th>1</th><th>1</th><th>0</th><th>0</th><th>1</th><th>0</th></tr></thead><tbody><tr><td>Enseignant</td><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>2/7</td></tr><tr><td>Ater</td><td>1</td><td>1</td><td>#</td><td>0</td><td>1</td><td>1</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>4/7</td></tr><tr><td>Senior-Chercheur</td><td>1</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>1</td><td>#</td><td>4/7</td></tr></tbody></table>

### Conclusions :

- Enseignant a la plus faible distance sémantique. Elle ne peut donc pas être une super-classe du schème émergent.

- Ater et Senior-Chercheur ont la même distance sémantique, et elle est supérieure à celle d'Enseignant. De plus, ces deux classes sont des sous-classes de Chercheur.

Les deux classes Ater et Senior-Chercheur ont la même d.s. La seule conclusion à laquelle nous pouvons arriver est que la structure conceptuelle émergente sera une sous-classe, directe ou indirecte, de la classe Chercheur, moyennant des mutations sur les attributs tels que *Modules*.

En l'état actuel, nous ne disposons pas encore des outils nécessaires pour faire un tel choix. Cela fait l'objet du chapitre suivant (chapitre 6).

## 5) - L'héritage multiple et l'émergence globale par croisement

Nous avons soulevé le fait que le choix quant à l'endroit d'insertion d'une nouvelle structure conceptuelle soit important. Il doit refléter la part d'influence de ses parents mais également la sémantique portée par la structure conceptuelle émergente. Il est plus logique qu'une structure conceptuelle qui prend la principale part de ses gènes d'une classe, soit dans la même branche dans la hiérarchie qu'elle.

Pour inférer une telle information, nous avons recours à l'exploitation des valeurs d'adaptation déjà calculé lors des phases d'exploration. Ainsi, lors d'un croisement, le parent ayant la plus forte Va va influer majoritairement le schème final. A plus forte
raison, si le schème émergent contient le GH du schème parent. Aussi, dans le cas d'une émergence globale, la structure conceptuelle émergente sera rattachée à sa branche.

Le cas particulier où les deux parents ont chacun une Va avoisinant les 50% (une Va comprise en 40% et 60%) au schème temporaire, peut voir la structure conceptuelle émergente créée par héritage multiple. Un autre critère permettrait d'avoir recours à l'héritage multiple sans ambiguïté est lorsque le GH de chaque schème parent se retrouve dans le schème émergent.

## 6) - Conclusions

Cependant, dans le cadre de l'émergence globale par croisement, le processus d'émergence tel qu'il a été défini gagnerait à être enrichi pour mener à bien les cas suivants :

- lorsqu'il y a le choix à faire entre plusieurs schèmes émergents car les Va étant identiques. Particulièrement si les schèmes émergents se retrouvent avec des blocs différents de GH, c'est-à-dire que différentes branches de la hiérarchie sont éligibles, tel le cas de $O_1$;

- lorsqu'il y a un choix à faire entre des classes pertinentes pour l'insertion d'une structure conceptuelle émergente, tel le cas de $O_5$. Les Va et les d.s obtenues à elles seules ne permettent pas de distinguer et de choisir la configuration finale de la structure conceptuelle émergente et de son lieu d'insertion dans la hiérarchie.

Ces limites rencontrées lors de l'analyse des résultats du croisement font l'objet du chapitre 6. Ces limites sont levées en ayant recours à des métriques.

### 4.5.3.3. Compléter le comportement spécifié au sein des structures conceptuelles

Les résultats de l'émergence sont proposés au concepteur. Celui-ci peut valider en choisissant la solution qui lui convient le mieux, s'il existe plusieurs solutions. Au sein de la solution choisie, il peut activer des mutations selon ses besoins. Le processus lui réclame en outre, de spécifier des méthodes pour pouvoir manipuler les attributs nouvellement introduits. Dans le cas de l'émergence de structures conceptuelles, en plus de la nécessité de définir ces méthodes, le processus crée automatiquement le constructeur et le destructeur par défaut.

Dans le cas où le concepteur décline cette proposition de venir compléter les structures conceptuelles, le système lui rappelle, sous forme de messages d'alerte, le fait que les méthodes ne soient pas spécifiées, et ce dès que le système accédera à une de ces structures conceptuelles ou l'une de leurs instances. Ceci est valable pour toute émergence d'un nouvel attribut et d'une nouvelle structure conceptuelle.

Une autre situation se pose lorsque l'émergence globale par croisement est effectuée. Une nouvelle structure conceptuelle émergeant par croisement est, en gros, constituée d'attributs existants (et donc préalablement spécifiés au sein d'autres classes) et de
nouveaux attributs. Elle nécessite également d'être complétée en terme de spécification du comportement de ses instances (actuelles et à venir).

Pour les nouveaux attributs, la procédure est celle sus-citée. Pour les attributs existants, le processus détecte automatiquement, pour chacun de ces attributs, toutes les méthodes dans la classe qui le référencent dans leur signature. L'ensemble de ces méthodes est alors référencé par la nouvelle structure conceptuelle.

Une fois ainsi complétée 'par défaut', la structure conceptuelle est soumise à la validation du concepteur.

## 4.6 - Le développement

Nous avons introduit la notion de processus de développement dans le cadre de l'état de l'art (chapitre 3) et dans le cadre des concepts et notions du modèle (chapitre 4). Nous l'avons également défini de manière plus précise dans la section 4.2.4.1 du présent chapitre.

Nous considérons en effet qu'un processus de développement représente toute évolution en intention et toute évolution en extension d'une classe.

Dans le cadre de l'étude de l'évolution d'objets faite dans le chapitre 3, plusieurs stratégies ont été présentées. Nous en avions conclu, au vu des définitions d'un processus de développement et d'un processus d'émergence, que la majeure partie de ces stratégies d'évolution font du développement.

Dans le cadre des processus d'évolution que nous proposons dans notre modèle, nous définissons des processus d'évolution pour gérer l'émergence. Pour ce qui est des processus de développement (définition et différents cas présentés en section 4.2.4.1), nous considérons que nous pouvons utiliser l'une des stratégies d'évolution étudiées dans le chapitre 3. Elles sont en effet adaptées pour gérer le développement car elles assurent l'évolution par modification de classes. Nos choisissons pour notre étude une de ces stratégies, à savoir la correction de classes [Banerjee& 87] car elle présente une taxonomie complète d'opérations d'évolution.

Rappelons le fonctionnement général des processus de développement et d'émergence. La figure suivante est légèrement plus détaillée que celle présentée dans le chapitre 3 :
<figure><img src="image_41.png" /><figcaption>Figure 4-14: le Développement et l'Émergence : les deux processus d'évolution.</figcaption></figure>

Outre sa définition propre, nous considérons qu’un processus de développement est déclenché de manière *directe* et/ou *indirecte* :

- de manière *directe* : lorsque l'évolution en intention ou en extension d'une classe survient directement sur l'entité concernée (classe ou instance) ;

- de manière *indirecte* : lorsque l'évolution en intention et en extension d'une classe survient pour gérer les conséquences d'un processus d'émergence. Lorsqu'un processus d'émergence locale, globale directe ou globale par croisement aboutit, les modifications doivent être répercutées au niveau de la hiérarchie des classes. La gestion des conséquences sur les autres entités concernées se fait dans le cadre du développement.

Dans ce cadre, nous proposons de laisser le choix au concepteur de choisir la stratégie de développement qui lui convient pour gérer les conséquences de l'émergence. Notre objectif est double :

- permettre l'intégration de notre modèle, moyennant la transcription de la hiérarchie de classes en prenant en compte les différents concepts proposés, principalement les GF, GH, GS et schème, au sein d'applications déjà existantes ;

- permettre au concepteur de continuer à travailler avec son environnement habituel et les stratégies d'évolution déjà présentes dans l'application.

## 4.7 - Le lien d'évolution

Le *lien d'évolution* a été introduit dans le chapitre 4. Il en a également été question en section 4.5.1.2 qui traite des exemples d'émergence locale, et en section 4.5.2.1.2, qui
traite des exemples de l'émergence globale par création directe de structures conceptuelles.

Ces premières introductions permettent de donner une idée de ce qu'est le lien d'évolution. Cependant, le lien d'évolution est défini et présenté en détails dans la présente section.

### 4.7.1. Introduction

L'émergence peut être menée à son terme :

- De manière *locale* : de nouvelles propriétés apparaissent au sein d'une classe existante ;

- De manière *globale* : une ou plusieurs structures conceptuelles émergent et sont insérées dans la hiérarchie de classes.

Mais quel que soit l'issue de l'émergence, tant qu'elle est concluante, les objets ayant provoqué ces processus d'émergence évoluent de leur classe initiale, dont ils sont détachés, vers les classes correspondantes, modifiées ou créées par émergence, auxquelles ils sont rattachés.

### 4.7.2. Définition du lien d'évolution

Le lien d'évolution est un lien sémantique représentée par une association réflexive dans le méta-modèle de GENOME, et porteur de propriétés. Lorsqu'un objet évolue d'une classe source vers une classe cible, un lien est créé de la classe source vers la classe cible. Ce lien est dit *lien d'évolution*. Le lien d'évolution est toujours orienté de la classe source vers la classe cible.

Une classe peut être la source d'aucun, d'un ou de plusieurs liens d'évolution. Une classe peut également être la cible d'aucun, d'un ou de plusieurs liens d'évolution. C'est ce qui est exprimé dans la portion suivante du méta-modèle de GENOME défini dans le chapitre 3 :
<figure><img src="image_42.png" /><figcaption>Figure 4-15: Lien d'évolution</figcaption></figure>

Un lien d'évolution, en plus de la spécification de ses classes source et cible, porte la différence des ensembles d'attributs et de méthodes des deux classes. Il détient les références des attributs et des méthodes de la classe source perdus par l'objet, et les références des attributs et des méthodes de la classe cible acquis par ce même objet.

### 4.7.3. Utilité du lien d'évolution

Le lien d'évolution est le concept qui concrétise un de nos principaux objectifs, celui de permettre à un modèle d'apprendre un de ses comportements futurs et nouveaux : **permettre la capitalisation de nouveaux comportements et des nouveaux besoins.**

L'objectif du lien d'évolution est de matérialiser le fait que le modèle ait appris un nouveau comportement et une voie possible et connue d'évolution non seulement de ses instances, mais également de son modèle de classes.

La structure et la composition du lien d'évolution sont utilisées comme suit :

Lorsqu'un objet d'une classe évolue dynamiquement dans sa structure, au lieu de déclencher directement un processus d'évolution, il est préférable d'exploiter en premier lieu les différents liens d'évolution émanant de sa classe d'appartenance (c'est-à-dire qu'elle en est la source).

En effet, étant donné que le système a acquis auparavant la connaissance de comportements évolutifs des instances de cette classe, il est plus judicieux de l'exploiter. Cela se fait en analysant les informations portées par le lien d'évolution. Dans le cas de résultats infructueux, il est possible de conclure que la situation de changements est nouvelle, et par conséquent inconnue. Un processus d'évolution est alors déclenché pour tenter d'y répondre.

Comment analyser les liens d'évolution ?

Il s'agit de comparer tous les liens d'évolution émanant de la classe d'appartenance de l'objet, c'est-à-dire dont elle est la source. Ensuite, pour chaque lien, il faut comparer la nouvelle structure de l'instance avec les attributs référencés par le lien, pour détecter si l'instance a perdu les mêmes attributs ou un sous-ensemble des attributs référencés par
le lien comme perdus, et si elle a acquis les mêmes attributs ou un sous-ensemble des attributs de la classe cible et référencés par le lien comme attributs à acquérir.

La comparaison avec le lien d'évolution évite d'avoir à parcourir l'ensemble des classes à la recherche de leur adaptation. Cela permet d'optimiser l'espace et le temps de recherche.

Dans le cas où l'instance serait conforme à la définition du lien d'évolution, le processus d'évolution se charge de faire évoluer l'instance de sa classe d'appartenance vers la classe cible. L'instance *emprunte* une voie d'évolution déjà connue, à laquelle le modèle sait répondre.

Dans le cas où l'instance ne serait conforme à aucun lien d'évolution émanant de sa classe d'appartenance initiale, un processus d'évolution est déclenché dans sa première phase qu'est la phase d'extraction, pour se poursuivre sur la phase d'exploration et la phase d'exploitation (section 4.4 - ).

4.7.4. Les graphes d'évolution

Le lien d'évolution est un lien porteur d'une sémantique particulière. Il n'a pas le même rôle qu'une simple association. Une association entre deux classes exprime une information statique qui existe entre les instances de ces deux classes. Le lien d'évolution est porteur d'une information d'évolution entre une classe et une autre. Il se situe dans une dimension différente de celle des autres types de liens que sont l'héritage, la composition et l'association. L'historique des liens d'évolution donne une information sur la manière dont le modèle a évolué. Ils ne sont consultés et activés que face à de nouvelles situations de changements. Pour ces raisons, les liens d'évolution sont organisés au sein de *graphes*. Chaque classe peut potentiellement être la racine d'un graphe de liens d'évolutions. Elle représenterait leur classe source. Donc, une population peut avoir plusieurs graphes de liens d'évolution. Ces graphes sont représentés, pour des raisons de lisibilité et pour éviter toute confusion avec la hiérarchie de classes, dans un plan parallèle au modèle de classes. Dans un graphe d'évolution, les nœuds sont les classes. Les arcs sont les liens d'évolution porteurs des gènes perdus et acquis lorsqu'une instance évolue de la classe source d'un arc vers la classe cible de ce même arc. Les arcs sont orientés pour exprimer dans quel sens se fait l'évolution. Les graphes des liens d'évolution sont illustrés dans la Figure 4-16.

4.7.5. Les exemples

L'émergence a pu être menée à terme pour les objets O₂, O₃ et O₄. Le résultat de
l'émergence pour ces objets sont :

- Pour O₂ : l'émergence globale par création directe de la classe Ingénieur comme sous-classe de la classe Membre-Université ;

- Pour O₃ : l'émergence locale de l'attribut *Responsabilité* au sein du GS de la classe Senior-Chercheur ;
- Pour $O_4$: l'émergence globale par création directe de la classe Post-Doc comme sous-classe de la classe Temporaire.

L'émergence n'a pas été complètement menée à terme pour les objets $O_1$ et $O_5$. Pour l'objet $O_1$, le croisement a mis en évidence deux schèmes émergents. Le choix doit être fait entre ces deux schèmes. Par contre pour l'objet $O_5$, le croisement a mis en évidence un seul schème émergent. Cependant, en appliquant la distance sémantique, deux classes présentent la même distance sémantique. Le choix doit être fait entre ces deux classes. Aussi, ces deux exemples seront traités dans le chapitre suivant (chapitre 6), y compris pour le lien d'évolution.

Dans la présente section, nous mettons en évidence les liens d'évolution pour les objets $O_2$, $O_3$ et $O_4$:

<figure><img src="image_43.png" /><figcaption>Figure 4-16: les liens d'évolution</figcaption></figure>

La figure ci-dessus met en évidence la prise en compte des résultats de l'émergence issus de l'évolution des objets $O_2$, $O_3$ et $O_4$.
## 1) - Modifications apportées à la hiérarchie de classes

Les modifications au sein de la population Membre-Université sont comme suit :

- Pour $O_2$: l'émergence globale par création directe de la classe Ingénieur comme sous-classe de la classe Membre-Université. La classe Ingénieur présente le même GF que sa population, ne présente pas de GH, et présente un GS constitué du nouvel attribut introduit par $O_2$, l'attribut *Poste*. Le schème permanent associé à Ingénieur a la même structure que la classe Ingénieur : la valuation des gènes du GF et la valuation du gène du GS. La première est imposée par la population. La seconde est proposée par défaut à 1 au concepteur. Dans ce cas, le concepteur décide de la laisser à 1.

- Pour $O_3$: l'émergence locale du nouvel attribut *Responsabilité*, introduit par l'objet $O_3$, au sein du GS de la classe Senior-Chercheur. Le schème permanent associé à la classe Senior-Chercheur est modifié en conséquence : il s'agit d'introduire un nouveau gène à la position du nouvel attribut. Par défaut, il est proposé à 1 au concepteur. Celui-ci le modifie à # car il estime qu'il n'est pas obligatoire que tous les senior-chercheurs aient une responsabilité.

- Pour $O_4$: l'émergence globale par création directe de la classe Post-Doc comme sous-classe de la classe Temporaire. La classe Post-Doc présente donc le même GF que toute la population. Elle présente également le même GH que les autres sous-classes de Temporaire. La classe Post-Doc présente également un GS constitué du nouvel attribut introduit par $O_4$, l'attribut *Responsable*. Le schème permanent associé à Post-Doc a la même structure que la classe Post-Doc : la valuation des gènes du GF, la valuation des gènes du GH et la valuation du gène du GS. La première est imposée par la population. La seconde subit une modification apportée par le concepteur sur le gène représentant le gène *Nbr-Publications*. Il le fait muter de # à 1. La troisième est proposée par défaut à 1 au concepteur. Dans ce cas, le concepteur décide de la laisser à 1.

## 2) - Spécifications des liens d'évolution

Trois liens d'évolution sont définis :

- $L_1$: de Eleve-Chercheur vers Ingénieur,

- $L_2$: de Eleve-Chercheur vers Senior-Chercheur,

- $L_3$: de Ater vers Post-Doc.

Les liens d'évolution sont organisés dans un graphe qui leur est propre. Ainsi, la première représentation des liens d'évolution en Figure 4-16 est plus précise dans la Figure 4-17. Cette dernière met en évidence deux plans séparés : la hiérarchie de classes et le plan des graphes de liens d'évolution. Chaque nœud d'un graphe de liens d'évolution est connecté par une ligne en pointillés vers une classe de la hiérarchie de classes. En réalité, chacun de ces nœuds est juste une image de la classe afin de permettre de représenter séparément les deux plans. En fait, ces deux plans sont parallèles. Ils ont les mêmes nœuds (les classes), mais ces nœuds sont organisés différemment selon le plan : les arcs qui les relient dans la hiérarchie de classes sont des liens d'héritage, voire de références (association, composition) ; les arcs qui les relient dans le graphe d'évolution sont les liens d'évolutions :
<figure><img src="image_44.png" /><figcaption>Figure 4-17: Hiérarchie de classes et Graphes de Liens d'évolution.</figcaption></figure>

Ainsi, à une hiérarchie de classes représentant une population peut être associé un graphe de liens d'évolution.

Dans notre exemple, L₁, L₂ et L₃ sont les trois liens d'évolution qui ont été créés après avoir mené à bien les processus d'évolution de O₂, O₃ et O₄. Chacun des liens d'évolution est orienté de la source vers sa cible. Nous présentons ci-après le détail de chaque lien :

- L₁ est constitué des attributs suivants :

- Theme-Recherche

- Laboratoire

- Nbr-Publications

- Durée

- Année

- Directeur-Thèse

- Poste

- L₂ est constitué des attributs suivants :
- Durée

- Année

- Directeur-Thèse

+ Date-début

+ Equipe-Recherche

+ Projet-Recherche

+ Responsabilité

- $L_3$ est constitué des attributs suivants :

- Nbr-heures

- Modules

+ Responsable

Les attributs précédés d'un signe - sont les attributs de la source qui sont perdus et les attributs précédés du signe + sont les attributs acquis de la cible. C'est la structure que respectera toute instance de la classe source qui évoluera de cette même classe source vers la classe cible.

## 4.8 - Conclusion

Tout au long de ce chapitre, les processus d'évolution de GENOME sont présentés et définis. Cette présentation a été abordée en plusieurs aspects :

- En premier lieu, nous précisons que les processus d'évolution sont déclenchés et opèrent entre deux états stables d'un modèle. Un état stable est un état où la dualité classe/instance est respectée, c'est-à-dire que toutes les modifications ont été apportées au niveau conceptuel ainsi que la gestion des impacts de ces modifications.

- Ensuite, les trois phases d'évolution de tout processus d'évolution sont introduites. Ce qui permet de définir plus clairement les processus d'évolution, étant donné que leurs principales étapes opératoires sont abordées. Ces phases sont les phases d'extraction, d'exploration et d'exploitation. Les processus de développement et d'émergence à proprement parler sont déclenchés lors de la dernière phase.

- Avant de préciser le détail opératoire de chaque phase, les opérateurs génétiques objets utilisés durant ces phases sont présentés et définis, ainsi que deux mesures. Les opérateurs sont la sélection, la reproduction, la mutation et le croisement, qui constitue le cœur du processus d'émergence globale. Les mesures sont la valeur d'adaptation $Va$ et la distance sémantique $d.s$. Cette section récapitule à la fin l'utilisation des opérateurs dans chacune des trois phases.
– Le détail de chaque phase est abordé ensuite dans des automates. Nous associons à chaque phase un automate qui est décrit selon le formalisme des diagrammes d'états-transitions d'UML [Muller 97]. Chacun de ces automates est illustré par des exemples. Le processus d'émergence est ensuite détaillé au travers de ses différents types : émergence locale, émergence globale par création directe de la structure conceptuelle et émergence globale par croisement.

– Cette section est suivie d'une section consacrée à une discussion sur l'émergence, mettant en évidence les apports de l'émergence, mais également certaines limites. Ces dernières seront abordées et levées dans le chapitre suivant.

– Ce chapitre se termine par une présentation des liens d'évolution. Les liens d'évolution, organisés en graphes, permettent de représenter le comportement d'évolution des instances du modèle et permettent également d'apprendre un nouveau comportement évolutif des instances. Le système aura recours à ces liens pour toute situation de changement future. Si aucun lien ne le détient, alors un processus d'évolution est déclenché et ses trois phases sont ainsi exécutées.
<figure><img src="image_45.png" /></figure>
# Chapitre 5 : GENOME : LES METRIQUES POUR CONTROLER L'EMERGENCE

<figure><img src="image_46.png" /></figure>
# 5.1 - Introduction

Nous traitons dans le présent chapitre les limites rencontrées lors de l'analyse des résultats du croisement dans le chapitre précédent. L'approche que nous adoptons pour pouvoir y répondre s'appuie sur l'utilisation de métriques. Notre objectif est de mesurer pour mieux contrôler ce qui émerge. Quelles sont donc ces limites et au vu de quoi pouvons-nous proposer des métriques ?

## 5.1.1. Les limites de l'émergence

Le chapitre précédent a permis de présenter les différents processus d'évolution. Ils ont été illustrés sur des exemples d'évolution d'objets. La plupart des exemples ont pu être menés à terme. Seules deux situations se sont retrouvées non résolues. Il s'agit de processus d'émergence globale par croisement. Le croisement a été mené à terme. Dans l'un des cas, il a permis l'émergence de deux schèmes émergeants mais aucun élément ne permet d'en préférer l'un à l'autre car les Va sont identiques. Dans l'autre cas, le croisement a permis l'émergence d'un schème émergent, mais l'application de la distance sémantique ne permet pas de dégager une super-classe potentielle pour l'abstraction véhiculée par le schème émergent. En effet, deux classes présentent la même d.s. La seule utilité de la d.s dans cet exemple a été d'éliminer une classe dont la d.s était trop faible pour être une super-classe, à savoir la classe Enseignant.

Nous rappelons ci-après les conclusions du précédent chapitre. Celles-ci mettent en évidence la nécessité d'enrichir l'émergence lors de l'analyse des résultats du croisement, et particulièrement dans les cas suivants :

- lorsqu'il y a un choix à faire entre plusieurs schèmes émergents. Particulièrement si les schèmes émergents se retrouvent avec des blocs
différents de GH, c'est-à-dire que différentes branches d'une hiérarchie sont
éligibles, tel le cas de O₁ pour lequel le schème émergent E4 présente un
bloc de gènes propre à la catégorie des enseignants, alors que le schème
émergent E5 présente plutôt des blocs de gènes propres à la catégorie des
chercheurs,

- lorsqu'il y a un choix à faire entre des classes pertinentes pour l'insertion d'une structure conceptuelle émergente, tel le cas de O₅, pour lesquelles au moins deux classes peuvent a priori être sa super-classe : Senior-Chercheur et Ater.

Nous en concluons que la Va et la d.s ne suffisent pas toujours pour mener à terme l'émergence. Dans les exemples précités, l'analyse des différentes Va et des différentes d.s permet de tirer quelques conclusions. La principale conclusion est que le schème émergent dans le cas de l'objet O₅ a des similitudes avec la catégorie des chercheurs. Cependant, les résultats de leur analyse ne permettent pas d'aller plus loin.

Nous en concluons que la Valeur d'adaptation, Va, et la distance sémantique, d.s, représentent des valeurs nécessaires pour l'exécution et l'achèvement de l'émergence mais, dans certaines situations, elles ne représentent pas des valeurs suffisantes principalement pour l'achèvement de l'émergence, tels que pour distinguer et choisir :

- parmi plusieurs schèmes émergents,

- parmi des classes identiquement proches du schème émergent.

Dans les deux cas, seule une analyse plus approfondie de la constitution des schèmes émergents et leur comparaison avec les classes éligibles peuvent permettre de statuer et de choisir parmi les solutions potentielles : le choix de schème émergent et/ou le choix de super-classe(s).

5.1.2. Des métriques au service de l'émergence

Les limites rencontrées pour l'achèvement de l'émergence globale par croisement nous incitent à vouloir analyser de manière plus approfondie les différents résultats d'un croisement : les schèmes émergents lorsqu'il y en a plusieurs pour un même croisement, et la comparaison du schème émergent avec les schèmes permanents ayant participé au croisement.

De manière plus précise, nous jugeons nécessaire d'avoir des informations sur la cohésion d'un schème émergent aussi bien de manière interne qu'externe, ainsi que la présence ou non de contradictions non seulement au sein d'un schème émergeant mais également par rapport aux schèmes permanents ayant participé au croisement ainsi que par rapport au modèle (au vu des contraintes et des invariants).

Nous optons pour l'utilisation de *métriques*. Ces dernières offrent l'avantage d'être calculées et évaluées de manière automatique et sont quantifiables. Ces caractéristiques
s'accordent avec notre principal objectif, à savoir celui de fournir un modèle de simulation d'évolution dynamique en cherchant et en proposant diverses voies d'évolution. Les caractéristiques précitées des métriques s'accordent avec notre approche pour deux principales raisons, qui constituent en fait des similitudes :

- Les métriques peuvent être évaluées automatiquement. Un processus d'évolution s'exécute automatiquement tout au long de ses trois phases. Une première utilisation de valeurs automatiquement calculées est celle de la Va et de la d.s. Cet automatisme permet de balayer rapidement l'espace des solutions, d'éliminer les moins pertinentes, et de proposer les plus intéressantes au concepteur ;

- Les métriques sont plus aisément applicables sur des données qui peuvent être évaluées sans ambiguïté. C'est justement la principale caractéristique et le principal rôle d'un schème, qu'il soit permanent, temporaire, enfant ou émergent. Sa structure constituée de gènes référençant des attributs et leurs valeurs restreintes (0, 1 ou #) permettent sans encombre d'effectuer des mesures principalement pour évaluer et relever aussi bien les similitudes, les rapprochements, les écarts et les contradictions.

Aussi, en mesurant de manière adéquate, nous pouvons mieux contrôler l'émergence et ses divers impacts. Pour pouvoir mesurer correctement, nous devons déterminer clairement ce que nous voulons faire et comment le faire. Nous devons également déterminer à quel endroit utiliser quelle métrique. Nous adoptons pour cela le principe général de la technique dite GQM pour Goal-Question-Metric [Basili& 84].

Nous considérons que la Va et la d.s sont des *métriques* d'un premier degré de mesure et d'analyse. Nous proposons, pour les raisons sus-citées, d'utiliser des métriques à un second degré de mesure et d'analyse pour étudier :

- la constitution de chaque schème de manière interne ;

- la cohésion du schème par rapport à la hiérarchie de classes existantes.

Nous nous inspirons de quelques métriques orientées objet standards [Coulange 98]. Nous en adoptons et adaptons quelques-unes unes à notre modèle. Nous en proposons également d'autres que nous introduisons pour prendre en compte les spécificités des concepts du modèle.

Nous présentons en premier lieu les métriques orientées objet dans leur définition, leur contexte d'utilisation ainsi que quelques métriques orientées objet standards.

## 5.2 - Les Métriques Orientées Objet

Les premières métriques ont été introduites en informatique pour la mesure de logiciels. Un exemple de métrique qui revient souvent dans le jargon d'un programmeur est la fameuse « X lignes de code ». L'effort de mesure ne s'y est pas uniquement cantonné. L'action de mesurer s'est appliquée à tous les niveaux
(application, développement, conception...) et à la plupart des composants (opérateurs, opérandes, fonction, flots de contrôle de programmes, effort de développement...) aussi bien en termes de quantité que de qualité. La métrologie est définie comme des « techniques qui permettent de vérifier de façon 'mathématique' des propriétés sur un logiciel » et elle s'est également étendue à l'approche objet [Coulange 98].

### 5.2.1. Définitions

Nous présentons une première définition générale de l'action de mesurer avant de parler de métrique dans l'approche objet :

- Définition générale : l'action de mesurer est le processus par lequel des nombres ou des symboles sont assignés à des attributs d'entités du monde réel d'une manière pouvant les décrire suivant des règles clairement définies.

- Métrique : une métrique est une mesure effectuée sur un logiciel ou sur un modèle d'analyse ou de conception. Une métrique est considérée comme un identificateur de l'entité mesurée.

### 5.2.2. Caractéristiques d'une métrique

Hormis des métriques objets de base (les premières sont les six métriques proposées par Chidamber et Kermer [Chidamber & 91] développées pour mesurer la qualité de la conception des logiciels orientés objet ; [Rocacher 88]) qui rassemblent plus ou moins un certain consensus, la définition d'une métrique est une tâche délicate. Elle doit en effet comporter et répondre à plusieurs éléments : sur quelle(s) entité(s) porte la métrique, comment la mesurer, comment interpréter la mesure, à quoi la comparer, quelles sont les limites qui permettent de dire que la mesure est 'bonne' ou 'mauvaise' ?...

Les caractéristiques auxquelles doit répondre une métrique sont rappelées dans [Coulange 98]. Parmi les plus significatives, une mesure doit :

- Suggérer une norme, une échelle de valeurs et des bornes. Il doit être possible de comparer deux mesures du même type.

- Avoir une signification.

- Se rapporter aux propriétés du processus, du modèle ou du système considéré.

- Suggérer une stratégie d'amélioration.

- Être simple.

Ces caractéristiques sont effectivement importantes, mais il n'y a pas de manière de les définir et de les assurer. La définition complète d'une métrique reste donc entièrement à l'appréciation de ceux qui la définissent.
Dans le cadre de logiciels orientés objet, les métriques se définissent selon un contexte précis d'utilisation :

### 5.2.3. Contextes d'utilisation d'une métrique et exemples

La signification d'une métrique dépend de son contexte d'utilisation. Généralement, trois contextes d'utilisation pour la qualité de la conception des logiciels orientés objet sont définis :

- contexte d'application,

- contexte de classe,

- contexte de fonction.

L'interprétation des métriques est souvent un indicateur et ne peut le plus souvent que renseigner et attirer l'attention du concepteur ou de l'utilisateur sur l'entité mesurée. Nous définissons succinctement chaque contexte d'utilisation de métriques. Nous présentons quelques exemples pour chaque contexte dans leur nom, leur définition et leur éventuelle utilité [Coulange 98]. La plupart de ces exemples sont des métriques proposées par [Chidamber& 96]. Elles ont également donné lieu à des variantes.

#### 5.2.3.1. Contexte d'Application

Le contexte *Application* concerne tout le code source d'une application. Les métriques ont une portée globale. Voici quelques exemples :

<table><caption>Tableau 5-1: des exemples de métriques de contexte d'application.</caption><thead><tr><td>Nom de la métrique</td><td>Signification</td><td>Utilité</td></tr></thead><tbody><tr><td>Nombre de niveaux du graphe d'appel</td><td>Nombre de niveaux dans le graphe représentant les appels entre les méthodes au sein d'une application.</td><td>Un nombre élevé montre une hiérarchie trop forte</td></tr><tr><td>Nombre de niveaux dans le graphe d'héritage</td><td>Nombre de niveaux dans le graphe représentant l'héritage entre classes</td><td>Un nombre élevé rendra une application difficile à comprendre</td></tr></tbody></table>

#### 5.2.3.2. Contexte de Classe

Le contexte *Classe* concerne les informations présentes au sein d'une classe. Voici quelques exemples [Chidamber& 91] :
<table><caption>Tableau 5-2: des exemples de métriques de contexte de classe.</caption><thead><tr><td>Nom de la métrique</td><td>Signification</td><td>Utilité</td></tr></thead><tbody><tr><td>Nombre pondéré de méthodes</td><td>Donne une idée de la complexité des méthodes d'une classe.</td><td>Elle peut être un indicateur de maintenabilité ou de réutilisabilité selon la formule de calcul adoptée. Plus elle est élevée, plus la classe est difficile à comprendre et donc à maintenir.</td></tr><tr><td>Manque de cohésion entre méthodes</td><td>Donne le nombre d'ensembles disjoints d'attributs dans une classe.</td><td>Une grande cohésion montre une bonne encapsulation. Une faible cohésion montre que la classe pourrait être divisée en plusieurs sous-classes.</td></tr><tr><td>Réponse pour une classe</td><td>Donne le nombre de méthodes pouvant être sollicitées en réponse à un message.</td><td>De mauvaises valeurs veulent peut être dire que les traitements ne sont pas dans les bonnes classes.</td></tr><tr><td>Couplage entre objets</td><td>Est un indicateur de dépendance d'une classe vis-à-vis des autres classes.</td><td>Plus elle est élevée, plus une classe est liée aux autres classes. Elle est alors difficile à réutiliser et à faire évoluer.</td></tr></tbody></table>

### 5.2.3.3. Contexte de Fonction

Le contexte *Fonction* concerne les informations présentes dans le corps d'une fonction. Voici quelques exemples :
<table><caption>Tableau 5-3: des exemples de métriques de contexte de fonction.</caption><thead><tr><td>Nom de la métrique</td><td>Signification</td><td>Utilité</td></tr></thead><tbody><tr><td>Nombre d'instructions</td><td>Donne le nombre d'instructions exécutables situées entre la ligne de début et la ligne de fin d'un sous-programme.</td><td>C'est un indicateur de maintenabilité. Mais elle est difficile à apprécier.</td></tr><tr><td>Nombre cyclomatique</td><td>Donne le nombre de chemins linéaires indépendants dans un graphe fermé.</td><td>C'est un indicateur de l'effort de compréhension et de tests à faire.</td></tr><tr><td>Nombre de chemins</td><td>Donne le nombre de chemins d'exécution non cycliques.</td><td>Donne une idée précise du nombre de tests nécessaires.</td></tr><tr><td>Nombre de niveaux</td><td>Donne le nombre de niveaux d'imbrication des structures de contrôle dans une fonction.</td><td>Plus il est élevé, plus la compréhension de l'algorithme de la fonction est difficile.</td></tr></tbody></table>

Il apparaît au vu des exemples cités, que les métriques ne permettent pas forcément de donner une information suffisamment précise sur l'élément mesuré qui permettrait d'agir directement. Mais elles peuvent représenter de précieux indicateurs et aider par conséquent à choisir ou à améliorer l'élément mesuré ainsi que ceux avec lesquels il peut interagir.

Dans la section suivante, nous abordons les métriques dans notre modèle. Nous expliquons comment nous procédons pour dégager des métriques nécessaires au contrôle de l'émergence, principalement les résultats du croisement, avant de présenter les différentes métriques et leur illustration.

## 5.3 - les métriques dans notre modèle

Nous introduisons des métriques pour compléter les processus d'évolution dans la dernière phase : la phase d'exploitation, et plus particulièrement pour l'émergence globale par croisement.

Nous avons expliqué l'utilité des métriques pour son achèvement. Nous savons que le schème émergent doit être analysé en détail dans sa constitution et par rapport aux autres schèmes. Nous devons donc déterminer exactement où et comment utiliser des métriques.
### 5.3.1. Détection des métriques nécessaires grâce à la technique GQM

Nous adoptons pour cela la technique GQM [Basili& 84] :

#### 5.3.1.1. Définition de la technique GQM

La technique GQM propose une démarche pour déterminer et situer de manière précise à quelle étape dans un processus quelconque (conception, évolution, maintenance...), l'utilisation d'une métrique peut être utile. Cette approche est approuvée comme étant efficace pour sélectionner et implémenter des métriques. Son nom Goal-Question-Metric résume sa démarche. Celle-ci consiste à :

- Définir les *objectifs* (Goal) à atteindre ;

- Se poser les *questions* (Question) qui peuvent être décomposées en sous-questions jusqu'à obtenir des réponses suffisamment terminales pour être *quantifiées* (Metric).

<figure><img src="image_47.png" /><figcaption>Figure 5-1: démarche descendante de la technique GQM.</figcaption></figure>

Le résultat de l'application de la technique GQM est la spécification d'un ensemble de mesures en adéquation avec les objectifs. Pour que la technique soit efficace, il est nécessaire de déterminer avec précision pour chaque objectif :

- La caractéristique de la qualité associée à l'objectif ;

- L'objet (ou le processus) sur lequel porte l'objectif ;

- Le point de vue adopté ;

- Le but de l'objectif.
Certes, cette démarche ne dit pas comment déterminer et distinguer de manière détaillée l'application des étapes, mais nous estimons qu'en ayant une connaissance suffisante du système étudié, et en la combinant avec cette démarche, cela peut nous permettre de cerner les parties d'un processus d'évolution et de dégager les aspects susceptibles d'être mesurés.

### 5.3.1.2. Première application de la technique GQM pour un processus d'évolution de GENOME

Une première application de la technique sur un processus d'évolution nécessite une première décomposition. Nous appliquons cette décomposition naturellement sur les trois phases de tout processus d'évolution. Nous appliquons les étapes sur le déroulement d'un processus d'évolution tout en gardant en vue que le principal objectif est la simulation de l'évolution d'un modèle suite à une situation de changement imprévue sur une ou plusieurs instances :
<table><caption>Tableau 5-4: une première application de la technique GQM.</caption><thead><tr><th>Phase</th><th>Objectif(s)</th><th>Question</th><th>Nécessité de Mesurer (O/N) ?</th><th>Métrique</th></tr></thead><tbody><tr><td>Extraction</td><td>Extraire le schème temporaire de l'instance ayant évolué</td><td>-</td><td>N</td><td>-</td></tr><tr><td rowspan="2">Exploration</td><td>trouver une population adaptée</td><td>son adaptation au schème temporaire</td><td>O</td><td>Va</td></tr><tr><td>trouver des classes adaptées</td><td>leur adaptation au schème temporaire</td><td>O</td><td>Va</td></tr><tr><td rowspan="3">Exploitation</td><td>détecter le processus de développement</td><td>une classe adaptée au schème temporaire</td><td>O</td><td>Va</td></tr><tr><td>détecter le processus d'émergence :<br/>- locale<br/>- globale</td><td>une classe adaptée au schème temporaire + de nouveaux attributs</td><td>O</td><td>Va</td></tr><tr><td></td><td>plusieurs classes partiellement adaptées au schème temporaire + éventuellement de nouveaux attributs</td><td>O</td><td>Va + d.s</td></tr></tbody></table>

Cette décomposition reste assez générale. Pour chaque phase, nous déterminons (en fait nous rappelons) le principal *objectif*, la principale *question* qui précise cet objectif. Avant de parler de métrique pour une question, nous estimons qu'il est en premier lieu nécessaire de s'enquérir de la pertinence d'utiliser ou non une métrique. Si elle est nécessaire, nous précisons alors la métrique.

Nous arrêtons la décomposition à ce stade pour introduire les métriques dans notre modèle.

### 5.3.2. Les métriques et GENOME

Nous nous inspirons de quelques métriques orientées objet et nous en proposons de nouvelles.

Les métriques orientées objet dont nous nous inspirons sont celles dont les contextes d'utilisation sont semblables aux nôtres. Comme nous nous intéressons à l'évolution de produit dans ses différentes composantes (classes, hiérarchies de classes, instances), nous nous intéressons aux métriques portant sur le produit : les métriques de contexte classe et les métriques de contexte application.
Quant aux métriques que nous proposons, nous déterminons en premier lieu les contextes d'utilisation pertinents pour les processus d'évolution et par conséquent pour le modèle via les concepts qui sont manipulés par les processus d'évolution. Étant donné que nous voulons analyser des structures conceptuelles émergentes<fnref n="6" /> aussi bien dans leur constitution interne que dans leur positionnement par rapport à la hiérarchie de classes, nous dégageons deux contextes d'utilisation de métriques :

- le contexte intra-structure : définit des métriques qui donnent des indications sur la constitution d'un schème émergent ;

- le contexte inter-structures : définit des métriques qui donnent des indications sur la corrélation d'un schème émergent avec son environnement : hiérarchie de classes et applications.

Nous présentons alors la deuxième application de la technique GQM. Elle constitue une décomposition détaillée de la précédente.

### 5.3.2.1. Deuxième application de la technique GQM pour un processus d'évolution de GENOME

La seconde application que nous faisons suit une décomposition de chaque question posée. Cette décomposition se fait au vu des objectifs et des questions préalablement dégagés (Tableau 5-4) tout en prenant en compte les deux contextes *intra-structure* et *inter-structures* lorsque cela s'avère nécessaire. Lors de cette seconde décomposition, nous introduisons, en plus de la précédente décomposition, des sous-questions si nous le jugeons nécessaire ainsi que des commentaires.

Nous développons plus en détails les questions sur la nécessité de mesurer sur la **phase d'exploitation** dans le tableau suivant. La lecture de ce tableau est rattachée aux sections suivantes :

<footnote n="6">⁶ On crée une structure conceptuelle émergente après avoir définitivement choisi un schème émergent.</footnote>
<table><thead><tr><th>Processus</th><th>Question</th><th>Sous-questions</th><th>Métriques</th><th>Commentaires</th></tr></thead><tbody><tr><td>Développement</td><td>une classe adaptée au schème temporaire et aucun nouvel attribut</td><td>-</td><td>Va</td><td>Traité dans la littérature (cité dans chapitre 3).</td></tr><tr><td rowspan="2">Émergence Locale</td><td>une classe adaptée au schème temporaire et de nouveaux attributs introduits par l'instance</td><td>-</td><td>Va</td><td>Traité dans chapitre 5</td></tr><tr><td>plusieurs classes adaptées au schème temporaire et de nouveaux attributs introduits par l'instance</td><td></td><td>Va+d.s</td><td>Traité dans chapitre 5.</td></tr><tr><td rowspan="4">Émergence Globale</td><td rowspan="3">Contexte intra-structure :<br/>par rapport à la constitution du schème émergent</td><td>Le schème émergent le plus significatif ?</td><td>S = écart entre un schème émergent et l'instance</td><td>Le schème le plus proche de l'instance (complète la d.s)</td></tr><tr><td>Le schème émergent le moins contradictoire ?</td><td>C<sub>t</sub> = nombre de contradictions entre attributs et blocs d'attributs</td><td>Le plus faible dénote le moins de contradictions</td></tr><tr><td>Le schème émergent le plus cohérent ?</td><td>C<sub>h</sub> = nombre d'attributs simples + nombre de contradictions entre attributs + nombre de blocs d'attributs + nombre de contradictions entre blocs d'attributs</td><td>Le plus faible dénote le moins d'incohérences</td></tr><tr><td>Contexte inter-structures :</td><td>Parents du schème émergent dans la hiérarchie ?</td><td>Détection de super-classe(s)</td><td>C'est la distance sémantique</td></tr></tbody></table>
<table><caption>Tableau 5-5: application approfondie de la technique GQM.</caption><tr><td rowspan="3">Le schème émergent par rapport aux autres classes de la hiérarchie</td><td>Contradiction du schème émergent par rapport aux parents ?</td><td>C<sub>d</sub> = Nombre d'attributs contradictoires + Nombre de blocs contradictoires ou contenant des contradictions</td><td>Le plus faible dénote le moins de contradictions</td></tr><tr><td>Couplage du schème émergent avec les autres classes ?</td><td>C<sub>p</sub> = somme des appels et références vers et des autres classes</td><td>Le plus faible dénote le minimum de couplage</td></tr><tr><td>Profondeur du schème émergent dans le graphe ?</td><td>P<sub>d</sub> = position dans le graphe d'héritage</td><td>Plus il est élevé, plus il y aura de réorganisation</td></tr></table>

Nous remarquons que la notion de contexte est utile uniquement dans le cadre de l'émergence globale, et plus particulièrement pour l'émergence globale par croisement. Par conséquent, les métriques que nous proposons se départagent en :

- des métriques de contexte intra-structure

et

- des métriques de contexte inter-structures.

Elles se définissent comme suit :

### 5.3.2.2. Métriques de Contexte Intra-structure

#### 1) - Définition

Les métriques de contexte intra-structure fournissent des indications sur la constitution interne d'un schème émergent. L'objectif est principalement de mesurer les écarts et les contradictions qu'il peut y avoir au sein d'un schème émergent.

Un schème émergent peut être constitué d'attributs simples et de blocs d'attributs. Un attribut simple est un attribut représenté par un gène présent dans un schème sans être rattaché à un bloc de gènes. Un bloc d'attributs est un bloc de gènes GH ou GS transmis au schème émergent tout au long du croisement par son schème parent dominant. Un gène appartenant à un bloc de gènes GH ou GS ne peut pas être dissocié des autres gènes constitutifs du même bloc (la contrainte de blocs de gènes).

Aussi, les métriques de contexte inter-structures considèrent les attributs simples et les blocs d'attributs de la même manière, c'est-à-dire comme un attribut indivisible. La seule distinction faite entre un attribut simple et un bloc d'attributs est que le premier n'est pas associé à d'autres attributs alors que le second peut être associé à un autre
bloc. En effet, un bloc de gènes GH peut être associé à un bloc GS et inversement, les deux formant une structure conceptuelle présente dans la population de classes. Par exemple, la classe Permanent est définie au travers du bloc GH constitué de *Thème-Recherche, Laboratoire, Nbr-Publications et du bloc GS constitué de Date-début* ; alors que pour la classe *Chercheur*, il y a uniquement le bloc GS.

Nous définissons trois métriques intra-structure :

## 2) - Métrique de Signification S

Cette métrique est définie pour privilégier un schème émergent qui serait le plus significatif par rapport à l'instance ayant évolué. En d'autres termes, le schème émergent le plus proche du schème temporaire.

Sa valeur est déterminée en faisant le décompte des gènes du schème émergent qui sont absents du schème temporaire. La métrique S est donc l'écart en nombre de gènes entre le schème émergent et le schème temporaire.

Elle est notée :

$$S(SE) = \sum_{i=1}^{n} S_{i}$$

avec :
$n$ : la longueur des deux schèmes temporaire et émergent
$S_i$ : la signification locale sur le gène en position $i$ définie par :

$$S_i = \begin{cases} 1 & \text{si} \\ 0 & \text{sin on} \end{cases} \left( (SE_i = 1) \lor (SE_i = #) \land (ST_i = #) \right)$$

avec :
$SE$ : Schème Émergeant
$ST$ : Schème Temporaire
$SE_i$ : gène à la position $i$ de $SE$
$ST_i$ : gène à la position $i$ de $ST$

La métrique S est complémentaire de la d.s.

*Interprétation* : le schème émergent présentant la plus faible signification S est le plus proche du schème temporaire, donc de l'instance ayant évolué.
### 3) - Métrique de Contradiction $C_t$

Cette métrique est définie pour détecter d'éventuelles contradictions entre l'instance ayant évolué et un schème émergent, donc les éventuelles contradictions entre le schème temporaire et un schème émergent.

Une contradiction est détectée à chaque fois que pour le même gène, sa valeur dans le schème temporaire et sa valeur dans le schème émergent sont contradictoires, c'est-à-dire pour tout couple de valeurs (1,0) ou (0,1). En effet, une telle combinaison pose problème :

<figure><img src="image_48.png" /></figure>

La métrique $C_t$ est donc le nombre de contradictions entre le schème temporaire et le schème émergent.

Elle est notée :

$$C_t(SE) = \sum_{i=1}^{n} C_{t_i}$$

avec :

$n$ : la longueur des deux schèmes temporaire et émergent

$C_{t_i}$ : la contradiction locale sur le gène en position $i$ définie par :

$$C_{t_i} = \begin{cases} 1 & \text{si} \quad ((ST_i = 1) \land (SE_i = 0)) \\ & \lor ((ST_i = 0) \land (SE_i = 1)) \\ 0 & \text{sin on} \end{cases}$$

avec :

SE : Schème Émergeant

ST : Schème Temporaire

$SE_i$ : gène à la position $i$ de SE

$ST_i$ : gène à la position $i$ de ST

Interprétation : la plus faible $C_t$ dénote le moins de contradictions. Plus elle est faible, plus le schème émergent est éligible.
## 4) - Métrique pour la Cohérence $C_h$

Cette métrique est définie pour la cohésion entre les attributs (donc les gènes) constitutifs d'un schème émergent. Les deux précédentes métriques prennent en compte le schème temporaire, contrairement à celle-ci.

Sa valeur est déterminée en faisant le décompte de gènes indépendants (nous entendons par gène indépendant un gène représentant un attribut simple ainsi qu'un bloc de gènes qui n'est associé à aucun autre), ainsi que le nombre de contradictions entre attributs (simples ou en blocs). Ces contradictions sont celles définies par le concepteur et présentes dans le modèle. Par exemple, les attributs *Date-début* et *Durée* sont considérés comme contradictoires par le concepteur. Ils ne doivent donc pas être en même temps présents dans une entité (structure conceptuelle, schème, instance), de la même manière que le bloc GS d'un permanent ne peut pas être présent en même temps que le bloc GS d'un temporaire.

La métrique $C_h$ est donc le nombre d'attributs simples, le nombre de blocs d'attributs et le nombre de blocs d'attributs indépendants.

Elle est notée :

$$C_h(SE) = \sum \text{attributs simples} + \sum \text{contradictions entre attributs simples} + \sum \text{nombre de blocs d'attributs} + \sum \text{contradictions entre blocs d'attributs}$$

*Interprétation* : la plus faible $C_h$ dénote le moins d'incohérences. Une trop forte valeur de $C_h$ révélerait une constitution trop disloquée du schème émergent et donc peu de cohésion interne. Cela peut donc dénoter une mauvaise encapsulation. Il sera difficile de spécifier la structure conceptuelle au sein d'une classe, et encore plus difficile de l'insérer dans la hiérarchie de classes représentant sa population.

## 5) - Conclusion sur l'utilisation des métriques intra-structure

Les métriques de contexte intra-structure sont particulièrement utiles pour choisir un seul schème parmi plusieurs schèmes émergents. Elles donnent au concepteur suffisamment d'indicateurs. Elles sont efficaces du moment que pour une même métrique, plusieurs valeurs (une par schème émergent) peuvent être comparées. Il n'est donc pas nécessaire de les utiliser lorsque le croisement fournit un seul schème émergent. Le concepteur peut toutefois y faire appel s'il veut avoir quelques indications sur ce schème. Il doit interpréter lui-même les valeurs obtenues, étant donné qu'il n'a pas de valeurs de comparaison.

Les métriques suivantes permettent d'avoir des indicateurs pour le schème émergent par rapport aux autres classes du modèle, qu'il soit unique ou sélectionné après avoir utilisé les métriques intra-structure.
### 5.3.2.3. Métriques de Contexte Inter-structures

#### 1) - Définition

Les métriques de contexte inter-structures fournissent des indications sur le schème émergent par rapport à sa population. Les différentes métriques portent sur la mesure des écarts et des contradictions que peut avoir un schème émergent avec les autres classes de la population, ainsi que les classes potentiellement parentes (c'est-à-dire des super-classes potentielles) et les interactions avec les autres classes.

Le principal objectif de ces métriques est de donner des indicateurs pour positionner une nouvelle structure conceptuelle, véhiculée par le schème émergent, par rapport aux classes de la même population. Pour cela, les métriques de contexte inter-structures s'appliquent sur deux schèmes à la fois : le schème émergent et un schème permanent.

Nous définissons quatre métriques de contexte inter-structures :

#### 2) - Métrique Distance Sémantique d.s

Cette métrique a été préalablement définie et illustrée dans le précédent chapitre (Chapitre 4 - Section 4.3.7). Elle est évaluée en l'appliquant à chacune des classes ayant participé au croisement par comparaison avec le schème émergent.

*Interprétation* : la plus forte d.s présuppose une classe parente. Une d.s trop faible présuppose l'élimination de la classe en tant que classe parente potentielle. Nous rappelons que nous entendons par classe parente pour un schème émergent, une classe qui peut devenir la super-classe de la structure conceptuelle véhiculée par ce même schème émergent.

#### 3) - Métrique de Contradiction $C_d$

Cette métrique est définie pour détecter les contradictions qui peuvent exister entre un schème émergent et un schème permanent. Ces contradictions peuvent exister entre des attributs simples et des blocs d'attributs. Le principe de cette métrique est similaire à celle de la métrique de contradiction $C_t$ de contexte intra-structure.

La métrique de contradiction $C_d$ revient à dénombrer le nombre d'attributs contradictoires, le nombre de blocs contradictoires, ainsi que la vérification des invariants du modèle de classes exprimés sur la branche de la hiérarchie de la classe du schème permanent qui est en comparaison avec le schème émergent.

Elle est notée :

$$C_d(SE, SP) = \sum_{i=1}^{n} C_{d_i}$$

avec : $n$ : la longueur des deux schèmes permanent et émergeant
$C_{d_i}$ : la contradiction locale sur le gène en position $i$ définie par :

$$C_{d_i} = \begin{cases} 1 & \text{si } ((SP_i = 1) \land (SE_i = 0)) \\ 0 & \text{sin on} \end{cases}$$

avec :
* SE : Schème Émergeant

* SP : Schème Permanent

* $SE_i$ : gène à la position $i$ de SE

* $SP_i$ : gène à la position $i$ de SP

Sachant qu'un gène en position $i$ peut représenter un attribut simple ou un bloc d'attributs.

*Interprétation* : la plus faible $C_d$ dénote le moins de contradictions entre le schème émergeant et le schème permanent. Plus elle est faible, plus la classe associée au schème permanent peut être considérée comme éligible comme classe parente (donc comme super-classe) de la structure conceptuelle véhiculée par le schème émergeant.

Les deux dernières métriques sont des métriques orientées objet standards.

## 4) - Métrique de Couplage $C_p$

Cette métrique est définie pour déterminer le couplage de la nouvelle structure conceptuelle avec toutes les autres classes du modèle (de la même population et éventuellement d'autres populations existant dans l'application). Cette métrique s'inspire de la métrique de couplage de contexte classe (section 5.2.3.2).

La métrique de couplage $C_p$ s'applique au niveau de la conception et doit donc prendre en compte les différentes manières dont une classe peut être couplée. Dans [Briand 97], ils présentent trois modes possibles : *Classe-Attribut* (CA) où un attribut de la classe a un paramètre qui a pour type une autre classe, *Classe-Méthode* (CM) où une méthode de la classe a un paramètre qui a pour type une autre classe, et *Méthode-Méthode* (MM) où une méthode de la classe a un paramètre qui a pour type une méthode d'une autre classe.

Pour notre part, étant donné que nous travaillons essentiellement sur la structure, la métrique de couplage $C_p$ s'intéresse aux couplages de type CA et également de type CM si les méthodes sont spécifiées, ne serait-ce que dans leur signature. Sinon, elle s'applique uniquement sur les couplages du type CA.

La métrique de couplage $C_p$ s'applique sur un schème émergeant. Elle permet de déterminer à quel point ce schème émergeant sollicite et peut être sollicité dans le modèle. Elle est notée :
$$C_p(SE) = \sum CA + [\sum CM]$$

*Interprétation* : un trop fort couplage peut être pénalisant en termes de coûts de réorganisation de la hiérarchie de classes lors de l'insertion de la nouvelle structure conceptuelle.

## 5) - Métrique de Profondeur $P_d$

Cette métrique est définie pour situer à quel niveau dans la hiérarchie sera insérée la nouvelle structure conceptuelle.

La métrique $P_d$ est notée :

$$P_d(SE) = \text{Niveau (Classe Parent)} + 1$$

*Interprétation* : cette métrique permet d'évaluer les impacts plus ou moins importants de l'insertion de la structure conceptuelle émergente dans la hiérarchie de classes. Pour être facilement interprétée, elle doit être comparée à la profondeur de l'arbre d'héritage, généralement nommée *DIT* (*Depth of Inheritance Tree*) qui représente la longueur du chemin le plus long de la hiérarchie depuis la classe racine jusqu'à la plus lointaine classe feuille qui en hérite [Chidamber & 91].

## 6) - Conclusion sur l'utilisation des métriques inter-structures

Les quatre métriques inter-structures s'appliquent sur le schème émergent. Chacune permet de donner des indications sur chaque schème permanent potentiellement éligible par rapport au schème émergent. Elles sont nécessaires pour déterminer la classe qui pourra être la super-classe de la structure conceptuelle émergente.

L'objectif principal étant de dégager une classe potentiellement parente, les métriques de contexte inter-structures peuvent par contre connaître une dépendance entre elles quant à leur application. En effet, la première métrique inter-structures à appliquer est la d.s. Elle permet d'emblée d'éliminer les classes qui ont une très faible distance sémantique, c'est-à-dire celles qui présentent très peu de similitudes avec le schème émergent. Elle permet également de mettre en évidence celles qui présentent une forte d.s. Dans le cas où l'application de la d.s. serait suffisante pour déterminer une seule classe qui présente une forte d.s, il n'est pas nécessaire de poursuivre l'application des autres métriques, car la classe potentiellement parente est trouvée avec la d.s. La d.s est alors une métrique qui est à la fois nécessaire et suffisante pour trouver la classe potentiellement parente. Les autres métriques inter-structures pourront par contre être utilisées si le concepteur veut des indications supplémentaires sur la structure conceptuelle émergente et les conséquences de son insertion dans la hiérarchie de classes.

Dans certains cas, la d.s à elle seule ne suffit plus. Elle est toujours une métrique nécessaire mais n'est plus suffisante pour trouver la classe potentiellement parente. Les autres métriques sont alors utilisées.
La métrique de contradiction $C_d$ s'appuie sur une analyse des blocs de gènes et des gènes indépendants. La première métrique, la d.s, comme nous l'avons vu dans le précédent chapitre, s'appuie sur la comparaison des gènes du schème émergent avec ceux d'un schème permanent. En combinant les valeurs obtenues pour la métrique de contradiction $C_d$ avec celles obtenues pour la d.s, l'interprétation peut être plus riche. En effet, une classe qui présente une d.s intéressante pour un schème émergeant mais qui, en même temps présente trop de contradictions avec ce même schème peut aboutir à son élimination comme classe potentiellement parente.

Les deux dernières métriques, celle de Couplage $C_p$ et celle de Profondeur $P_d$ s'inspirent directement de métriques orientées-objets [Chidamber& 91], [Sahraoui 99]. La métrique de profondeur $P_d$ permet de connaître l'endroit d'insertion de la nouvelle structure conceptuelle. Cette insertion est gérée dans le cadre d'un processus de développement (Chapitre 5 – Section 4.6 - ).

Après avoir présenté les deux catégories de métriques et après avoir expliqué l'utilisation des métriques de chacune des deux catégories, nous abordons leur utilisation au vu des besoins pour mener à terme le processus d'émergence et également au vu des invariants du système.

### 5.3.3. L'application des métriques et les invariants

La principale question qui se pose est :

*Comment et surtout quand et dans quelle séquence (ou en parallèle) appliquer les différentes métriques sur les schèmes émergents ?*

Étant donné que l'objectif premier est la simulation de l'évolution d'un modèle de classes au vu de changements dynamiques dans la structure des instances, le concepteur décide à la fois des changements qu'il veut exprimer sur des instances et du moment où il veut déclencher le processus de simulation.

De la même manière, nous offrons au concepteur la possibilité d'exprimer des invariants à respecter par le processus d'évolution à différents niveaux :

#### 5.3.3.1. Invariants sur les instances

Outre les invariants déjà présents dans les spécifications du modèle, le concepteur peut exprimer des invariants sur les instances en précisant les attributs qu'il veut avoir dans la structure conceptuelle finale, par 1 pour le gène correspondant dans le schème, et les attributs qu'il ne veut pas voir apparaître dans l'instance, par un 0 dans le schème temporaire associée à l'instance ayant évoluée. Les attributs qu'il considère comme indifférents ou sur lesquels il a un doute, seront à #.
### 5.3.3.2. Invariants sur les résultats de l'émergence

Outre ce premier type d'invariants, le concepteur peut également préciser des invariants sur l'évolution. Cela revient à exprimer des invariants sur les résultats de l'émergence. Ces invariants mettent en jeu les métriques précédemment définies. Ils déterminent également la manière dont elles seront utilisées et si leur application est totale ou sélective.

Le concepteur peut par exemple préciser qu'il préfère une structure conceptuelle émergente qui provoquerait le moins possible de réorganisation. La simulation d'évolution devra prendre en compte cet invariant. L'invariant revient à la « *stabilité du modèle de classes* ». Parmi les métriques proposées, celle de couplage $C_p$ est plus adaptée que les autres métriques. Elle est donc privilégiée. Le concepteur peut également préférer une structure conceptuelle émergente de plus haut niveau possible dans la hiérarchie.

Le tableau suivant résume selon l'invariant imposé par le concepteur, la métrique inter-structures qui lui est associée et qui est prépondérante dans le choix de la classe parente pour la nouvelle structure conceptuelle :
<table><caption>Tableau 5-6: métriques inter-structures et invariants associés.</caption><thead><tr><th>Métrique Inter-structures</th><th>Invariants associés</th><th>Conséquences</th></tr></thead><tbody><tr><td>Métrique Distance Sémantique d.s</td><td>Elle est obligatoire. Il n'y a donc pas d'invariant associé.</td><td>-</td></tr><tr><td rowspan="2">Métrique de Contradiction C<sub>d</sub></td><td>Les contradictions ne sont pas prépondérantes</td><td>La classe sélectionnée peut présenter des contradictions. Son insertion nécessite alors un effort de révision dans ses spécifications. Cette métrique sera uniquement indicative.</td></tr><tr><td>Une structure conceptuelle avec le minimum de contradictions</td><td>La classe sélectionnée sera la plus cohérente possible. Son insertion dans la hiérarchie peut se faire sans modifications majeures. Cette métrique sera prépondérante.</td></tr><tr><td rowspan="2">Métrique de Couplage C<sub>p</sub></td><td>Le degré de couplage n'est pas prépondérant</td><td>La structure conceptuelle émergente peut être fortement couplée. Cette métrique sera uniquement indicative.</td></tr><tr><td>Le degré de couplage doit être minimal</td><td>La structure conceptuelle émergente doit être faiblement couplée. Cette métrique sera prépondérante.</td></tr><tr><td rowspan="2">Métrique de Profondeur P<sub>d</sub></td><td>Les efforts de réorganisation ne sont pas prépondérants</td><td>La structure conceptuelle émergente peut engendrer des coûts et des efforts pour gérer les impacts de son insertion. Cette métrique sera uniquement indicative.</td></tr><tr><td>La classe doit engendrer un minimum de réorganisation</td><td>La structure conceptuelle émergente devra être sélectionnée de manière à éviter un minimum de réorganisation suite à son insertion. Cette métrique sera prépondérante.</td></tr></tbody></table>

Ces invariants sont prépondérants dans le choix des métriques à appliquer sur les schèmes émergents. Ils peuvent par conséquent imposer l'ordre de leur application, voire même réduire les métriques à appliquer. Dans le cas où une classe répondrait à l'invariant imposé par le concepteur et que par ailleurs, elle présente des valeurs médiocres pour les autres métriques, elle n'est pas rejetée. Cette classe ainsi que les différentes valeurs qu'elle a obtenues sont présentées au concepteur qui a la charge d'accepter et de prendre en compte les différents résultats, ou de rejeter ses choix et de recommencer l'application des métriques, voire de la simulation de l'évolution.

Dans le cas où le concepteur ne préciserait pas d'invariants, seules les métriques nécessaires pour choisir un schème émergent sont appliquées. D'autres métriques
peuvent être utilisées dans le cas ou celles qui ont été appliquées ne suffisent pas à
démarquer les schèmes émergents entre eux.

En effet, les métriques de contexte intra-structure se complètent avec les métriques inter-structures pour enrichir le processus d'émergence globale par croisement. Les premières sont utiles pour le choix d'un schème émergent, lorsqu'il y a un choix à faire entre plusieurs schèmes émergents. La seconde catégorie de métriques s'applique de manière indépendante de la première. Parmi les métriques inter-structures que nous appliquons par défaut, ce sont les deux premières métriques pour :

- Déterminer la ou les super-classes grâce à la distance sémantique d.s.

- Détecter d'éventuelles contradictions entre les schèmes émergents et chaque classe potentiellement parente. Cette métrique peut influencer le choix définitif de schèmes émergents et de super-classe(s).

Les deux autres métriques peuvent influencer le choix si le concepteur les activent comme étant importantes. De la même manière, elles peuvent influencer les choix finaux.

La section suivante permet d'illustrer l'utilisation des métriques. Nous revenons sur les deux exemples de croisement qui n'ont pas pu être menés à terme en utilisant uniquement la d.s.

## 5.4 - Exemples

Nous partons des résultats de l'émergence globale par croisement de la fin du chapitre 5 - Section 4.5.2.2, qui relèvent les manques de l'émergence et des exemples qui n'ont pas pu être traités complètement, notamment les objets $O_1$ et $O_5$. Le premier a eu deux schèmes émergents. Le second a eu un seul schème émergent, mais deux parents du croisement qui ont la même distance sémantique.

Nous appliquons les différentes métriques pour chacun des cas :

### 5.4.1. Exemple de l'objet $O_1$

Reprenons l'objet $O_1$ avec les deux schèmes émergents :
<table><caption>Tableau 5-7: les deux schèmes émergents E4 et E5 pour O₁.</caption><thead><tr><th></th><th>1</th><th>2</th><th>3</th><th>4</th><th>5</th><th>6</th><th>7</th><th>8</th><th>9</th><th>10</th><th>11</th><th>12</th></tr></thead><tbody><tr><th>O<sub>1</sub></th><td>1</td><td>1</td><td>#</td><td>#</td><td>1</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>#</td><td>Va</td></tr><tr><th>E4</th><td>1</td><td>1</td><td>1</td><td>0</td><td>1</td><td>0</td><td>1</td><td>0</td><td></td><td></td><td>1</td><td>#</td><td>5/5=1</td></tr><tr><th>E5</th><td>1</td><td>1</td><td>#</td><td>1</td><td>1</td><td>0</td><td>1</td><td>0</td><td></td><td></td><td>1</td><td>0</td><td>5/5=1</td></tr></tbody></table>

Les gènes sont numérotés de 1 à 12, avec les gènes en positions 9 et 10 qui ne sont pas considérés étant donné qu'aucun des schèmes considérés ne les spécifient.

Ayant deux schèmes émergents, il est nécessaire d'en choisir un, avant de rechercher à quelle classe de la population rattacher la structure conceptuelle qu'il sous-tend. Les métriques de Contexte intra-structure sont nécessaires pour élire un schème émergent :

### 5.4.1.1. Métriques Contexte intra-structure

Les métriques intra-structure sont appliquées pour chaque schème émergent :

<table><caption>Tableau 5-8: applications des métriques intra-structure pour les schèmes émergents de l'objet O₁.</caption><thead><tr><th rowspan="2">Métrique</th><th colspan="2">Valeur</th><th rowspan="2">Conclusions</th></tr><tr><th>Schème émergent E<sub>4</sub></th><th>Schème émergent E<sub>5</sub></th></tr></thead><tbody><tr><td>Signification S</td><td>S(E<sub>4</sub>) = 2 les gènes 3 et 12</td><td>S(E<sub>5</sub>) = 2 les gènes 3 et 4</td><td>S(E<sub>4</sub>) =<br>S(E<sub>5</sub>)=2<br>valeurs non<br>significatives</td></tr><tr><td>Contradiction C<sub>t</sub></td><td>C<sub>t</sub>(E<sub>4</sub>) = 0</td><td>C<sub>t</sub>(E<sub>5</sub>) = 0</td><td>Aucune<br>contradiction</td></tr><tr><td>Cohérence C<sub>h</sub></td><td>C<sub>h</sub>(E<sub>4</sub>) =OME<sub>4</sub><br>simples(E<sub>4</sub>) +OME<sub>4</sub><br>nbre de blocs indépendants(E<sub>4</sub>)<br>= 1 + 2 + 0 = 3</td><td>C<sub>h</sub>(E<sub>5</sub>) =OME<sub>5</sub><br>simples(E<sub>5</sub>) +OME<sub>5</sub><br>nbre de blocs indépendants(E<sub>5</sub>)<br>= 5 + 0 + 1 + 0 = 6</td><td>C<sub>h</sub>(E<sub>4</sub>)=3 ; C<sub>h</sub>(E<sub>5</sub>)=6<br>Le schème E<sub>4</sub><br>est plus<br>cohérent que<br>le schème E<sub>5</sub></td></tr></tbody></table>

**Conclusion :**

- les deux schèmes émergents présentent la même signification S=2 ;

- les deux schèmes émergents ne présentent aucune contradiction C<sub>t</sub>=0 ;
- le schème E₄ présente une plus grande cohérence que le schème E₅, Cₕ est respectivement à 3 et à 6 :

Le schème émergent E₄ est élu comme étant le schème émergent.

### 5.4.1.2. Métriques Contexte inter-structures

Une fois le schème émergent élu, nous devons rechercher à quel endroit de la hiérarchie l'insérer. Nous devons appliquer les métriques inter-structures. La première métrique à appliquer est la d.s. Si elle n'offre pas de résultats permettant de choisir, les autres métriques doivent être appliquées pour pouvoir choisir une classe parente.

Pour calculer la d.s, il est nécessaire de comparer les schèmes permanents ayant participé au croisement avec le schème émergent :

<table><caption>Tableau 5-9: application de la d.s sur le schème émergent de O₁.</caption><thead><tr><th></th><th>1</th><th>2</th><th>3</th><th>4</th><th>5</th><th>6</th><th>7</th><th>8</th><th>9</th><th>10</th><th>11</th><th>12</th></tr></thead><tbody><tr><th>O<sub>1</sub></th><td>1</td><td>1</td><td>#</td><td>#</td><td>1</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>#</td></tr><tr><th>Schème Émergeant</th><td>1</td><td>1</td><td>1</td><td>0</td><td>1</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>#</td><td>d.s</td></tr><tr><th>Enseignant</th><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>1/7</td></tr><tr><th>Ater</th><td>1</td><td>1</td><td>#</td><td>0</td><td>1</td><td>1</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>4/7</td></tr><tr><th>Senior-Chercheur</th><td>1</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>#</td><td>6/7</td></tr></tbody></table>

Senior-Chercheur est la classe qui présente la plus grande distance sémantique : 6/7. Cette valeur est forte. La classe Senior-Chercheur est donc éligible comme classe parente de la structure conceptuelle émergente.

**Conclusion** : il est proposé au concepteur de créer la structure conceptuelle émergente véhiculée par le schème émergent comme sous-classe de Senior-Chercheur. Ce choix est d'autant plus cohérent que le schème émergent et Senior-Chercheur présentent le même bloc GH. Tout porte donc à considérer la structure conceptuelle émergente comme étant effectivement une spécialisation de Senior-Chercheur.

Étant donné que la d.s est suffisante pour cet exemple et étant donné qu'il n'y a pas d'invariants particuliers, les métriques de *couplage* et de *profondeur* ne sont pas utiles pour le choix final. Elles sont uniquement instructives. A titre d'exemple, en notant *ref* toutes les références du schème et *est-ref* toutes les fois où le schème est référencé, les valeurs de *couplage* pour le schème sont :

$$C_p(E_4) = \Sigma_{ref} + \Sigma_{est-ref} = 5 + 0 = 5$$
Le choix précédent peut être conforté par les valeurs des autres métriques inter-structures. Nous rappelons la d.s et nous appliquons les trois autres métriques :

<table><caption>Tableau 5-10: Métriques inter-structures sur le schème émergent de O<sub>1</sub>.</caption><thead><tr><th>Métrique</th><th>Valeur</th><th>Conclusions</th></tr></thead><tbody><tr><td rowspan="3">Distance sémantique d.s</td><td>d.s(Enseignant) = 1/7</td><td>Éliminée</td></tr><tr><td>d.s(Ater) = 4/7</td><td>Moyennement éligible</td></tr><tr><td>d.s(Senior-Chercheur) = 6/7</td><td>Fortement éligible</td></tr><tr><td rowspan="2">Contradiction C<sub>d</sub></td><td>C<sub>d</sub>(E<sub>4</sub>, Ater) = 1</td><td>Pénalisant</td></tr><tr><td>C<sub>d</sub>(E<sub>4</sub>, Senior-Chercheur) = 0</td><td>Favorable</td></tr><tr><td>Couplage C<sub>p</sub></td><td>C<sub>p</sub>(E<sub>4</sub>) = 5</td><td>-</td></tr><tr><td>Profondeur P<sub>d</sub></td><td>P<sub>d</sub>(E<sub>4</sub>) = 5</td><td>-</td></tr></tbody></table>

**Conclusion:** en appliquant la métrique de contradiction sur le schème émergent et chacune des deux classes qui présentent une d.s assez bonne, à savoir Ater et Senior-Chercheur, il apparaît que E<sub>4</sub> présente une contradiction avec Ater (E<sub>4</sub> spécifie l'attribut *Date-Début* alors que Ater spécifie l'attribut *Durée*; ces deux attributs sont exclusifs) alors qu'il n'en présente aucune avec Senior-Chercheur. Ce résultat conforte le premier choix fait avec la d.s.

Les deux dernières métriques n'apportent aucune information qui puisse influencer d'une manière ou d'une autre le choix de la classe parente. Elles sont purement informatives.

Appliquons les métriques sur le schème émergent de l'objet O<sub>5</sub>.

### 5.4.2. Exemple de l'objet O<sub>5</sub>

Dans le cas de l'objet O<sub>5</sub>, il y a un seul schème émergent. Il reste à déterminer ses parents. Les métriques de contexte intra-structure ne sont pas utiles. Elles peuvent par contre donner un peu plus d'indications au concepteur sur la constitution du schème :

#### 5.4.2.1. Métriques Contexte intra-structure

L'application des métriques intra-structure pour le schème émergent E<sub>5</sub> donne :
<table><caption>Tableau 5-11: Métriques intra-structures sur le schème émergent de O<sub>5</sub>.</caption><thead><tr><th>Métrique</th><th>Valeur</th><th>Conclusions</th></tr></thead><tbody><tr><td>Signification S</td><td>S(E<sub>5</sub>) = 2</td><td>valeur non significative</td></tr><tr><td>Contradiction C<sub>t</sub></td><td>C<sub>t</sub> (E<sub>5</sub>) = 0</td><td>aucune contradiction avec l'objet O<sub>5</sub></td></tr><tr><td>Cohérence C<sub>h</sub></td><td>C<sub>h</sub> (E<sub>5</sub>) = nbr d'attributs simples(E<sub>5</sub>) +<br/>nbr de blocs(E<sub>5</sub>) + nbr de blocs<br/>indépendants(E<sub>5</sub>)<br/>= 3 + 0 + 2 + 0 = 5</td><td>non significative<br/>toute seule, sauf<br/>qu'elle révèle<br/>l'absence de<br/>contradictions</td></tr></tbody></table>

**Conclusion:** les métriques de contexte intra-structure n'apportent aucune information dans ce cas, sauf qu'il n'y a pas de contradiction au sein du schème émergent E<sub>5</sub>.

L'application des métriques inter-structures est plus utile :

### 5.4.2.2. Métriques Contexte inter-structures

Nous devons rechercher à quel endroit de la hiérarchie insérer la structure conceptuelle émergente véhiculée par le schème émergent E<sub>5</sub>. Pour calculer la d.s, il est nécessaire de comparer les schèmes permanents ayant participé au croisement avec les schème émergent. Le calcul de la d.s pour ce schème émergent a déjà été effectué (Chapitre 5 – Section 4.5.3.2). Nous le rappelons à ce niveau :

<table><caption>Tableau 5-12: application de la d.s sur le schème émergent de O<sub>5</sub>.</caption><thead><tr><th></th><th>1</th><th>2</th><th>3</th><th>4</th><th>5</th><th>6</th><th>7</th><th>8</th><th>9</th><th>10</th><th>11</th><th>12</th></tr></thead><tbody><tr><td>O<sub>5</sub></td><td>1</td><td>1</td><td>#</td><td>#</td><td>1</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>#</td></tr><tr><td>Schème Émergeant</td><td>1</td><td>1</td><td>#</td><td>1</td><td>1</td><td>0</td><td>1</td><td>1</td><td>0</td><td>0</td><td>1</td><td>0</td><td>d.s</td></tr><tr><td>Enseignant</td><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>2/7</td></tr><tr><td>Ater</td><td>1</td><td>1</td><td>#</td><td>0</td><td>1</td><td>1</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>5/7</td></tr><tr><td>Senior-Chercheur</td><td>1</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>#</td><td>5/7</td></tr></tbody></table>

**Conclusion:** la classe Enseignant est éliminée car elle présente une faible distance sémantique. Par contre, les deux autres classes présentent chacune une forte d.s. Par contre, elles sont identiques : 5/7.
Nous devons appliquer les trois autres métriques, même si seules les deux premières métriques sont nécessaires pour établir un choix entre les deux classes Ater et Senior-Chercheur :

<table><caption>Tableau 5-13: Métriques inter-structures sur le schème émergent de O<sub>5</sub>.</caption><thead><tr><th>Métrique</th><th>Valeur</th><th>Conclusions</th></tr></thead><tbody><tr><td rowspan="3">Distance sémantique d.s</td><td>d.s(Enseignant) = 2/7</td><td>Éliminée</td></tr><tr><td>d.s(Ater) = 5/7</td><td>Fortement éligible</td></tr><tr><td>d.s(Senior-Chercheur) = 5/7</td><td>Fortement éligible</td></tr><tr><td rowspan="2">Contradiction C<sub>d</sub></td><td>Cd(E<sub>5</sub>, Ater) = 3</td><td>Pénalisant</td></tr><tr><td>Cd(E<sub>5</sub>, Senior-Chercheur) = 0</td><td>Favorable</td></tr><tr><td>Couplage C<sub>p</sub></td><td>Cp(E<sub>5</sub>) = 5</td><td>-</td></tr><tr><td>Profondeur P<sub>d</sub></td><td>Pd(E<sub>5</sub>) = 5</td><td>-</td></tr></tbody></table>

**Conclusion:** seules les deux premières métriques sont utiles dans ce cas. Le schème émergent E<sub>5</sub> donne lieu à une structure conceptuelle émergente qui sera potentiellement une sous-classe de Senior-Chercheur.

Une fois les schèmes émergeants choisis et les classes parentes trouvées, l'émergence globale peut être achevée. Nous l'illustrons sur l'exemple en présentant l'état final du modèle de classes dans la section suivante.

## 5.5 - l'exemple final

Dans le cas de notre exemple, les processus d'évolution ont dégagé deux structures conceptuelles émergentes. Ces structures conceptuelles seront créées toutes les deux en tant que sous-classes de Senior-Chercheur. Par conséquent, elles ont en commun le même bloc GH, hormis les changements explicites. Les schèmes émergents deviennent des structures conceptuelles émergentes qui prennent en compte l'analyse des métriques appliquées :
Attributs existants

<table><caption>Tableau 5-14: les structures conceptuelles émergentes.</caption><thead><tr><th></th><th>1</th><th>2</th><th>3</th><th>4</th><th>5</th><th>6</th><th>7</th><th>8</th><th>9</th><th>10</th><th>11</th><th>12</th></tr></thead><tbody><tr><td>Schème Émergent(O1)</td><td>1</td><td>1</td><td>1</td><td>0</td><td>1</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>#</td></tr><tr><td>Schème Émergent(O2)</td><td>1</td><td>1</td><td>#</td><td>1</td><td>1</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td></tr><tr><td>Structure émergente(O1)</td><td>1</td><td>1</td><td>1</td><td>0</td><td>1</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>#</td></tr><tr><td>Structure émergente(O2)</td><td>1</td><td>1</td><td>#</td><td>1</td><td>1</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td></tr></tbody></table><table><thead><tr><th>Nouveaux attributs</th></tr></thead><tbody><tr><td>1</td><td>-</td><td>-</td></tr><tr><td>-</td><td>-</td><td>-</td></tr></tbody></table>

Une analyse des deux schèmes émergents met en évidence une similitude dans leur constitution. Seuls diffèrent le quatrième attribut, à savoir *Spécialité*, et le nouvel attribut introduit par $O_1$, à savoir *Grade* qu'il value avec *'Professeur'* . Cette constatation est soumise au concepteur. Il réalise en effet que les deux structures conceptuelles sont identiques, mis à part ces deux attributs.

Le concepteur ajuste la structure finale pour ne garder qu'une seule structure conceptuelle. Il peut choisir de garder le quatrième attribut (donc mettre le gène correspondant à l'attribut *Spécialité* à 1) et d'accepter le nouvel attribut *Grade*. Ce dernier est alors intégré dans le modèle et perd son statut transitoire.

Les deux structures conceptuelles mettent en évidence des spécificités d'un Senior-Chercheur, présentent des caractéristiques d'un Enseignant (principalement l'attribut *Module* présents dans les deux structures conceptuelles) et introduisent de nouvelles informations. Avec les choix faits, elles se sont donc complétées mutuellement. Elles sont donc représentées par une seule et même structure conceptuelle : celle d'Enseignant-Chercheur.

La classe est insérée dans la population Membre-Université comme sous-classe de Senior-Chercheur. La figure suivante met en évidence cette insertion :
<figure><img src="image_49.png" /><figcaption>Figure 5-2: Insertion d'Enseignant-Chercheur dans la population de Membre-Université.</figcaption></figure>

Les objets O₁ et O₅ sont ajustés à la nouvelle structure conceptuelle avant d'être rattachés à leur nouvelle classe. L'objet O₁, en plus de son évolution initiale, peut valuer (gène à # dans le schème permanent) en plus les attributs acquis *Spécialité* et *Projet-Recherche*. L'objet O₅, en plus de son évolution initiale, value obligatoirement (gène à 1 dans le schème permanent) les attributs *Projet-Recherche* et *Grade*.

Le lien d'évolution doit également être spécifié. Il existe en fait deux liens d'évolutions :

- un lien d'évolution ayant pour source Ater et pour cible Enseignant-Chercheur. Nous le notons L₄ ;

- un lien d'évolution ayant pour source Elève-Chercheur et pour cible Enseignant-Chercheur. Nous le notons L₅.

Le graphe d'évolution est complété. La figure suivante complète la figure 16 du chapitre 4 :
<figure><img src="image_50.png" /><figcaption>Figure 5-3: Hiérarchie de classes et Graphes de Liens d'évolution.</figcaption></figure>

En plus des liens d'évolution L₁, L₂ et L₃ créés dans le cadre des processus d'évolution des objets O₂, O₃ et O₄ (Chapitre 4), les liens L₄ et L₅ sont les deux liens d'évolution qui sont créés après avoir mené à bien les processus d'évolution des objets O₁ et O₅.

L₄ est constitué des attributs suivants :

-durée

-nbr-heures

-année

-directeurthèse

+date-début

+Equipe-Recherche

+Projet-Recherche

+spécialité

+grade

L₅ est constitué des attributs suivants :

-durée

-nombre-heures
+date-début

+Equipe-Recherche

+Projet-Recherche

+spécialité

+grade

Chacun des liens d'évolution est orienté de la source vers sa cible. Aussi, les attributs précédés d'un signe `-` sont les attributs de la source qui sont perdus et les attributs précédés du signe `+` sont les attributs acquis de la cible. C'est la structure que respectera toute instance de la classe source qui évoluera vers la classe cible.

- Enseignant-Chercheur est une nouvelle structure conceptuelle qui a été créée par croisement. Elle est une sous-classe de Senior-Chercheur. Une instance de lien d'évolution a été créée entre chacune des classes dont une instance a évoluée vers cette nouvelle structure conceptuelle. Chaque lien détient comme propriétés les attributs perdus et les attributs acquis.

- Deux nouvelles classes ont été créées par émergence directe : la classe Ingénieur comme une sous-classe de Membre-Université et Post-doc comme une sous-classe de Temporaire.

## 5.6 - Conclusion

L'émergence, et plus particulièrement l'émergence globale par croisement, est le processus d'évolution qui constitue le noyau de notre modèle. Il est primordial d'assurer la vérification et l'analyse des résultats de l'émergence dans le but de mieux les contrôler, et par conséquent de mieux décider.

Nous considérons que l'émergence peut être mesurée et contrôlée. Les résultats obtenus nécessitent de prendre en compte un critère important : la cohésion de la structure conceptuelle émergeante vis-à-vis d'elle-même et du reste du modèle.

Aussi, nous proposons l'utilisation de métriques pour mieux comprendre et analyser la constitution d'une structure conceptuelle émergente. Ces métriques sont dites *Métriques de Contexte intra-structure*. Elles permettent de déceler d'éventuelles contradictions et incohérences internes.

D'autres métriques sont utilisées pour mieux comprendre et analyser l'impact de l'insertion d'une structure conceptuelle émergente dans une hiérarchie de classes. Ces métriques sont dites *Métriques de Contexte inter-structures*. Elles permettent de trouver les super-classes potentielles de la nouvelle structure conceptuelle, de détecter d'éventuelles contradictions avec elles, et de finalement choisir une seule classe parente. Elles permettent également de connaître la position de la structure
conceptuelle émergente dans la hiérarchie ainsi que le degré de couplage de cette
structure conceptuelle avec les autres classes.

Les métriques ne sont pas toutes appliquées de manière systématique, principalement
les secondes. Les premières sont utiles pour départager entre plusieurs schèmes
émergents lorsque la situation se présente : il faut prendre le schème émergent le plus
cohérent. Les secondes sont utiles pour attirer l'attention sur les impacts d'insertion (si
les coûts ne représentent aucun souci, elles ne sont pas utiles). Aussi, étant dans le
cadre d'un outil de simulation au service du concepteur pour l'évolutivité et la
maintenabilité de systèmes dont il a la charge, le concepteur a la possibilité d'exprimer
des invariants soit sur des instances, soit sur les schèmes émergents. Ces invariants
devant être respectés, les métriques associées ont alors toute leur utilité.

Il est essentiel de préciser que le modèle que nous proposons ne répond pas de manière
absolue et sans appel à la prise en compte de tous les nouveaux besoins. Il reste un
outil de simulation pour l'aide à l'évolution et à la maintenance. La manière dont les
besoins et les invariants sont exprimés influencent grandement les résultats. De la
même manière, si des erreurs de conception existent, l'objectif n'est pas un objectif de
correction de conception mais si les résultats apparaissent trop incohérents, cela peut
dénoter une mauvaise conception ou une mauvaise spécification initiales des besoins,
et permet aussi d'attirer l'attention du concepteur.
<figure><img src="image_51.png" /></figure>
# Chapitre 6 : IMPLEMENTATION

<figure><img src="image_52.png" /></figure>
## 6.1 - Introduction

Nous abordons dans le présent chapitre une vue générale de la réalisation et de l'implémentation du modèle GENOME. Ce chapitre aborde en premier lieu le contexte et l'environnement déjà existants et par rapport auxquels GENOME doit s'intégrer. Il s'agit de l'environnement de Présage. Nous décrivons pour cela l'infrastructure de Présage. Nous présentons ensuite les choix d'implémentation de GENOME et son positionnement par rapport à l'infrastructure de Présage.

La seconde partie de ce chapitre est consacré au modèle de représentation de GENOME. L'architecture du modèle dont une première ébauche a été présentée dans le chapitre 3, est complétée en précisant les méthodes de chaque classe ainsi qu'une brève description. Nous avons décrit les processus d'évolution par des automates dans le chapitre 4. Nous présentons plus de détails dans ce chapitre, principalement les classes (via leurs méthodes) mises en jeu pour mener ces processus d'évolution, principalement le croisement. Les présentations sont faites sur la base de la notation d'UML [Muller 97].

Nous terminons enfin par un exemple de Présage auquel peut répondre GENOME, ainsi qu'un bref descriptif des parties implémentées et des résultats.
# 6.2 - L'environnement Présage et GENOME

## 6.2.1. L'infrastructure de Présage

Présage est un logiciel de modélisation et de planification de réseaux de télécommunications, qui consiste à étudier l'évolution de ces réseaux à court, moyen et long termes, à savoir dans un délai pouvant aller de 1 an à 10 ans. Un environnement orienté objet à été développé pour l'implantation de l'infrastructure de Présage [Caminada 92]. Le modèle est basé sur une modélisation hiérarchisée/multi-vues [Oussalah 88] : un réseau peut être considéré suivant ses différentes vues. Par exemple, une vue peut correspondre à une demande en transmission, ou à son implantation physique (en anneaux, en étoile, point-à-point...). Une vue peut être associée à différents niveaux d'abstractions.

Présage s'adresse à deux types d'utilisateurs : le Constructeur d'Applications qui modélise un réseau, et l'Utilisateur Final qui manipule une instance de ce réseau. Cet environnement a été implémenté dans le langage C++. Une de ses principales caractéristiques est la dynamicité des classes. En effet, la dynamicité des classes au niveau du Constructeur d'Applications CA est simulée grâce à l'implantation d'une sur-couche du langage C++ [Puig 97].

Toute classe créée dynamiquement par le CA est représentée par une instance C++, qui lors du passage en mode Utilisateur Final UF, sera transformée en classe C++, grâce à une étape de génération automatique de code C++ :

<figure><img src="image_53.png" /></figure>