<caption>Figure 6-1: Présage: prise en charge de la dynamicité des classes dans C++.</caption>

Ainsi, les classes niveau CA représentent le modèle hiérarchisé/multi-vues de planification de réseaux de télécommunications. Par exemple, la planification de réseaux urbains selon différentes vues (zone, commutations, dimension du réseau, transmission), et pour chaque vue selon plusieurs abstractions (niveaux système, demande de transmission, support physique ...). Ce modèle est instancié pour définir différents types de réseaux urbains.

Ces instances, grâce à la **génération automatique de code C++**, sont représentées par des classes ainsi générées, au niveau UF. Ces classes sont ensuite instanciées pour définir des réseaux urbains. C'est ainsi que les attributs sont réifiés en mode CA et deviennent de vrais attributs contenus dans les classes en mode UF. L'ajout et la modification d'attributs sont simulés. C'est également ainsi que la relation d'héritage entre ces classes dynamiques a été ré-implémentée grâce aux attributs *isa* qui référence la super-classe, et *sub* qui référence les sous-classes.

## 6.2.2. GENOME et les choix d'implémentation

### 6.2.2.1. Positionnement de GENOME par rapport à Présage

Nous considérons GENOME comme étant indépendant. Il peut en effet parfaitement être considéré comme un module indépendant, voire une application indépendante.

Dans le cadre de son intégration dans Présage, nous le considérons comme un module à part, avec des points d'entrée et des points de sortie. Étant un outil de simulation d'évolution, le module de GENOME travaille à part de l'application Présage qui s'exécute dans le cadre de ses activités de planification.

Lorsque le concepteur nécessite de simuler l'évolution au vu de certaines données, il transmet à GENOME comme entrée la base de données ou la partie de la base de données concernée par l'évolution. GENOME donne en retour comme sortie les résultats de la simulation de l'évolution, et donc de changements proposés en termes d'émergence de nouvelles structures conceptuelles. Ces changements sont proposés au concepteur. Lui seul a le pouvoir de décider d'accepter les changements, voire de les ajuster avant de les intégrer définitivement dans la base de Présage :
<figure><img src="image_54.png" /><figcaption>Figure 6-2: Interactions Présage/Genome.</figcaption></figure>

Ce passage entre les deux modèles implique le passage de classes, liens et instances Présage et qui sont nécessaire à GENOME pour mener l'évolution. Ces classes, liens et instances sont donc momentanément décrits en GENOME, le temps de la simulation de l'évolution. La principale information qui doit être dégagée par le concepteur pour transcrire la (portion de) base de données Présage en GENOME est de distinguer la population, donc de cerner le Génotype Fondamental, ainsi que la valuation des schèmes permanents. Les GH et GS se déduisent sans encombre grâce au lien d'héritage.

Une fois les résultats de l'évolution obtenus, validés et/ou corrigés par le concepteur, les données sont à nouveau transmises et sont intégrées à la base Présage dans leur nouvel état.

### 6.2.2.2. Choix d'implémentation de GENOME

La nouvelle politique adoptée par le CNET dans le cadre du développement de nouvelles applications et de l'extension d'applications existantes, est de favoriser le développement en Java. Pour cette raison, GENOME ainsi que les parties développées du prototype sont spécifiés en Java.

Les similitudes de GENOME avec Présage est la réification des différents concepts. Cependant, la différence des langages d'implémentation nécessite de développer une passerelle entre les deux applications pour prendre en compte le passage C++/Java des informations transmises entre Présage et GENOME. Cette partie a fait l'objet de propositions en cours d'études et de validation. Cette étape nécessite le développement d'un noyau permettant un interfaçage automatique entre Présage et GENOME.
Nous présentons dans la section suivante le modèle d'implémentation de GENOME :

## 6.3 - Le modèle d'implémentation de GENOME

### 6.3.1. Le modèle GENOME

Nous reprenons les classes du modèle de GENOME présenté au chapitre 3, et nous détaillons chacune d'entre elles, principalement en termes de méthodes car les principaux attributs ont déjà été présentés, ainsi qu'un bref descriptif.

Certains attributs diffèrent de ceux présentés dans la synoptique du modèle. Il s'agit principalement des trois groupes de gènes. En effet, dans la partie implémentation, nous distinguons les attributs et les méthodes constituants chaque groupe de gènes : GF, GH et GS.

**- Classe Population :**

*public class Population extends Object :* cette classe représente les caractéristiques d'une population.

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

**Attributs**

*NomPopulation* : est de type chaîne de caractères.

*GFatt* : est l'ensemble des références des attributs (instances de la classe **Attributs**) qui constituent les attributs du GF.

*GFmeth* : est l'ensemble des références des méthodes (instances de la classe **Methode**) qui constituent les méthodes du GF.

**Remarque** : un GF d'une population est réellement constitué de *GFatt* et de *GFmeth*.

**Méthodes**

*public Population(String nomPop, Vector attGF, Vector methGF)* : est le constructeur.
public String afficheNom() : méthode qui affiche le nom de la population courante.

protected Vector afficheGF(String nomPopulation) : méthode qui affiche le GF de la population courante. Elle fait appel dans son corps aux méthodes protected afficheGFatt et afficheGFmeth.

protected Vector afficheGFatt(String nomPopulation) : méthode qui affiche les attributs du GF de la population courante.

public Vector afficheGFmeth(String nomPopulation) : méthode qui affiche les méthode du GF de la population courante.

## Classe PatrimoineGenetique :

public class PatrimoineGenetique extends Object : cette classe stocke l'ensemble des références de gènes (attributs et méthodes) constituant le patrimoine génétique d'une population.

### PatrimoineGenetique

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

listeAttributs : Attributs

listeMethodes : Methode

* patrimoineGenetique() : PatrimoineGenetique

* longueurPatrimoine() : int

* miseaJourListeAttributs(nom : Attributs)

* miseaJourlisteMethodes(nom : Methode)

### Attributs :

listeAttributs : c'est l'ensemble des références d'attributs (classe Attributs) constituant le patrimoine génétique de la population associée.

listeMethodes : c'est l'ensemble des références de méthodes (classe Methode) constituant le patrimoine génétique de la population associée.

### Méthodes :

public patrimoineGenetique() : constructeur.

public int longueurPatrimoine() : méthode qui renvoie la taille du patrimoine génétique.

public void miseaJourlisteAttributs(Attributs nom) : méthode qui met à jour le patrimoine génétique avec les nouveaux attributs/méthodes de la classe courante de la population.

public void miseaJourlisteMethode(Methode nom) : méthode qui met à jour le patrimoine génétique avec les nouveaux attributs/méthodes de la classe courante de la population.

## Classe ClasseGtype :

public class ClasseGtype extends Object : c'est la classe qui permet de représenter toute classe sous GENOME. La principale distinction est les trois groupes de gènes.
## ClasseGtype

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

NomClasse : String

GF : Population

GHatt : Attributs

GHmet : Methode

GSatt : Attributs

GSmet : Method

* ClasseGtype(nomClasse : String, GF : Population) : ClasseGtype

* recupGH(attSuperClasse : Attributs, methSuperClasse : Methode) : Vector

* specifGS(attrGS : Attributs, methGS : Methode) : Vector

* afficheGF() : Vector

* afficheGH() : Vector

* afficheGS() : Vector

* afficheGHatt() : Vector

* afficheGHmeth() : Vector

* afficheGSatt() : Vector

* afficheGSmeth() : Vector

## Attributs :

NomClasse : est de type chaîne de caractères et permet de nommer une classe.

GF : est une référence vers une instance de la classe **Population**. De cette sorte, une classe est toujours liée à une population et respecte par conséquent le GF. Cet attribut est transmis à toutes ses sous-classes.

GHatt : représente l'ensemble des attributs constituant le GH de la classe courante.

GHmet : représente l'ensemble des méthodes constituant le GH de la classe courante.

GSatt : représente l'ensemble des attributs constituant le GS de la classe courante.

GHmet : représente l'ensemble des méthodes constituant le GS de la classe courante.

## Méthodes :

public ClasseGtype(String NomClasse, Population : GF) : constructeur.

public Vector recupGH(Attributs : attSuperClasse, Methode : methSuperClasse) : constitue le GH de la classe courante en récupérant le GH et le GS de la super-classe.

public Vector specifGS(Attributs : attSuperClasse, Methode : methSuperClasse) : permet de spécifier le GS de la classe courante.

public afficheGF() : fait appel à la méthode afficheGF de la classe **Population**.

public afficheGH() : affiche le GH de la classe en cours en faisant appel aux méthodes afficheGHatt et afficheGHmeth.

public afficheGS() : affiche le GS de la classe en cours en faisant appel aux méthodes afficheGSatt et afficheGSmeth.

## - Classe Attributs :

public class Attributs extends Object : cette classe Attributs permet de réifier les attributs.
### Attributs

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

nom : String

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

type : String

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

statut : boolean = F

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

► Attributs(nomAtt : String, typeAtt : String) : Attributs

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

◄ modifieAttributs()

### Attributs :

* nom : de type String qui définit le nom de l'attribut.

* type : détermine le type de l'attribut. Pour l'instant, nous le considérons comme une chaîne de caractères.

* statut : qui est de type booléen pour exprimer si l'attribut est permanent ou transitoire.

* valeur : sous forme de chaîne de caractères pour contenir la valeur de l'attribut.

### Méthodes :

* public Attributs (String nomAtt, String typeAtt) : le constructeur, qui met à défaut le statut à vrai pour exprimer qu'il est permanent, et la valeur à chaîne nulle.

* public modifieAttributs() : pour modifier un attribut. Cette méthode est redéfinie et surchargée de manière à gérer toutes les modifications possibles.

### - Classe Methode :

* public class Methode extends Object : cette classe Methode permet de réifier les méthodes.

#### Methode

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

nom : String

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

signature : Vector

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

corps : String

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

◄ Methode(nomMet : String, param : Vector, corps : String) : Methode

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

◄ modifieMethode() : Methode

### Attributs :

* nom : le nom de la méthode sous forme de chaîne de caractères.

* signature : donne la liste de paramètres.

* corps : chaîne de caractères.

### Méthodes :

* public Methode(String nomMet, Vector param, String corps) : le constructeur qui permet de créer une méthode en spécifiant son nom, la liste de ses paramètres et le corps considéré comme une chaîne de caractères.

* public modifieMethode() : pour modifier une méthode. Cette méthode est redéfinie et surchargée de manière à gérer toutes les modifications possibles.
## - Classe Scheme :

public class Scheme extends Object : cette classe représente tout schème et permet donc de créer le schème courant et le stocke dans un vecteur.

### Scheme

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

attribut : Attributs

valeurGene : Character = #

* miseajourSchemeCourant(valeur : String) : Vector

* creationSchemeCourant(nom : String, vecteur : Vector) : Vector

* miseajourSchemeHerite(schemePere : Vector, nouveauScheme : Vector) : Vector

* afficheValeurSchemeCourant()

## Attributs :

attribut : est un ensemble d'attributs que référencent le schème. Il référence des instances de la classe **Attributs**.

valeurGene : est de type caractère. Il représente la valeur associé à l'attribut référencé. Il est initialisé par défaut à #. Il peut prendre également la valeur 0 ou 1.

## Méthodes :

Scheme() : constructeur

public void afficheValeurSchemeCourant() : affiche le schème de la classe courante

public Vector creationSchemeCourant(String nom, Vector vecteur) : méthode qui crée le vecteur contenant le schème courant

Vector miseajourSchemeCourant(String valeur) : méthode qui crée le schème de la classe courante

public Vector miseajourSchemeHerite(Vector schemePere, Vector nouveauScheme) : méthode qui met à jour le schème de la classe courante en prenant en compte l'héritage.

## - Classe InstanceClasseGtype :

public class PatrimoineGenetique extends Object :

### Méthodes :

public void afficheSaisie(Vector l) : méthode qui affiche l'interface de saisie d'une nouvelle classe et qui stocke la nouvelle classe avec ses valeurs dans le vecteur des classes. Elle est représentée par une instance de ClasseGtype.

## - Classe evolueVers :

public class PatrimoineGenetique extends Object : c'est la classe qui représente un lien d'évolution.
## evolueVers

attributsPerdus : Attributs

methodesPerdues : Méthode

attributsAcquis : Attributs

methodeAcquis : Méthode

## 6.3.2. Les processus d'évolution

Nous citons dans cette section quelques classes notables de l'application ainsi que les principales parties de l'application des processus d'évolution :

### - Class MiseaJourScheme :

public class MiseaJourScheme extends Object : cette classe stocke le schème courant dans le vecteur des schèmes et met à jour le schème des autres classes. Elle définit entre autres les méthodes suivantes :

public void miseaJourSchemeToutesAutresClasses(Vector v) : méthode qui met à jour tous les autres schèmes.

public void StockageSchemeCourant(Vector v, String pere) : méthode qui stocke le schème courant dans le vecteur des schèmes

### - Class Genome :

public class Genome extends Object implements ActionListener : cette classe instancie un objet Genome1. Elle permet de gérer l'interface graphique et définit la méthode afficheSaisie(Vector) qui affiche l'interface de saisie d'une nouvelle classe et qui stocke la nouvelle classe avec ses valeurs dans le vecteur des classes.

### - Class AfficheClasse :

public class AfficheClasse extends Object implements ActionListener, WindowListener : cette classe crée l'IHM de visualisation des classes qui affiche tous les attributs et méthodes d'une classe.

### - Class AfficheMenu :

public class AfficheMenu extends Object implements ActionListener : cette classe est l'IHM dans laquelle on peut choisir de créer une nouvelle classe et de visualiser n'importe quelle classe déjà créée. Elle détient le main (point de lancement).
- **Class AfficheVisu :**

public class AfficheVisu extends Object implementsActionListener : cette classe affiche la liste des classes déjà créées.

**Méthodes intéressantes :**

public void creeListedesClasses (Vector v) : méthode qui crée la liste des classes à afficher dans cette interface.

public void methodeAfficheVisu() : méthode qui affiche la liste des classes déjà créées.

- **Les processus d'évolution** : nous présentons non pas le détail du programme, mais uniquement l'intitulé des différentes étapes :

- préparation du tableau de population en le mettant à zéro

- saisie ou extraction du schème temporaire

- Recherche des parents et chargement de la population via les schèmes permanents

**corps du programme**

- affichage des parents

- génération de la population

- fin de la génération

**Croisement**

- choix des géniteurs dans la population

- pondération des VA

- /* création des enfants */

for (i=0; i<longueur_chem; i++) {
    valeatoir= Math.random();

    if (valeatoir > va_ponde) {
        e1[0][i] = tabloPopulation[p1][i];
        e2[0][i] = tabloPopulation[p2][i];
    }

    else {
        e1[0][i] = tabloPopulation[p2][i];
        e2[0][i] = tabloPopulation[p1][i];
    }

    e1[1][i] = -1;
    e2[1][i] = -1;
}

** étude des contraintes de blocs**

- mise à jour des schèmes des enfants en appliquant les contraintes de blocs de gènes

- entrée des enfants i dans la population à la place des parents

- calcul des va de chaque enfant i

- fin de calcul des va des ei

- enregistrement de va max

- affichage de population

- affichage des va_max
### 6.3.3. Un exemple de Présage

Nous reprenons l'exemple de Présage d'un réseau urbain, représenté par une instance, et les diverses évolutions qu'il peut connaître. Cet exemple a été introduit dans le chapitre 1.

L'état initial de l'instance représente un réseau de télécommunications qui a été créé en utilisant les éléments contenus dans la classe **Cl-Réseau Urbain.2**. Cette instance représente les voies de communications d'un réseau urbain. Avec cette représentation, le concepteur réalise rapidement qu'il obtient une saturation au niveau de la demande pour les deux anneaux de type 'STM1' (à droite de la Figure 1-2). Il faut donc remédier à ce problème. Une solution serait de remplacer les deux anneaux de type 'STM1' par un anneau de type 'STM4' qui lui permet de faire passer quatre fois plus d'informations qu'un anneau de type 'STM1'. Voici comment le concepteur voudrait pouvoir manipuler les réseaux existants. Mais en même temps, il faut également tenir compte de la nature expérimentale de la construction du modèle, comme c'est le cas pour la plupart des modèles. Avec GENOME, le concepteur est en mesure d'exprimer les différents nouveaux besoins :

Nous remarquons dans cet exemple que le concepteur apporte les changements suivants à la structure, aux composants et aux types de composants du graphe du réseau urbain modélisé :

- les arêtes existantes rstm1.4 et rstm1.3 du type existant d'arêtes RSTM1 ont été détruites ;

- de nouvelles arêtes, système.1 et système.2, du type existant d'arêtes système ont été ajoutées ;

- une nouvelle arête, rstm4.1, d'un nouveau type d'arêtes RSTM4 ont été ajoutés (le type et l'arête ont été ajoutés) ;

- les nœuds existantsstm1.6 àstm1.8 du type de nœuds existant STM1 ont été remplacées ;

- de nouveaux nœuds,stm4.1 àstm4.4, d'un nouveau type de nœuds STM4 ont été ajoutés.
<figure><img src="image_69.png" /><figcaption>Figure 6-3: un exemple d'une instance, donc d'un réseau de télécommunications, et les changements que veut y apporter le concepteur.</figcaption></figure>

Le concepteur a ainsi exprimé ses besoins d'évolution sur une instance existante, dans le cadre de sa tâche de planification de réseaux de télécommunications. Le processus d'évolution permet l'émergence d'une nouvelle structure conceptuelle représentée par la classe CI-Réseau Urbain.3 :
<figure><img src="image_70.png" /><figcaption>Figure 6-4: résultat de l'évolution.</figcaption></figure>

Sur cet exemple, nous mettons en évidence le GF caractérisant tous les réseaux urbains, ainsi que la nouvelle classe émergente, définie au travers du GF, de son GH et du GS qu'elle introduit.

## 6.4 - Descriptif et état d'avancement

Les deux principales parties de GENOME ont été développées : l'aspect des processus d'évolution a été développé avec le JDK 1.0 et l'aspect de l'implémentation du méta-modèle a été développé avec le JDK 1.1.5 sur Unix. L'implémentation du modèle GENOME, a été menée dans le cadre de l'extension de Présage, et dans le cadre de projets avec des étudiants. Dans un souci d'uniformité, elle doit prendre en compte les deux niveaux CA et UF, car elle doit offrir de nouvelles fonctionnalités pour Présage, dans le cadre de la manipulation et l'évolution des réseaux de télécommunications.

De plus, le langage Java ne présentant pas de méta-niveau, le modèle est donc implémenté selon le modèle de Présage, à savoir avec des classes (représentant en fait le niveau CA) dont les instances seront par la suite transformées pour définir des classes (représentant en fait le niveau UF) qui seront à leur tour instanciées de manière terminale.
Nous nous sommes attelés à la première partie. La seconde devrait se poursuivre dans le cadre de l'extension de Présage avec GENOME.

L'implémentation s'est faite chronologiquement en deux phases :

1- Le processus d'émergence globale par croisement ;

2- Le modèle de GENOME.

Les raisons de ces choix de développement sont explicitées ci-après :

## 6.4.1. Processus d'émergence globale par croisement

En effet, la première partie à avoir été développée a été celle de l'émergence globale par croisement. Il nous était effectivement nécessaire de développer le croisement à des fins de validation et de vérification du croisement tel que nous l'avions défini.

Dans le cadre de la validation du croisement, les caractéristiques qui nous ont intéressées sont résumées comme suit :

- La manipulation directe d'un codage des paramètres, et non des paramètres eux-mêmes : le codage des paramètres étant le schème et les paramètres étant les attributs ;

- L'exploration au moyen d'une population de solutions, et non d'une solution unique : la population de solutions étant la population de classes, ou plus précisément la population des schèmes permanents des classes partiellement adaptées ; la solution unique étant le schème temporaire, donc l'abstraction véhiculée par l'instance ayant évolué ;

- L'exploration 'aveugle' à partir uniquement des données de la situation : l'exploration 'aveugle' est un qualificatif utilisé par les Algorithmes Génétiques. Il revient pour nous à l'exploration de l'ensemble de la population de solutions et le croisement effectué en introduisant de l'aléa dans le croisement et donc dans la transmission des gènes manipulés. Les données de la situation sont : les schèmes permanents, les contraintes de blocs de GH et de GS de ces schèmes à respecter, les invariants exprimés par le concepteur dans le modèle ainsi que ceux, éventuellement, exprimés directement sur les instances ayant évolué.

- L'utilisation pour l'optimisation de la solution finale, d'opérateurs stochastiques : et non de règles purement déterministes.

### 6.4.1.1. Validation et amélioration du croisement

L'implémentation du croisement nous a été particulièrement utile. Grâce à elle, des améliorations importantes ont été apportées au croisement, principalement l'uniformisation de deux schèmes avant le croisement, l'utilisation de Valeurs d'Adaptation pondérées Vap et l'application des contraintes de blocs de gènes.

Ce dernier point a été initialement introduit uniquement pour des raisons sémantiques. Lors de son implémentation, nous avons réalisé que les résultats du croisement s'étaient
nettement améliorés. Avant cela, les résultats obtenus du croisement, donc les Va, tendaient à s'améliorer, mais restaient généralement en deçà de la solution idéale, c'est-à-dire celle ayant une Va à 1. Sur un nombre d'itérations prédéfini (i=100), les meilleures des résultats obtenus variaient autour d'une $Va = 0.6 \pm\{0.1, 0.2\}$.

L'introduction de la contrainte de blocs a permis de converger les résultats plus rapidement (une amélioration de l'ordre de plus de 25%) et la Va idéale était plus souvent atteinte (Va=1), sans pour autant diminuer de la diversité des schèmes émergents obtenus.

Le principe d'exécution est d'introduire un schème temporaire et de le comparer avec la population des 20 schèmes. Ces jeux d'essais sont appliqués plusieurs fois sur cette population fixe de 20 schèmes différents, une population fixe de 20 individus, une longueur de schème fixée arbitrairement à 8 gènes, et le GF codé sur un gène (il n'intervient pas dans le croisement). Les résultats constatés montrent l'apparition d'individus dans la population : c'est l'émergence d'une solution non prévue.

La constatation finale que nous avons faite de l'évolution des Va maximales est représentée dans le graphe suivant :

<figure><img src="image_71.png" /><figcaption>Figure 6-5: Évolution de la Va Max au cours des itérations du croisement.</figcaption></figure>

La Va maximale (la plus grande Va de chaque génération de croisement) évolue au cours des générations du croisement. Comme l'indique le graphique, lors des premières itérations, la Va maximale baisse sensiblement, avant de remonter asymptotiquement, en rattrapant d'abord le niveau initial (donc les Va initiales, celles des schèmes permanents) puis de le dépasser et se rapprocher de la valeur maximale 1, atteinte après un nombre d'itérations du croisement. Le nombre d'itérations avant la convergence de la Va vers 1 varie selon les schèmes permanents dont on dispose.
Cette dégradation des performances avant une amélioration est connue dans le cadre des Algorithmes Génétiques.

### 6.4.1.2. Deuxième étape dans l'implémentation du croisement

Les limites de cette première étape de l'implémentation du croisement était le codage figé des schèmes permanents (nous considérions que nous travaillions sur une même population, d'où les schèmes permanents figés). Mais cette étape était nécessaire pour valider et même améliorer le croisement.

La seconde étape consiste à rendre le processus plus générique en le rendant modulaire et paramétrable, le rendre donc plus générique. Il est donc devenu nécessaire de :

- travailler sur les schèmes permanents de population de classes, donc de schèmes de longueur variables (d'où l'introduction de l'uniformisation de schèmes deux à deux avant de les comparer, ainsi que des Vap);

- manipuler pour ajout, modification, destruction de classes, d'instances et d'attributs;

- extraire des schèmes temporaires des instances ayant évolué.

Cela revient à l'implémentation des deux phases d'extraction et d'exploration.

Des améliorations ont été également nécessaires à apporter au croisement :

- le croisement doit pouvoir être déclenché à la demande du concepteur, soit après la modification d'une instance, soit après avoir modifié plusieurs instances;

- une autre option est de faire un croisement 'à la carte', c'est-à-dire uniquement sur deux schèmes, pour des besoins de simulations ponctuelles et d'évaluation.

Aussi, le croisement tel qu'obtenu en premier a été intégré comme un noyau dans un autre module qui permet de travailler via une interface graphique sur la simulation d'un modèle de classes avec des attributs mais aussi la sélection d'une instance et de provoquer son évolution structurelle de manière dynamique. Il s'ensuit une extraction des schèmes temporaires et de l'accomplissement du croisement.

Ainsi, une fois que le cœur du modèle a été vérifié et validé, puis complété avec les deux premières phases, la seconde étape de l'implémentation a été celle des concepts du modèle, tel qu'il est présenté en section 6.3 - .

### 6.4.2. État d'avancement du prototype

L'avancement et les manques de l'implémentation de GENOME sont abordés dans cette section, tout en précisant les extensions nécessaires à apporter à court terme :
### 6.4.2.1. Le modèle de GENOME

Les concepts du modèle de GENOME sont spécifiés : le concept de Classe-Gtype, la distinction entre les trois différents génotypes ainsi que la transmission du GF et du GH entre les classes d'une population, la simulation du lien d'héritage ainsi que la spécification du schème permanent lors de la définition d'une classe et la possibilité de définir les liens d'évolution.

Cependant, il n'est pas encore possible de redéfinir le GH et l'interface graphique ne permet pas encore de représenter tout le modèle (tel que le schème qui n'est pas encore manipulé graphiquement mais ses états apparaissent sur la ligne de commande uniquement). Il n'y a pas encore la transformation du modèle des instances en classes pour qu'elles puissent être à leur tout instanciées.

Nous jugeons que plusieurs aspects doivent être étendus :

- Approfondir la simulation du lien d'héritage en permettant la redéfinition des gènes hérités ainsi que la modification du schème permanent en conséquence ;

- Spécifier le lien d'évolution (il ne pourra être utilisé qu'en développant la jonction entre le modèle statique et le modèle dynamique) ;

- Simuler l'instanciation d'une classe et permettre la persistance des données (classes et instances), ce qui permettrait de récupérer une base de données existante sur laquelle peuvent être simulées des évolutions. Cela doit se poursuivre dans le cadre de Présage ;

### 6.4.2.2. Les Processus d'Évolution de GENOME

Dans le cadre des processus d'évolution, l'effort s'est porté essentiellement sur le processus d'émergence par croisement. De plus, le croisement peut aussi bien se faire sur une instance ayant évolué par rapport à des classes existantes, qu'entre deux instances au choix pour un besoin de simulation. Nous avons également simulé la phase d'extraction de schèmes temporaires sur des exemples simples.

Cependant, la phase d'extraction doit être plus générique. Les suites de la phase d'exploitation, après avoir mené le croisement, n'a pas encore été développée, principalement l'analyse et l'insertion d'abstractions émergentes dans le modèle de classes, la gestion des différents impacts, ainsi que le modèle de métriques.

Pour répondre à ces manques, il faut développer la phase d'exploitation, principalement :

- La mesure et l'analyse de l'émergence ;

- Le modèle de métriques ;

- L'insertion des abstractions émergentes ;

- La gestion des impacts de cette insertion ;

- Les spécification du lien d'évolution.
### 6.4.2.3. Complexité du croisement

Étant donné que le croisement de GENOME se base sur le croisement des Algorithmes Génétiques, ses résultats et ses performances sont semblables à ces derniers. Il est connu dans le domaine des Algorithmes Génétiques, que la convergence du croisement ne peut être prouvée de manière théorique, et que les résultats dépendent plutôt des cas concrets de leur utilisation. Dans le cadre de nos travaux, et principalement dans le cadre de la simulation de l'évolution par émergence globale, nous avons défini au niveau du croisement trois critères d'arrêts exclusifs :

- lorsqu'au moins un schème émergent (Va=1) apparaît ;

- lorsque le concepteur décide à l'avance d'un certain nombre d'itérations pour le croisement d'une population ;

- lorsque les résultats du croisement se détériorent de manière très sensible.

De plus, au vu des différents paramètres que nous utilisons lors du croisement, principalement la contrainte de blocs de gènes, les résultats des tests du croisement permettaient toujours d'obtenir une bonne convergence du croisement pour une même population.

## 6.5 - Conclusion

Ce chapitre met en évidence d'une part l'infrastructure de Présage, dans le cadre duquel le modèle GENOME doit s'intégrer, et d'autre part, l'implémentation du modèle de GENOME et de ses processus d'évolution. En l'état actuel, les deux parties sont indépendantes. La jonction doit permettre de spécifier le modèle de manière complète et d'assurer une cohérence respective :

- Les processus d'évolution se baseront alors sur le modèle de classes et d'instances pour s'exécuter ;

- Les résultats du processus de développement et d'émergence seront intégrés et répercutés sur le modèle de classes.
<figure><img src="image_72.png" /></figure>
CONCLUSION :
CONTRIBUTIONS ET
PERSPECTIVES

<figure><img src="image_73.png" /></figure>
## 7.1 - Contributions de nos travaux

La problématique ayant motivé cette thèse s'inscrit dans le cadre plus général qu'est l'évolution d'objets [Oussalah& 99], [Dony& 97], [Nguyen& 89], [Lerner& 90]... Nos travaux se sont intéressés à l'évolution d'objets sous un angle particulier, celui de l'évolution initiée à partir de l'évolution dynamique de la structure d'instances avec impacts sur les classes, par modification de ces dernières au sein de leur hiérarchie. Ce dernier point constitue le point commun avec les stratégies d'évolution d'objets par modification de classes, telles que leur *réorganisation* [Casais 91], leur *classification* [Capponi 94], leur *catégorisation* [Napoli 92], ou leur *correction* [Banerjee& 87].

Comme nous l'avions préalablement souligné dans l'état de l'art (Chapitre 2), la plupart des stratégies d'évolution s'intéresse à l'évolution de classes et de schémas de classes. Notre approche est complémentaire. A notre connaissance, peu de travaux ([Li& 94]) ont traité l'évolution d'objets sous cet angle.

En effet, ces principales stratégies (présentées en chapitre 2) sont nécessaires et utiles pour mener à bien l'évolution à partir des classes, chacune selon sa politique et donc son adéquation à la situation. Mais elles ne peuvent être utiles que s'il est possible au concepteur de définir a priori l'évolution. Or, au vu de l'expérience acquise, suite à une maturation et un recul certains, le besoin de pouvoir manipuler, dans une certaine mesure les spécifications existantes à partir d'instances, se fait pesamment ressentir. Ainsi, un concepteur ayant la charge d'applications complexes et volumineuses rencontre souvent ce type de problèmes.

Nous avons proposé GENOME, un modèle objet pour la simulation de l'évolution d'objets à partir de l'évolution dynamique de la structure d'instances. Ce modèle trouve toute son utilité sur des applications objets complexes et volumineuses. Nous l'avons proposé comme un outil d'aide à la maintenance et à l'évolution, pour un utilisateur particulier : le concepteur ayant la charge de ce type d'applications.
Un concepteur rencontre, dans l'accomplissement de sa tâche, de nouveaux besoins qui sont partiellement ou mal spécifiés, tout au long du cycle de vie des applications. Or, dans le cadre d'applications complexes et volumineuses (Réseaux de télécommunications [Caminada 92], CAO [Rieu& 92]...), il est parfois très difficile de cerner à quel endroit de l'application il est nécessaire d'apporter des modifications au niveau des spécifications conceptuelles existantes. De plus, ces besoins apparaissent généralement lors du déroulement des applications, donc de la manipulation des instances. Il nous est apparu fort utile de pouvoir manipuler ces mêmes instances dans leur structure pour refléter l'évolution et amorcer les impacts sur le niveau des classes.

Il n'a nullement été question dans le cadre de nos travaux d'accorder aux instances les mêmes prérogatives ni la même importance qu'aux classes. Nous nous sommes bien situés dans un cadre de modélisation et d'évolution d'objets, et nous considérons que dans un état stable, la dualité classe/instance, telle que définie dans l'approche objet [Masini 89], est et reste respectée dans un modèle. Nous considérons toutefois qu'au vu de certains de ses aspects rigides, la modélisation objet est contraignante dans certaines situations. Nous avons pour cela pensé que l'évolution d'objets gagnerait en richesse et en intérêt en permettant, dans ces situations, d'amorcer et de simuler l'évolution et ses conséquences par le biais de l'évolution dynamique de la structure d'instances.

Nous pouvons situer la contribution de nos travaux sur deux plans :

- l'état de l'art ;

- une approche pour l'évolution d'objets basée sur les instances.

### 7.1.1. D'un point de vue de l'État de l'Art

Nous avons proposé une classification de l'évolution d'objets basée sur trois *facettes* :

1. L'Objet de l'évolution : l'évolution peut porter sur un *produit* ou un *processus*.

2. Le *Type de l'évolution* : lorsque les besoins d'évolution sont pris en compte lors de l'analyse et spécifiés lors de la conception, l'évolution est dite *préventive*. Lorsque de nouveaux besoins apparaissent ou qu'ils aient été mal ou partiellement définis, l'évolution est dite *curative*.

3. Le *Processus d'évolution* : nous distinguons deux types de processus d'évolution : le *développement* et l'émergence. Le premier concerne l'évolution des classes et leurs impacts sur les sous-classes et les instances correspondantes. Le second concerne l'évolution d'instances avec des impacts sur les classes.

Nous avons mis en évidence que toute stratégie d'évolution peut être positionnée dans cette représentation triptyque en répondant pour chacune d'entre elles aux questions suivantes :

1. Quel est l'objet de sa politique d'évolution : *produit* ou *processus* ?
2- Quel est le type d'évolution qu'elle propose : *curative* ou *préventive* ?

3- Quel type de processus d'évolution permet-elle : *développement* ou *émergence* ?

Nous avons souligné que cette classification offre un double avantage :

- celui de situer une stratégie d'évolution par rapport à l'évolution et non par rapport à une stratégie donnée, ce qui permet une comparaison uniforme ;

- celui de situer les aspects de l'évolution d'objets qui ont largement été traités, peu traités ou jamais traités.

## 7.1.2. D'un point de vue de l'Évolution d'objets

Notre approche, comme nous l'avons précédemment rappelé, se base sur l'évolution initiée à partir de celles d'instances existantes.

Comme nous considérons que les instances sont des entités détenant leur propre connaissance (via leurs classes), elles peuvent faire évoluer leur connaissance, au vu des perturbations émanant de l'environnement changeant et instable dans lequel elles évoluent. Afin de prendre en compte ces informations nouvellement présentes dans certaines instances, et afin d'assurer une évolution harmonieuse et sans rupture majeure, tout en veillant à tirer profit au maximum des informations préalablement existantes, nous avons défini les processus d'évolution et les concepts du modèle GENOME. En amont, nous avons situé notre contexte et nos hypothèses de travail.

Nous nous sommes inspirés de quelques principes, notions et concepts des travaux de la Vie Artificielle et des Algorithmes Génétiques, car les individus qu'ils définissent peuvent s'adapter et adapter leur propre connaissance dans un environnement instable. Les nouveaux individus qui apparaissent sont beaucoup mieux adaptés que leurs prédécesseurs.

Le principal nouvel aspect que nous introduisons dans nos travaux est le croisement d'entités (qu'elles soient instances ou classes) dans leurs spécifications. Il permet l'interchangement de spécifications, en introduisant de l'aléa mais tout en garantissant un minimum de cohérence (la contrainte des blocs). Le but est de dégager de nouvelles structures conceptuelles, auparavant inexistantes, mieux adaptées aux nouveaux besoins.

### 7.1.2.1. Le principe de l'évolution d'objets sous GENOME

Suite à l'évolution de la structure d'une instance, nous considérons que tout processus d'évolution s'exécute en trois phases : une phase d'extraction, une phase d'exploration, et enfin une phase d'exploitation. Nous rappelons le principe de chaque phase :

- **Phase d'extraction** : elle consiste en la détection de l'évolution de l'objet et l'extraction de sa constitution, que nous qualifions de son code génétique.
- **Phase d'exploration** : elle consiste à explorer l'ensemble des classes du modèle par comparaison du code génétique de l'instance ayant évolué et celui de chaque classe. L'objectif est de repérer les classes qui détiennent, ne serait ce que partiellement, les caractéristiques présentes dans l'objet, après que celui-ci aura évolué.

- **Phase d'exploitation** : elle permet l'aboutissement de l'évolution en gérant les différents impacts par un développement ou une émergence :

- *Processus de développement* : ils représentent les impacts d'évolution des classes sur les instances.

- *Processus d'émergence locale et d'émergence globale* : ils représentent les impacts d'évolution d'objets vers les classes. Ils concernent toute émergence d'une nouvelle information conceptuelle à partir d'instances. Il y a deux issues possibles à cette évolution :

- *Émergence locale* : elle concerne l'émergence de nouvelles informations au sein de classe(s) existante(s). Le code génétique de l'objet a évolué et peut faire évoluer celui de sa classe ou d'une classe sémantiquement voisine.

- *Émergence globale* : elle concerne l'émergence d'une nouvelle structure conceptuelle (donc de classe(s)) soit par projection directe au sein de l'objet ayant évolué, soit par croisement d'entités existantes.

### 7.1.2.2. Le principe de la modélisation sous GENOME

Nous avons défini les concepts de GENOME pour modéliser les classes et les instances ainsi que leurs caractéristiques pour pouvoir mener à bien les processus d'évolution, et principalement l'émergence. Nous avons notamment mis en évidence les notions de :

- *Population* : est l'ensemble des classes qui définissent les différentes abstractions d'une même entité de la situation réelle modélisée ;

- *Génotype Fondamental* : est cet ensemble particuliers d'attributs et de méthodes qui représente le noyau commun et indivisible à toutes les classes formant une population ;

- *Le Génotype Hérité et le Génotype Spécifique* : représentent respectivement les caractéristiques héritées de la super-classe et les caractéristiques propres à la classe ;

- *Le schème* : qu'il soit *permanent* (associé à une classe) ou *temporaire* (associé à une instance), le schème est cette entité exprimé de manière très précise et pour ainsi dire binaire. Il représente le code génétique d'une entité manipulé durant les étapes de tout processus d'évolution.

Nous abordons en premier lieu dans la section suivante une réflexion générale sur la problématique de l'évolution d'objets, avant de poursuivre avec les limites et perspectives de notre modèle.
## 7.2 - Limites et Perspectives

Comme nous l'avons cité, chaque stratégie d'évolution est bien adaptée pour mener à
bien l'évolution dans un contexte et pour un besoin précis, mais chacune est assez
souvent moins efficace en dehors de ce contexte. Cependant, la plupart de ces
stratégies sont capables de faire face à des besoins connus et les intègrent durant les
phases d'analyse et de conception, le tout en accord avec la politique d'évolution de la
stratégie adoptée. Nous pensons que dans le cadre de la problématique générale de
l'évolution d'objets, il est avant tout nécessaire d'élaborer des méthodologies pour
gérer l'évolution principalement en :

- Combinant des approches d'évolution existantes ;

- S'appuyant sur des méta-modèles d'évolution ;

- Utilisant des techniques pour contrôler et mener à bien l'évolution ;

- Permettant, finalement, l'évolution d'objets durant le cycle de vie. Cela peut être assuré en prenant en compte les nouveaux besoins lorsqu'ils apparaissent sans provoquer de ruptures préjudiciables ni de perturbations notables.

Nous présentons les limites et perspectives par chapitre du manuscrit. Ensuite, nous
les présentons par ordre de priorité jugé le plus approprié pour la suite des travaux :

### 6.5.1. Limites et perspectives par chapitre

- **Chapitre 3 : l'état de l'art** : nous avons défini dans ce chapitre une classification de l'évolution d'objets basée sur ses trois facettes. Nous avons ensuite étudié les principales stratégies d'évolution basées sur la modification de classes et de schémas de classes. Cette étude nous a permis de distinguer une taxonomie d'opérations d'évolution en opérations de base et opérations avancées. Ces dernières utilisent les premières au vu de la politique d'évolution adoptée. Nous pensons que cette étude gagnerait à :

- d'une part, être étendue aux autres facettes,

- et d'autre part d'établir des liens entre les différents éléments ainsi énumérés de chacune de ces facettes.

Ainsi, non seulement l'évolution peut être définie en situant quelle partie de chacune
des facettes est concernée, mais également quel élément de chaque facette peut être
relié à quel autre élément de chacune des deux autres facettes. Nous pourrions alors
définir des triplets pour définir pleinement toutes les phases d'évolution. Ainsi, la
connaissance d'un élément peut mener à la connaissance des autres éléments concernés
via justement ce triplet qui les réunis. Nous pensons qu'une telle démarche peut largement contribuer à l'analyse et la conception de l'évolution ainsi qu'à sa maîtrise et sa maintenance.

– **Chapitre 4 : les concepts** : nous avons présenté les concepts du modèle GENOME. Nous les avons illustrés par un exemple d'une population de classes. Nous avons manipulé, à titre d'exemple, quelques-unes unes des instances. GENOME est défini pour faire face à l'émergence de structures conceptuelles suite à l'évolution d'instances simples ... vers d'autres instances simples. Nous estimons utile d'étendre le modèle de manière à prendre en compte des **objets composites** et des **objets complexes**. Un cas intéressant peut en effet survenir : celui de l'évolution d'une instance simple en une **instance composite** ou **complexe**. Actuellement, notre modèle ne peut pas répondre à une telle situation. En effet, une telle instance est constituée d'instances reliées entre elles par des liens. Ces instances peuvent ne pas appartenir à la même population. Nous aurions alors une instance composée d'instances de plusieurs populations, donc invoquant plusieurs Génotypes Fondamentaux. Ainsi, le processus d'évolution se trouvera dans une situation embarrassante puisqu'il ne détectera aucune population pleinement adaptée avec le (les ?) GF de l'instance.

Pour cela, nous estimons qu'il est intéressant et utile d'étendre les trois phases d'évolution de manière à intégrer et répondre à l'évolution d'objets composites et complexes. Nous devons pour cela intégrer les relations sémantiques dans notre modèle et de prévoir une gestion dynamique de ces relations. Nous pourrions pour cela utiliser des travaux déjà existants, tels ceux présentés dans [Rashid& 99] qui s'intéressent à l'évolution dynamique des relations dans le cadre d'applications de BDOO volumineuses.

Comme conséquence, si nous pouvons exprimer un lien de référence dans les spécifications d'une classe, nous considérons qu'il est nécessaire d'étendre le concept de schème en distinguant dans sa structure les attributs simples des attributs composites et complexes. Nous avons déjà abordé cette éventualité dans [Tamzalit& 98a] : nous avons proposé, dans le cadre d'émergence globale d'objets complexes, d'appliquer un *filtrage*. Un attribut composé revient à exprimer un lien entre l'objet ayant évolué et d'autres objets. Nous considérons les trois grandes catégories de liens que sont l'héritage, la composition et l'association.

<figure><img src="image_74.png" /></figure>
<caption>Figure 6-6 : Composition et association entre objets</caption>

Un autre aspect nous semble intéressant : celui de pouvoir définir des sous-populations au sein d'une même population. Si un concepteur doit modéliser une situation très complexe, il peut avoir besoin d'organiser les classes et les hiérarchies de classes en populations et sous-populations. Cela revient essentiellement à la manière de définir et de considérer les GF ainsi que les liens entre les GF de sous-populations entre elles et avec la population 'mère'.

Un autre aspect nous paraît également très prometteur : celui de la spécification de méthodes et l'extension plus marquée du croisement sur les méthodes. A terme, la simulation de l'évolution pourra, selon le choix et les besoins, être amorcée sur l'évolution de spécifications de méthodes ou d'attributs, voire une combinaison des deux. Cet aspect pourra s'appuyer sur la proposition d'extension de la taxonomie des facettes de l'évolution précitée. Nous considérons également que cette extension pour prendre en charge les méthodes au même titre que les attributs est un bon point d'ouverture vers les travaux en Génie Logiciel, principalement ceux de la rétro-ingenierie.

## - Chapitre 5 : les processus d'évolution

Quelques pistes nous semblent intéressant pour dépasser les limites des processus d'évolution tels que nous les avons définis et assurer leur amélioration et leur performances :

- Pour l'instant nous avons présenté les processus d'évolution comme étant déclenchés dès qu'une instance évolue dans sa structure. En terme d'ouverture, l'idée serait de pouvoir établir un modèle de déclenchement des processus d'évolution : des règles à respecter, des priorités qui s'imposent, des quotas, de l'importance ou non des changements, du nombre d'instances modifiées, des états dans lesquels le modèle ne doit pas être modifié, des états où il pourra être modifié... Nous pourrions ainsi en partie automatiser le choix du moment propice au déclenchement de l'évolution. Pour l'instant, étant dans un cadre de simulation d'évolution, c'est le concepteur qui déclenche le processus une fois qu'il a exprimé les changements sur les instances.

- Nous proposons également d'assainir le modèle en l'optimisant dès qu'un certain nombre de changements sont effectués. On pourrait alors utiliser les techniques existantes pour l'optimisation et la factorisation des hiérarchies de classes ([Casais 91], [Napoli 92]...).

- Dans le cadre de l'utilisation du développement (soit directement, soit indirectement pour gérer les impacts de l'émergence), il serait intéressant d'étendre la possibilité d'utiliser n'importe quelle stratégie d'évolution et non pas nous intéresser principalement à celles qui font de l'évolution par modification de classes. Nous proposons d'étendre également aux stratégies d'évolution par dérivation et par versionnement. Ainsi, lorsque le
concepteur paramètre l'outil de simulation sur son application, il pourra
entre autres choisir quelle stratégie il voudrait voir appliquer dans la phase
de développement pour gérer les impacts de l'émergence. Si par exemple il
veut garder un historique, il pourra choisir le versionnement. Ce choix de
stratégies à appliquer pour la gestion des impacts de l'émergence dans le
cadre du développement constitue un des invariants que pourra imposer le
concepteur. Il pourrait donc influencer le choix des métriques et le choix des
résultats de l'émergence. Il permet également de garder éventuellement des
stratégies d'évolution déjà existantes dans son environnement et/ou
auxquelles il serait habitué.

Nous présentons également quelques perspectives pour deux aspects particuliers du
modèle :

- Nous proposons d'accorder un poids par lien d'évolution. Le poids d'un lien augmentera à chaque fois qu'une instance de sa classe source l'empruntera pour évoluer vers sa classe cible. Ces poids nous donneront de bons indicateurs sur la tendance générale d'évolution des instances du modèle, et ce sur un intervalle de temps déterminé.

- Dans le cadre de l'émergence locale, cela ne peut être possible que sur une classe concrète (étant donné que l'émergence de nouveaux attributs vient d'une instance qui devra être rattachée à cette classe, cette dernière ne peut être que concrète). Par contre, et ce en terme de perspective, si toutes les sous-classes d'une classe abstraite voient émerger les mêmes nouveaux attributs, l'émergence locale se fera alors sur la classe abstraite. Cela reste dans le cadre de l'optimisation du modèle au bout d'un certain temps d'utilisation, et en ayant recours à des stratégies d'évolution existantes, principalement pour la factorisation de propriétés communes.

6.5.2. Priorité des perspectives

Nous présentons les perspectives selon l'ordre de priorité qui nous semble le plus
approprié. Nous prenons également en compte l'implémentation :

1. Implémentation:

Dans le cadre des prévisions du projet, nous prévoyons de compléter le prototype de
en poursuivant par l'implémentation :

1. du modèle de métriques de contexte intra-structure et de contexte inter-structures ;

2. de la gestion de l'insertion des structures émergeantes dans la hiérarchie de classes. Cette gestion implique également celle des impacts de cette insertion
dans le cadre du développement, et ce en utilisant des stratégies d'évolution déjà existantes et bien adaptées à la tâche ;

3. du lien d'évolution et des graphes d'évolution ;

4. enfin, du processus d'évolution par émergence locale.

2. Extension du modèle GENOME : quant à l'extension du modèle, nous récapitulons la suite de son extension et de son enrichissement par :

1. la prise en compte de la modélisation et de l'évolution d'objets composites et complexes, ce qui implique la prise en compte également de la modélisation et de l'évolution des relations sémantiques ;

2. la combinaison de diverses stratégies d'évolution pour gérer le développement ;

3. l'extension des règles et des situations de déclenchement des processus d'évolution ainsi que l'optimisation des processus d'évolution. Dans le cadre de l'optimisation des processus d'évolution, nous reprendront les automates définis pour les décrire avec des diagrammes d'activités ;

4. la spécification de l'évolution dynamique également pour les méthodes

3. Méthodologie : cet aspect méthodologique est une carence récurrente dans toutes les stratégies d'évolution (versionnement, catégorisation...). Il en est de même pour notre modèle d'évolution. Nous devons définir une méthodologie claire et qui est destinée au concepteur pour lui permettre d'utiliser les fonctionnalités de GENOME, et pour lui permettre d'intervenir durant tout le processus d'évolution.

Après ces quelques perspectives, qui mettent en évidence en même temps les limites que nous recensons au modèle proposé, nous achevons cette conclusion en rappelant que nous nous sommes intéressés à l'évolution dans la structure d'instances et de classes, en tentant de dégager des structures conceptuelles à partir d'instances. Nous visons en effet, à tirer profit d'informations structurelles présentes aussi bien au niveau des instances (niveau implémentation) qu'au niveau des classes (niveau conceptuel). Le résultat obtenu, ou plutôt les résultats obtenus (étant donné que plusieurs voies possibles d'évolution peuvent être obtenues après simulation), ne sont pas une transcription conceptuelle d'informations structurelles nouvellement présentes dans les instances, mais représentent des spécifications, voire des structures conceptuelles plus génériques et plus riches. Ces spécifications permettront de faire émerger des structures conceptuelles qui étaient plus ou moins noyées et qui s'avèrent plus prometteuses par rapport aux changements survenus dans l'environnement.
<figure><img src="image_75.png" /></figure>
BIBLIOGRAPHIE

<figure><img src="image_76.png" /></figure>
REFERENCES BIBLIOGRAPHIQUES
RELATIVES A CE TRAVAIL DE
RECHERCHE

Chapitre dans un ouvrage

[Oussalah& 99] Oussalah C., Tamzalit D., Chapitre 4 « l'émergence comme processus d'évolution d'objets » dans l'ouvrage « Génie Objet, Analyse et Conception de l'évolution », Éditions Hermes, septembre 1999.

Revue Internationale

[Tamzalit& 00] Tamzalit D., Oussalah C. « Allowing Conceptual Emergence through Instance Evolutionary Processes » D. Tamzalit & C. Oussalah - International Journal of Engineering Intelligent Systems. Pp 177-192. Vol 8 N° 3, Septembre 2000. ISSN 0969 1170.

Publications à des Conférences Internationales avec comité de lecture

[Oussalah& 00] Oussalah C., Tamzalit D., « Emergence Measurement and Analyzes of Conceptual Abstractions during Evolution Simulation in OOD » *ISMIS'2000 (twelfth international symposium on Methodologies for intelligent systems)*, Charlotte, USA, 11-14 Octobre 2000.

[Tamzalit& 00b] Tamzalit D., Oussalah C. « How to Manage Evolution in OODB? » 2000 ADBIS-DASFAA Symposium on Advances in Databases and Information Systems 5 – 8, Prague, République Tchèque, Septembre 2000.

[Tamzalit& 99b] Tamzalit D., Oussalah C. "From Object Evolution to Object Emergence", 8th ACM International Conference on Information and Knowledge Management, p. 514-521, Kansas-City, USA. November 1999.

[Oussalah& 99a] Oussalah C., Tamzalit D. « Emergence as Object Evolution Process » 4th *International Symposium on Programming and Systems (ISPS'99)* Alger, 18-20 Octobre 1999.

[Tamzalit& 99a] Tamzalit D., Oussalah C., « Instances Evolution Vs Classes Evolution » *DEXA'99*, Florence (Italie), 30 août – 3 septembre 1999.

[Tamzalit& 98b] Tamzalit D., Oussalah C., Magnan M. "How to Introduce Emergence in Object Evolution", Proceedings of International Conference on Object-Oriented Information Systems, Pp. 293-310, OOIS98, Paris, 1998.
[Oussalah& 98] Oussalah C., Tamzalit D., Magnan M., "Genetic Evolution as Object Evolution", *ICSIS'98*, Amman, Jordanie, Juin 1998.

[Tamzalit& 98a] Tamzalit D., Oussalah C., Magnan M., "GENOME: A Genetic Evolution Object Model", SEKE'98, San Francisco, U.S.A, Juin 1998.

## Publications à un Workshop International avec comité de lecture

[Tamzalit& 00a] Tamzalit D., Oussalah C. « A Model for Object Structures Emergence », Workshop Objects and classification : a natural convergence, ECOOP 2000, Sophia Antipolis, France, 12 juin 2000.

## Publication à une Conférence Nationale avec comité de lecture

[Rieu 97] Rieu D., Bounaas F., Morat P., Tamzalit D. « La métacircularité au service de la métamodélisation », Congrès INFORSID, Toulouse, France, juin 1997.
BIBLIOGRAPHIE

[Ahmed-Nacer 94] Ahmed-Nacer M. "Un modèle de gestion et d'évolution de schéma pour les bases de données de génie logiciel" Thèse de doctorat. Institut National Polytechnique de Grenoble, Grenoble, France, Juillet 1994.

[Astudillo 97] Astudillo H. "Maximizing Object Reuse with a Biological Metaphor", Wiley-Interscience Publication, John Wiley & Sons, vol. 3 n°4, 1997.

[Banerjee & 87] Banerjee J., Kim W., Kim H., Korth H.F. "Semantics Implementation of Schema Evolution in Object-Oriented Databases" ACM 1987.

[Bancilhon & 88] Bancilhon F., Barbedette G., Benzaken V., Delobel C., Gamerman S., Lécluse C., Pfeffer P., Richard P., Velez F. "The Design and Implementation of O2 an Object-Oriented Database System" Rapport Technique Altaïr 20-88. 13 avril 1988.

[Basili & 84] Basili, V.R., Weiss, D., "A methodology for collecting valid software engineering data", IEEE Transactions on Software Engineering. Pp 728-738. November 1984.

[Benatallah & 97] Benatallah B., Fauvet M.C. "Le point sur l'évolution du schéma d'une base de données" in L'Objet : Logiciel, Base de Données, Réseaux. Vol 3. N°3- Septembre 97. pp 277-297. Edition Hermes.

[Bertino 92] Bertino E. "A View Mechanism for Object-Oriented DataBases" 3rd International Conference on Extending Databases Technology, mars 23-24, Vienna (Austria), 1992

[Borgida 88] Borgida A. "Modelling Class Hierarchies With Contradictions", SIGMOD Record (special issue on SIGMOD'88), vol. 17, No 3. Pp. 434-443, ACM, September 1988.

[Bounaas 95] Bounaas F. "Gestion de l'évolution dans les bases de connaissances", Thèse de doctorat Informatique INPG, Grenoble, France, Octobre 1995

[Bratsberg 93] Bratsberg E. "Evolution and Integration of Classes in Object-Oriented Databases" PhD thesis, Norwegian Institute of Technology, jun. 1993.

[Briand 97] Briand L. C., Devanbu P., Melo W. L., "An Investigation into Coupling Measure for C++", in proceedings of ICSE'97, pp. 412-421, 1997.

[Caminada 92] Caminada A., « Présage, un environnement de modélisation multi-vue/multi-niveau pour la construction et l'utilisation d'applications de planification des réseaux de télécommunications », Thèse de doctorat, Université de Montpellier II, Novembre 1992.

[Capponi 94] Capponi C., « Interactive class classification using types », dans Edwin Diday, Yves Lechevallier, Martin Schader, Patrice Bertrand, Bernard Burtschy (éds.), New approaches in classification and data analysis, Springer-Verlag, Berlin (DE), pp204-211, 1994

[Casais 91] Casais E. "Managing Evolution in Object Oriented Environnements : An Algorithmic Approach" Thèse - Université de Genève. 1991.

[Cauvet & 99] Cauvet C., Semmak F. dans [Oussalah & 99], chapitre 1, Pp 25-26, 1999.

[Chidamber & 91] Chidamber S.R., Kemerer C.F. "Towards a Metric Suite for Object-Oriented Design" Conference proceedings OOPSLA 1991.

[Chidamber & 94] Chidamber S.R., Kemerer C.F. "A Metrics Suite for Object Oriented Design", IEEE Transactions on Software Engineering, vol. 20, 6 – 1994, p. 476-493.
<table>
  <tr>
    <td>[Clamen 94]</td>
    <td>Clamen S.M. "Schema Evolution and Integration" in Proceedings of the Distributed and Parallel Databases conference, volume 2, p 101-126. Kluwer Academic Publishers, Boston, 1994.</td>
  </tr>
  <tr>
    <td>[Coad 90]</td>
    <td>Coad P. "Object-Oriented Patterns", CACM, vol. 35, n°9, 1990.</td>
  </tr>
  <tr>
    <td>[Coulange 98]</td>
    <td>Coulange B. « Métrologie et Objets » L'Objet : Logiciel, Base de Données, Réseaux. Vol 4. N°4- Décembre 1998. Edition Hermes.</td>
  </tr>
  <tr>
    <td>[Dekker 94]</td>
    <td>Dekker L. "FROME : Représentation multiple et classification d'objets avec points de vue" Thèse de doctorat informatique, USTL, Lille, France, Juin 1994.</td>
  </tr>
  <tr>
    <td>[Demeyer & 99]</td>
    <td>Demeyer S., Ducasse S. "Metrics, Do They Really Help?" LMO 1999, Pp 69-82, VilleFranche-sur-Mer, France.</td>
  </tr>
  <tr>
    <td>[Dony & 97]</td>
    <td>Dony C., Huchard M., Libourel T., "Automatic hierarchie reorganization: an algorithm and case studies with overloading". Rapport technique 97279, Laboratoire d'Informatique, de Robotique et de Microélétronique de Montpellier, 1997.</td>
  </tr>
  <tr>
    <td>[Goldberg 94]</td>
    <td>Goldberg D.E. "Algorithmes Génétiques" Intelligence Artificielle - Edition Addison-Wesley. 1994.</td>
  </tr>
  <tr>
    <td>[Guetari 95]</td>
    <td>R. Guetari "An Object Model for the Real-Time Systems Design" in Actes 1995 IEEE International Conference on Systems, Man and Cybernetics. Vancouver, British Columbia, Canada, October 22-25, 1995.</td>
  </tr>
  <tr>
    <td>[Harani 97]</td>
    <td>Harani Y. « Une Approche Multi-Modèles pour la Capitalisation des Connaissances dans le Domaine de la Conception », Thèse de Doctorat, Université de l'IPG, Grenoble, France, Novembre 1997.</td>
  </tr>
  <tr>
    <td>[Harel 87]</td>
    <td>D. Harel - Statecharts : a visual formalism for complex systems, Science of Computer Programming pp. 231-274 - 1987.</td>
  </tr>
  <tr>
    <td>[Harel 96]</td>
    <td>D. Harel, E. Gery - Executable object modeling with statecharts, Proceedings 18 th Int. Conf. Soft. Eng. IEEE Press 1996 pp.246-257.</td>
  </tr>
  <tr>
    <td>[Haton & 91]</td>
    <td>Haton J.P., Bouzid N., Charpillet F., Haton M.C., Lâasri B., Lâasri H., Maquis P., Mondot T., Napoli A. « Le raisonnement en Intelligence Artificielle : modèles, techniques et architectures pour les systèmes à base de connaissances », InterEditions, 1991.</td>
  </tr>
  <tr>
    <td>[Heudin 94]</td>
    <td>Heudin J.C. "La Vie Artificielle" Edition Hermes, 1994.</td>
  </tr>
  <tr>
    <td>[Holland 75]</td>
    <td>Holland J. "Adaptation in Natural and Artificial Systems", University of Michigan Press, Ann Arbor, Mich., 1975.</td>
  </tr>
  <tr>
    <td>[Jacobson & 91]</td>
    <td>Jacobson I., Lindtröm F. "Re-engineering of Old Systems to an Object-Oriented Architecture" Conference proceedings OOPSLA 1991.</td>
  </tr>
  <tr>
    <td>[Jiang & 96]</td>
    <td>Jiang H., Castellani X. "Migration of Characteristics of Classes, a New Concept to Specify an Object System Evolution" 7th International Conference of the Information Resources Management Association (IRMA), May 1996, Washington, USA.</td>
  </tr>
  <tr>
    <td>[Katz & 87]</td>
    <td>Katz R.H., Chang E. "Managing change in a computer-aided design database" In Proceedings of the 13th conference on VLDB, pp 455-462, Brighton, England, September 1987.</td>
  </tr>
  <tr>
    <td>[Keen 89]</td>
    <td>Keen S.E., « Object-Oriented Programming in Common Lisp : A Programmer's Guide to CLOS », Addison-Wesley, Reading, MA, 1989.</td>
  </tr>
  <tr>
    <td>[Kim & 88]</td>
    <td>Kim W., Chou H.T. "Versions of schema for object oriented databases" In Proceedings of the 14th VLDB Conference, Los Angeles, California, 1988.</td>
  </tr>
  <tr>
    <td>[Kim & 90]</td>
    <td>Kim W. "Introduction to Object-Oriented Databases", MIT Press, Cambridge Massachusetts, 1990.</td>
  </tr>
  <tr>
    <td>[Langton & 90]</td>
    <td>Langton C., Taylor C., Farmer J.D., Rasmussen S. "Artificial Life II", Proceedings volume in the Santa Fe Institute studies in the sciences of complexity, 1990.</td>
  </tr>
</table>
[Lerner& 90] Lerner B.S., Habermann A.N. "Beyond Schema Evolution to Database Reorganization" in Proc. ACM Conf. OOPSLA and Proc. ECOOP, Ottawa, Canada. Published as ACM SIGPLAN Notices 25(10), pp. 67-76. October 1990.

[Li& 94] Li Q., McLeod D. "Conceptual Database Evolution Through Learning in Object Databases", IEEE Transactions on Knowledge and Data Engineering' volume 6 – n°2 – Pp: 205-224. avril 1994.

[Li& 98] Li Wei, Talburt J. "Empirically Analyzing Object-Oriented Software Evolution", JOOP, September 1998, Pp. 15-19.

[Masini 89] Masini G., Napoli A., Colnet D., & all « Les langages à Objets », Interéditions, 1989.

[Meslati& 97] Meslati D., Ghoul S. "Semantic Classification : A genetic approach to classification in object-oriented models", JOOP, 1997.

[Meyer 88] Meyer B. "Object-Oriented Software Construction" International Series in Computer Science. Prenctice Hall, 1988.

[Muller 97] Muller P.A. Modélisation objet avec UML, édition Eyrolles, 1997.

[Napoli 92] Napoli A. "Représentation à objets et raisonnement par classification en I.A." Thèse de doctorat, Nancy 1992.

[Nguyen& 89] Nguyen G.T., Rieu D. "Schema Evolution in Object-Oriented Database Systems", Data and Knowledge Engineering, Vol. 4, 1989.

[Nguyen& 97] Nguyen G.T. dans [Oussalah& 97], Chapitre 6, Pp 205-232, 1997.

[Orel& 95] Orel T., Trousse B. "A view on the Philosophical Meanings of the Concept of Design", Journal of Design Sciences and Technology, vol. 4, 1995.

[Oussalah 88] Oussalah C., « Modèles hiérarchisés multi-vues pour le support de raisonnement dans les domaines techniques », Thèse de doctorat, université de droit, d'économie et de sciences d'Aix-Marseille, Juin 1988.

[Oussalah& 97] Oussalah C. et alii « Ingénierie Objets – Concepts et Techniques », InterEditions, 1997.

[Oussalah& 99] Oussalah C. & alii « Génie Objet : analyse et conception de l'évolution », Editions Hermes, 1999.

[Penney& 87] Penney D.J., Stein J. "Class modification in the GemStone object-oriented DBMS" SIGPLAN Notices (Proc OOPSLA'87) Vol. 22, No. 12, pp. 111-117. 1987.

[Pernici 91] Pernici B. "Objects with Roles" IEEE Conference on Office Information Systems, vol 16, n°3, pp 417-438, september 1991.

[Peyrade 87] Peyrade M., « Computer-aided Telecommunications Network Planning », communication & Transmission, n°2, 1987.

[Price 97] Price M.W., Dumerjian S.A. "Analyzing and Measuring Reusability in Object-Oriented Designs" Conference proceedings OOPSLA 1997.

[Puig 97] Puig V., « CHIC: Un Modèle de Contraintes dans les Hiérarchies de Composition d'Objets, » Thèse de Doctorat, Université de Montpellier II, Montpellier, France, 1997.

[Rashid& 99] Rashid A., Sawyer P. "Dynamic Relationships in Object Oriented Databases: A Uniform Approach" In proceedings of DEXA'99, Pp 26-35; Florence, August/September 1999.

[Rational 97] Rational Corporation. UML Notation Guide 1.1. Septembre 1997.

[Rechenman 89] Rechenman F., Uvietta P. "SHIRKA : an object-centered knowldege bases management system." In A. Pavé and G. Vansteenkiste ED. Artificial Intelligence in numerical and symbolic simulation, ALEAS, Lyon, France, pp 9-23.

[Rieu& 92] Rieu D., Nguyen G.T, Escamilla J. "SHOOD : an object model for design applications", Proc. 7th Intl. Conf. Artificial Intelligence, Expert Systems & Natural Language, Avignon, France, juin 1992.
<table>
  <tr>
    <td>[Rieu 99]</td>
    <td>Rieu D. « Ingénierie des Systèmes d'Informations : Bases de Données, Bases de Connaissances et Méthodes de Conception. » Mémoire d'Habilitation à diriger des Recherches. LSR IMAG - INPG, 1999.</td>
  </tr>
  <tr>
    <td>[Rocacher 88]</td>
    <td>Rocacher D. "Metrics definitions for Smalltalk" Projet ESPRIT 1257, MUSE WP9A, 1988.</td>
  </tr>
  <tr>
    <td>[Sahraoui 99]</td>
    <td>Sahraoui A.H., Lounis H., Mao Y. « Impact du couplage sur la réutilisabilité des classes : une étude de cas. » LMO 1999, pp 83-98, VilleFranche-sur-Mer, France.</td>
  </tr>
  <tr>
    <td>[Segapeli& 99]</td>
    <td>Segapeli J.L, Cavarero A. « Comment construire un schéma de classes à partir d'exemples ». LMO 1999, pp 213-228, VilleFranche-sur-Mer, France.</td>
  </tr>
  <tr>
    <td>[Skarra& 87]</td>
    <td>Skarra A.H., Zdonik S.B. "Type Evolution in an Object-Oriented Databases" in Research Directions in Object-Oriented Programming, MIT Press Series in Computer Systems, MIT Press, Cambridge, MA, 1987, pp. 393-415. 1987.</td>
  </tr>
  <tr>
    <td>[Stroustrup 96]</td>
    <td>Stroustrup B. « Le langage C++ », International Thomson Publishing France, Deuxième édition, Paris, 1996.</td>
  </tr>
  <tr>
    <td>[Sun 98]</td>
    <td>SUN MICROSYSTEMS. Programmation Java - LJ20 - Solaris 2.x, Windows NT, Guide étudiant, Janvier 1998.</td>
  </tr>
  <tr>
    <td>[Syswerda 89]</td>
    <td>Syswerda G. "Uniform Crossover in Genetic Algorithms" dans les actes de Intl. Conf. On Genetic Algorithms, pages 2-9, 1989.</td>
  </tr>
  <tr>
    <td>[Talens 93]</td>
    <td>Talens G., Oussalah C., Colinas M.F. "Versions of Simple and Composite Objects" VLDB'93 : 19th International Conference on VLDB, Dublin- Ireland. Août 1993.</td>
  </tr>
  <tr>
    <td>[Talens 94]</td>
    <td>Talens G., « Gestion de versions d'objets simples et composites », Thèse de Doctorat, Université de Montpellier II, Montpellier, France, Février 1994.</td>
  </tr>
  <tr>
    <td>[Urtado 98]</td>
    <td>Urtado C, « Versions d'Entités Complexes – Approches Microscopique et Macroscopique », Thèse de Doctorat, Université de Montpellier II, Montpellier, France, Octobre 1998.</td>
  </tr>
  <tr>
    <td>[Weinberg 85]</td>
    <td>Weinberg GM "Natural Selection as Applied to Computers and Programs" Chapitre dans 'Processes of Software Changes' - Academic Press - London. Editeur : Lehman MM and Belady LA. Côte : R3127, 1985.</td>
  </tr>
  <tr>
    <td>[Zdonik 90]</td>
    <td>Zdonik S.B. "Object-Oriented Type Evolution" in Advances in Database Programming Languages, François Bancilhon and Peter Buneman (eds.), ACM Press, New York, NY, pp. 277-288, 1990.</td>
  </tr>
  <tr>
    <td>[Zicari 91]</td>
    <td>Zicari R., "A framework for schema updates in an object oriented database system", in proc. Of the 7th Conf. On Data Engineering, Japan, 1991.</td>
  </tr>
</table>
**Résumé** : nous proposons le modèle d'évolution GENOME basé sur l'évolution dynamique de structure d'objets. Dans le cadre d'applications d'ingénieries complexes et volumineuses, nous voulons permettre à un concepteur de faire face à des besoins d'évolution imprévus ou mal spécifiés. Comme nous considérons l'évolution comme un processus interactif et itératif d'adaptation entre classes et objets, l'objectif est de rechercher et de dégager diverses voies d'évolution des structures conceptuelles à partir de l'évolution dynamique de la structure d'objets. Pour cela, GENOME permet au concepteur d'exprimer directement les nouveaux besoins sur les objets concernés. Ensuite, il recherche diverses voies possibles d'évolution pour permettre l'adaptation aux besoins. La recherche passe par la simulation de plusieurs voies d'évolution. L'adaptation passe par l'émergence de nouvelles structures conceptuelles. Celles-ci sont mieux adaptées et plus complètes, et émergent en tirant profit de l'expression des besoins ponctuels et des informations présentes dans la base.

Cette simulation d'évolution se fait au travers de *processus d'évolution*. Tout processus peut aboutir à deux situations : les *processus de développement* qui représentent toute extension de classes existantes par création, modification ou migration d'instances ; les *processus d'émergence* qui représentent toute émergence de nouvelles propriétés et/ou structures conceptuelles. Ces derniers peuvent être de *l'émergence locale* de nouvelles propriétés au sein de classes existantes, ou de *l'émergence globale* d'une nouvelle structure conceptuelle à partir de l'objet ayant évolué, ou en croisant plusieurs structures conceptuelles grâce au mécanisme de *croisement* proposé. Pour contrôler l'émergence, nous définissons des métriques objets de contextes *intra-structure* et *inter-structures*. Leur utilisation permet de trouver la structure émergente la plus cohérente, la plus significative et qui répond au mieux aux *invariants* du concepteur.

**Mots-clés** : Évolution dynamique d'objets - Émergence - Développement - Génotype - Phénotype - Génotype Fondamental - Génotype Hérité - Génotype Spécifique - Sélection - Croisement - Adaptation - Métriques.

**Abstract:** we propose the GENOME evolution model based on the dynamic evolution of objects structure. Within complex and bulky engineering applications, we want to allow a designer to face unpredicted and badly specified evolution needs. As we consider object evolution as an iterative and adaptive process between classes and objects, our objective is to search and extract several ways of evolution of conceptual structures from the dynamic evolution of objects in their structure. For that, GENOME allows the designer to express directly his new needs on the concerned objects. Then, it explores to find several ways of evolution, in order to achieve the adaptation to these new needs. The exploration is done through the simulation of these evolution ways. The adaptation is done through the emergence of new conceptual structures. These lasts are well-adapted and more complete, and they emerge from the expression of the needs and existing information within the database.

This simulation of evolution is done within *Evolutionary Processes*. Each process can lead to two situations: *Development processes* which represent classes extension by creating or modifying objects, or by migration of objects; *Emergence processes* which represent emergence of new properties or/and new conceptual structures. These processes can lead to *local emergence* of new properties within existing classes, or to *global emergence* of new conceptual structures from the evolved objects, or by crossing existing conceptual structures thanks to the proposed *crossing-over* mechanism. In order to control the emergence, we define some object metrics of *intra-structure* context and *inter-structures* context. Their use permit to find the most coherent, the most significant emergent structure and which well respond to the designer *invariants*.

**Key-Words:** dynamic object evolution – emergence – development – genotype – phenotype – fundamental genotype – inherited genotype – specific genotype – selection – crossing-over – adaptation – metrics.