# GENOME: un Modèle pour la Simulation d'Émergence de Structures d'Objets

Dalila Tamzalit

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

To cite this version:

Dalila Tamzalit. GENOME: un Modèle pour la Simulation d'Émergence de Structures d'Objets. Informatique [cs]. Université de Nantes (1962-2021), 2000. Français. NNT: tel-04421358

HAL Id: tel-04421358

https://hal.science/tel-04421358

Submitted on 27 Jan 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

Public Domain
UNIVERSITE DE NANTES

UFR SCIENCES ET TECHNIQUES

ÉCOLE DOCTORALE

SCIENCES ET TECHNOLOGIES
DE L'INFORMATION ET DES MATERIAUX

2000

Thèse de DOCTORAT

Spécialité : INFORMATIQUE

Présentée et soutenue publiquement par

Dalila TAMZALIT

Le 14 décembre 2000

A la Faculté des Sciences et Techniques, Université de Nantes

GENOME : un Modèle pour la Simulation d'Émergence de
Structures d'Objets

Jury

Président : Jean Jacques CHABRIER, Professeur, Université de Bourgogne

Rapporteurs : Annie CAVARERO, Professeur Université de Nice
Dominique RIEU, HDR LSR IMAG - INPGrenoble

Examinateurs : Marie Françoise COLINAS, Responsable département CNET
Noureddine MOUADDIB, Professeur, École Polytechnique de Nantes
Jean-François SANTUCCI, Professeur, Université de Corte

Directeur de Thèse : Mourad Chabane OUSSALAH

IRIN,
2 rue de la Houssinière
BP 92208
44322 NANTES cedex 3

N° ED 0366-xxx
# TABLE DES MATIERES

Table Des Matières 1

Liste des Figures 11

Liste des Tableaux 13

Introduction 15

1.1 - Cadre de l'étude 17

1.2 - Objectif : un Modèle pour la Simulation de l'Évolution d'Objets 18

1.3 - Plan du manuscrit 19

1.3.1. Chapitre 1 : Contexte de travail, motivations et hypothèses de travail 19

1.3.2. Chapitre 2 : État de l'Art 19

1.3.3. Chapitre 3 : GENOME : les concepts 21

1.3.4. Chapitre 4 : GENOME : les processus d'évolution 21

1.3.5. Chapitre 5 : GENOME : les métriques pour contrôler l'émergence 22

1.3.6. Chapitre 6 : Implémentation 22

1.3.7. Conclusion : Contributions et Perspectives 22

Chapitre 1 : Contexte de travail, motivations et Hypothèses de travail 23

1.1 - Introduction 25

1.2 - Contexte du travail : Modélisation des réseaux de télécommunications 26

1.2.1. Le projet Présage 26

1.2.2. L'évolution dans les réseaux de télécommunications 27

1.2.3. Modélisation des réseaux de télécommunications et illustration par un exemple 28

1.3 - Problématique 29

1.3.1. Problématique du concepteur 29

1.3.2. Problématique sous l'angle de vue de la modélisation et de l'évolution d'objets 30

1.3.3. Conclusion 31

1.4 - Approche de la problématique 31

1.4.1. Nos motivations : faire face à des situations imprévues de changements 32

1.4.2. Reconsidérons les instances 33
<table><tr><td>1.4.3. Notre contribution : un modèle pour la simulation d'évolution</td><td>33</td></tr><tr><td>1.5 - Hypothèses de travail</td><td>34</td></tr><tr><td>1.6 - Conclusion</td><td>35</td></tr></table>

## Chapitre 2 : État de l'Art 37

2.1 - Introduction 39

2.2 - Les trois facettes de l'Évolution d'Objets 40

2.2.1. Introduction 40

2.2.2. Les trois facettes de l'évolution d'objets 40

2.2.2.1. Objet de l'Évolution 41

2.2.2.2. Type de l'Évolution 41

2.2.2.3. Processus d'Évolution 42

2.2.3. Représentation triptyque 43

2.2.4. Comment positionner une stratégie d'évolution ? 44

2.3 - Problématique de l'Évolution du produit 45

2.3.1. Problématique dans l'Évolution du Produit 45

2.3.1.1. Problématique de l'évolution de classes 46

2.3.1.2. Problématique de l'évolution d'instances 46

2.3.2. Problématique de notre approche 47

2.3.3. Stratégies d'Évolution étudiées 47

2.4 - Principales Stratégies d'Évolution par modification de produit 49

2.4.1. Réorganisation de classes 49

2.4.1.1. Principe, avantages et inconvénients 49

2.4.1.2. Fonctionnement de l'évolution 49

2.4.2. Classification de classes 51

2.4.2.1. Principe, avantages et inconvénients 51

2.4.2.2. Fonctionnement de l'évolution 51

2.4.3. Catégorisation 52

2.4.3.1. Principe, avantages et inconvénients 52

2.4.3.2. Fonctionnement de l'évolution 52

2.4.4. Correction de classes ou Chirurgie de classes : 52

2.4.4.1. Principe, avantages et inconvénients 52

2.4.4.2. Fonctionnement de l'évolution 53

2.4.5. Versionnement de classes 55

2.4.5.1. Principe, avantages et inconvénients 55

2.4.5.2. Fonctionnement de l'évolution 56

2.4.6. Migration de caractéristiques 56

2.4.6.1. Principe, avantages et inconvénients 56

2.4.6.2. Fonctionnement de l'évolution 57

2.4.7. Premier bilan : positionnement des stratégies étudiées dans le triptyque 59

2.4.8. Impacts de l'évolution de classes vers les instances 60

2.4.8.1. Conversion d'instances 60

2.4.8.2. Émulation d'instances 60

2.4.8.3. Versionnement d'instances 61

2.4.9. Évolution d'instances 61

2.4.9.1. Contraintes d'intégrité 61
<table><tbody><tr><td>2.4.9.2. Versions d'instances</td><td>61</td></tr><tr><td>2.4.9.3. Classification d'instances</td><td>62</td></tr><tr><td>2.5 - Taxonomies de produits et d'opérations</td><td>62</td></tr><tr><td>2.5.1. Taxonomie du produit</td><td>62</td></tr><tr><td>2.5.1.1. Nœud</td><td>63</td></tr><tr><td>2.5.1.2. Contenu d'un nœud</td><td>63</td></tr><tr><td>2.5.1.3. Arc</td><td>63</td></tr><tr><td>2.5.2. Taxonomie des opérations</td><td>63</td></tr><tr><td>2.5.2.1. Opérations de base</td><td>63</td></tr><tr><td>2.5.2.2. Opérations avancées</td><td>64</td></tr><tr><td>2.5.3. Bilan</td><td>65</td></tr><tr><td>2.6 - Autres travaux portant sur l'Évolution d'Objets</td><td>67</td></tr><tr><td>2.6.1. Autres stratégies d'évolution de classes</td><td>68</td></tr><tr><td>2.6.1.1. Ajustement de classes</td><td>68</td></tr><tr><td>2.6.1.2. Approches de représentations multiples : Points de vue, Rôles, Vues</td><td>68</td></tr><tr><td>2.6.1.3. Approche par Scénario</td><td>69</td></tr><tr><td>2.6.2. Limites des approches actuelles</td><td>69</td></tr><tr><td>2.6.3. Second bilan : positionnement des principales stratégies dans le triptyque</td><td>70</td></tr><tr><td>2.6.4. Travaux connexes</td><td>72</td></tr><tr><td>2.7 - L'émergence curative : comment ?</td><td>73</td></tr><tr><td>2.8 - Les travaux de l'Évolution Artificielle</td><td>74</td></tr><tr><td>2.8.1. L'Évolution Artificielle</td><td>74</td></tr><tr><td>2.8.2. Principe général</td><td>74</td></tr><tr><td>2.8.2.1. La Vie Artificielle</td><td>75</td></tr><tr><td>1) - Définition</td><td>75</td></tr><tr><td>2) - Concepts</td><td>75</td></tr><tr><td>3) - Principes d'évolution</td><td>76</td></tr><tr><td>2.8.2.2. Les Algorithmes Génétiques</td><td>77</td></tr><tr><td>1) - Définition</td><td>77</td></tr><tr><td>2) - Concepts</td><td>78</td></tr><tr><td>3) - Principes d'évolution</td><td>78</td></tr><tr><td>2.8.3. Conclusion</td><td>81</td></tr><tr><td>2.9 - Conclusion</td><td>83</td></tr></tbody></table>

Chapitre 3 : Genome : les concepts 85

<table><tbody><tr><td>3.1 - Introduction</td><td>87</td></tr><tr><td>3.2 - Exemple</td><td>88</td></tr><tr><td>3.3 - Préliminaire des processus d'évolution</td><td>90</td></tr><tr><td>3.3.1. Le développement</td><td>90</td></tr><tr><td>3.3.2. L'émergence</td><td>91</td></tr><tr><td>3.4 - Les concepts de base</td><td>91</td></tr><tr><td>3.4.1. Gène</td><td>91</td></tr><tr><td>3.4.2. Classe-GTYPE</td><td>92</td></tr><tr><td>3.4.3. Instance-PTYPE</td><td>92</td></tr><tr><td>3.4.4. Population et Patrimoine Génétique</td><td>92</td></tr><tr><td>3.5 - Les concepts avancés</td><td>93</td></tr></tbody></table>
<table><tbody><tr><td>3.5.1. Génotype Fondamental</td><td>94</td></tr><tr><td>3.5.1.1. Définition</td><td>94</td></tr><tr><td>3.5.1.2. Principales propriétés du Génotype Fondamental</td><td>94</td></tr><tr><td>3.5.2. Génotype Hérité</td><td>95</td></tr><tr><td>3.5.3. Génotype Spécifique</td><td>96</td></tr><tr><td>3.5.4. Le schème</td><td>96</td></tr><tr><td>3.5.4.1. Schème permanent</td><td>96</td></tr><tr><td>3.5.4.2. Schème temporaire</td><td>97</td></tr><tr><td>3.5.4.3. Représentation d'un schème</td><td>97</td></tr><tr><td>3.5.5. Le lien d'évolution</td><td>98</td></tr><tr><td>3.6 - L'exemple et sa représentation</td><td>98</td></tr><tr><td>3.7 - Le méta-modèle</td><td>100</td></tr><tr><td>3.7.1.1. Formalisme utilisé</td><td>100</td></tr><tr><td>3.7.1.2. Synoptique du modèle</td><td>100</td></tr><tr><td>3.7.1.3. Définition et rôle des classes</td><td>101</td></tr><tr><td>1) - Population</td><td>101</td></tr><tr><td>2) - PatrimoineGenetique</td><td>101</td></tr><tr><td>3) - ClasseGtype</td><td>102</td></tr><tr><td>4) - Attributs</td><td>102</td></tr><tr><td>5) - Methode</td><td>103</td></tr><tr><td>6) - Scheme</td><td>103</td></tr><tr><td>7) - InstanceClasseGtype</td><td>103</td></tr><tr><td>3.7.1.4. Définition des différents liens</td><td>103</td></tr><tr><td>1) - 'faitPartie' entre classe ClasseGtype et classe Population</td><td>103</td></tr><tr><td>2) - 'son PG' entre classe Population et classe PatrimoineGenetique</td><td>104</td></tr><tr><td>3) - 'AttributsGF' entre classe Population et classe Attributs</td><td>104</td></tr><tr><td>4) - 'MethodesGF' entre classe Population et classe Methode</td><td>104</td></tr><tr><td>5) - 'is-a' entre classe ClasseGtype</td><td>104</td></tr><tr><td>6) - 'MethodesGH' entre classe ClasseGtype et classe Methode</td><td>104</td></tr><tr><td>7) - 'MethodesGS' entre classe ClasseGtype et classe Methode</td><td>104</td></tr><tr><td>8) - 'AttributsGH' entre classe ClasseGtype et classe Attributs</td><td>104</td></tr><tr><td>9) - 'AttributsGS' entre classe ClasseGtype et classe Attributs</td><td>104</td></tr><tr><td>10) - 'aPourSchemePermanent' entre classe ClasseGtype et classe Scheme</td><td>105</td></tr><tr><td>11) - 'estAssocieA' entre classe ClasseGtype</td><td>105</td></tr><tr><td>12) - 'lienEvolution' entre classe ClasseGtype</td><td>105</td></tr><tr><td>3.8 - Conclusion</td><td>106</td></tr></tbody></table>

Chapitre 4 : Genome : les processus d'évolution 107

<table><tbody><tr><td>4.1 - Introduction</td><td>109</td></tr><tr><td>4.1.1. L'évolution gérée au travers de processus d'évolution</td><td>109</td></tr><tr><td>4.1.2. Formalisme utilisé</td><td>110</td></tr><tr><td>4.1.3. Niveau d'abstraction considéré</td><td>111</td></tr><tr><td>4.2 - Les trois phases d'un processus d'évolution : définition</td><td>112</td></tr><tr><td>4.2.1. Présentation</td><td>112</td></tr><tr><td>4.2.2. Phase d'extraction</td><td>114</td></tr><tr><td>4.2.3. Phase d'exploration</td><td>114</td></tr></tbody></table>
<table>
  <tbody>
    <tr>
      <td>4.2.4. Phase d'exploitation</td>
      <td>114</td>
    </tr>
    <tr>
      <td>4.2.4.1. Processus de développement</td>
      <td>115</td>
    </tr>
    <tr>
      <td>4.2.4.2. Processus d'émergence</td>
      <td>115</td>
    </tr>
    <tr>
      <td>4.3 - Les Opérateurs Génétiques Objets</td>
      <td>116</td>
    </tr>
    <tr>
      <td>4.3.1. Introduction</td>
      <td>116</td>
    </tr>
    <tr>
      <td>4.3.2. Sélection</td>
      <td>117</td>
    </tr>
    <tr>
      <td>4.3.3. Reproduction</td>
      <td>117</td>
    </tr>
    <tr>
      <td>4.3.4. Croisement</td>
      <td>117</td>
    </tr>
    <tr>
      <td>4.3.5. Mutation</td>
      <td>118</td>
    </tr>
    <tr>
      <td>4.3.6. Valeur d'Adaptation</td>
      <td>118</td>
    </tr>
    <tr>
      <td>4.3.7. Distance Sémantique</td>
      <td>120</td>
    </tr>
    <tr>
      <td>4.3.8. Classification et utilisation des opérateurs</td>
      <td>121</td>
    </tr>
    <tr>
      <td>4.3.8.1. Classification des opérateurs</td>
      <td>121</td>
    </tr>
    <tr>
      <td>4.3.8.2. Utilisation des opérateurs</td>
      <td>122</td>
    </tr>
    <tr>
      <td>4.4 - Les trois phases de tout processus d'évolution : Les automates</td>
      <td>122</td>
    </tr>
    <tr>
      <td>4.4.1. L'exemple</td>
      <td>123</td>
    </tr>
    <tr>
      <td>4.4.2. Notion d'invariant</td>
      <td>124</td>
    </tr>
    <tr>
      <td>4.4.3. Phase d'extraction</td>
      <td>125</td>
    </tr>
    <tr>
      <td>4.4.3.1. Automate</td>
      <td>125</td>
    </tr>
    <tr>
      <td>4.4.3.2. Exemple</td>
      <td>127</td>
    </tr>
    <tr>
      <td>4.4.4. Phase d'exploration</td>
      <td>128</td>
    </tr>
    <tr>
      <td>4.4.4.1. Automate</td>
      <td>128</td>
    </tr>
    <tr>
      <td>4.4.4.2. Exemples</td>
      <td>129</td>
    </tr>
    <tr>
      <td>1) - Objet O<sub>1</sub></td>
      <td>129</td>
    </tr>
    <tr>
      <td>2) - Objet O<sub>2</sub></td>
      <td>131</td>
    </tr>
    <tr>
      <td>3) - Objet O<sub>3</sub></td>
      <td>131</td>
    </tr>
    <tr>
      <td>4) - Objet O<sub>4</sub></td>
      <td>132</td>
    </tr>
    <tr>
      <td>5) - Objet O<sub>5</sub></td>
      <td>133</td>
    </tr>
    <tr>
      <td>6) - Conclusion</td>
      <td>134</td>
    </tr>
    <tr>
      <td>4.4.5. Phase d'exploitation</td>
      <td>135</td>
    </tr>
    <tr>
      <td>4.4.5.1. Automates</td>
      <td>136</td>
    </tr>
    <tr>
      <td>4.4.5.2. Exemple</td>
      <td>137</td>
    </tr>
    <tr>
      <td>4.5 - L'émergence</td>
      <td>138</td>
    </tr>
    <tr>
      <td>4.5.1. L'émergence locale</td>
      <td>138</td>
    </tr>
    <tr>
      <td>4.5.1.1. L'automate</td>
      <td>138</td>
    </tr>
    <tr>
      <td>4.5.1.2. L'exemple</td>
      <td>139</td>
    </tr>
    <tr>
      <td>4.5.2. L'émergence globale</td>
      <td>140</td>
    </tr>
    <tr>
      <td>4.5.2.1. L'émergence directe</td>
      <td>140</td>
    </tr>
    <tr>
      <td>1) - L'automate</td>
      <td>141</td>
    </tr>
    <tr>
      <td>2) - Les exemples</td>
      <td>142</td>
    </tr>
    <tr>
      <td>4.5.2.2. L'émergence globale par croisement</td>
      <td>143</td>
    </tr>
    <tr>
      <td>1) - Définition détaillée du croisement</td>
      <td>143</td>
    </tr>
    <tr>
      <td>2) - La contrainte de blocs de gènes dans le croisement</td>
      <td>145</td>
    </tr>
    <tr>
      <td>3) - L'automate</td>
      <td>145</td>
    </tr>
    <tr>
      <td>4) - Les exemples</td>
      <td>147</td>
    </tr>
    <tr>
      <td>4.5.3. Discussion sur l'émergence</td>
      <td>150</td>
    </tr>
  </tbody>
</table>
<table><tbody><tr><td>4.5.3.1. L'émergence locale</td><td>151</td></tr><tr><td>4.5.3.2. L'émergence globale</td><td>151</td></tr><tr><td>1) - L'émergence globale par création directe de la structure conceptuelle</td><td>151</td></tr><tr><td>2) - L'émergence globale par croisement</td><td>152</td></tr><tr><td>3) - L'exemple de l'objet O<sub>1</sub></td><td>152</td></tr><tr><td>4) - L'exemple de l'objet O<sub>5</sub></td><td>154</td></tr><tr><td>5) - L'héritage multiple et l'émergence globale par croisement</td><td>154</td></tr><tr><td>6) - Conclusions</td><td>155</td></tr><tr><td>4.5.3.3. Compléter le comportement spécifié au sein des structures conceptuelles</td><td>155</td></tr><tr><td>4.6 - Le développement</td><td>156</td></tr><tr><td>4.7 - Le lien d'évolution</td><td>157</td></tr><tr><td>4.7.1. Introduction</td><td>158</td></tr><tr><td>4.7.2. Définition du lien d'évolution</td><td>158</td></tr><tr><td>4.7.3. Utilité du lien d'évolution</td><td>159</td></tr><tr><td>4.7.4. Les graphes d'évolution</td><td>160</td></tr><tr><td>4.7.5. Les exemples</td><td>160</td></tr><tr><td>1) - Modifications apportées à la hiérarchie de classes</td><td>162</td></tr><tr><td>2) - Spécifications des liens d'évolution</td><td>162</td></tr><tr><td>4.8 - Conclusion</td><td>164</td></tr></tbody></table>

## Chapitre 5 : Genome : les métriques pour contrôler l'émergence ____________ 167

<table><tbody><tr><td>5.1 - Introduction</td><td>169</td></tr><tr><td>5.1.1. Les limites de l'émergence</td><td>169</td></tr><tr><td>5.1.2. Des métriques au service de l'émergence</td><td>170</td></tr><tr><td>5.2 - Les Métriques Orientées Objet</td><td>171</td></tr><tr><td>5.2.1. Définitions</td><td>172</td></tr><tr><td>5.2.2. Caractéristiques d'une métrique</td><td>172</td></tr><tr><td>5.2.3. Contextes d'utilisation d'une métrique et exemples</td><td>173</td></tr><tr><td>5.2.3.1. Contexte d'Application</td><td>173</td></tr><tr><td>5.2.3.2. Contexte de Classe</td><td>173</td></tr><tr><td>5.2.3.3. Contexte de Fonction</td><td>174</td></tr><tr><td>5.3 - les métriques dans notre modèle</td><td>175</td></tr><tr><td>5.3.1. Détection des métriques nécessaires grâce à la technique GQM</td><td>176</td></tr><tr><td>5.3.1.1. Définition de la technique GQM</td><td>176</td></tr><tr><td>5.3.1.2. Première application de la technique GQM pour un processus d'évolution de GENOME</td><td>177</td></tr><tr><td>5.3.2. Les métriques et GENOME</td><td>178</td></tr><tr><td>5.3.2.1. Deuxième application de la technique GQM pour un processus d'évolution de GENOME</td><td>179</td></tr><tr><td>5.3.2.2. Métriques de Contexte Intra-structure</td><td>181</td></tr><tr><td>1) - Définition</td><td>181</td></tr><tr><td>2) - Métrique de Signification S</td><td>182</td></tr><tr><td>3) - Métrique de Contradiction C<sub>t</sub></td><td>183</td></tr><tr><td>4) - Métrique pour la Cohérence C<sub>h</sub></td><td>184</td></tr><tr><td>5) - Conclusion sur l'utilisation des métriques intra-structure</td><td>184</td></tr><tr><td>5.3.2.3. Métriques de Contexte Inter-structures</td><td>185</td></tr></tbody></table>
<table><tr><td>1) - Définition</td><td>185</td></tr><tr><td>2) - Métrique Distance Sémantique d.s</td><td>185</td></tr><tr><td>3) - Métrique de Contradiction C<sub>d</sub></td><td>185</td></tr><tr><td>4) - Métrique de Couplage C<sub>p</sub></td><td>186</td></tr><tr><td>5) - Métrique de Profondeur P<sub>d</sub></td><td>187</td></tr><tr><td>6) - Conclusion sur l'utilisation des métriques inter-structures</td><td>187</td></tr><tr><td>5.3.3. L'application des métriques et les invariants</td><td>188</td></tr><tr><td>5.3.3.1. Invariants sur les instances</td><td>188</td></tr><tr><td>5.3.3.2. Invariants sur les résultats de l'émergence</td><td>189</td></tr><tr><td>5.4 - Exemples</td><td>191</td></tr><tr><td>5.4.1. Exemple de l'objet O<sub>1</sub></td><td>191</td></tr><tr><td>5.4.1.1. Métriques Contexte intra-structure</td><td>192</td></tr><tr><td>5.4.1.2. Métriques Contexte inter-structures</td><td>193</td></tr><tr><td>5.4.2. Exemple de l'objet O<sub>5</sub></td><td>194</td></tr><tr><td>5.4.2.1. Métriques Contexte intra-structure</td><td>194</td></tr><tr><td>5.4.2.2. Métriques Contexte inter-structures</td><td>195</td></tr><tr><td>5.5 - l'exemple final</td><td>196</td></tr><tr><td>5.6 - Conclusion</td><td>200</td></tr></table>

## Chapitre 6 : Implémentation 203

<table><tr><td>6.1 - Introduction</td><td>205</td></tr><tr><td>6.2 - L'environnement Présage et GENOME</td><td>206</td></tr><tr><td>6.2.1. L'infrastructure de Présage</td><td>206</td></tr><tr><td>6.2.2. GENOME et les choix d'implémentation</td><td>207</td></tr><tr><td>6.2.2.1. Positionnement de GENOME par rapport à Présage</td><td>207</td></tr><tr><td>6.2.2.2. Choix d'implémentation de GENOME</td><td>208</td></tr><tr><td>6.3 - Le modèle d'implémentation de GENOME</td><td>209</td></tr><tr><td>6.3.1. Le modèle GENOME</td><td>209</td></tr><tr><td>6.3.2. Les processus d'évolution</td><td>214</td></tr><tr><td>6.3.3. Un exemple de Présage</td><td>216</td></tr><tr><td>6.4 - Descriptif et état d'avancement</td><td>218</td></tr><tr><td>6.4.1. Processus d'émergence globale par croisement</td><td>219</td></tr><tr><td>6.4.1.1. Validation et amélioration du croisement</td><td>219</td></tr><tr><td>6.4.1.2. Deuxième étape dans l'implémentation du croisement</td><td>221</td></tr><tr><td>6.4.2. État d'avancement du prototype</td><td>221</td></tr><tr><td>6.4.2.1. Le modèle de GENOME</td><td>222</td></tr><tr><td>6.4.2.2. Les Processus d'Évolution de GENOME</td><td>222</td></tr><tr><td>6.4.2.3. Complexité du croisement</td><td>223</td></tr><tr><td>6.5 - Conclusion</td><td>223</td></tr></table>

## Conclusion : Contributions et Perspectives 225

<table><tr><td>7.1 - Contributions de nos travaux</td><td>227</td></tr><tr><td>7.1.1. D'un point de vue de l'État de l'Art</td><td>228</td></tr><tr><td>7.1.2. D'un point de vue de l'Évolution d'objets</td><td>229</td></tr><tr><td>7.1.2.1. Le principe de l'évolution d'objets sous GENOME</td><td>229</td></tr></table>
<table><tr><td>7.1.2.2. Le principe de la modélisation sous GENOME</td><td>230</td></tr><tr><td>7.2 - Limites et Perspectives</td><td>231</td></tr><tr><td>7.2.1. Limites et perspectives par chapitre</td><td>231</td></tr><tr><td>7.2.2. Priorité des perspectives</td><td>234</td></tr></table>

<table><tr><td>Bibliographie</td><td>237</td></tr></table>
<figure><img src="image_2.png" /></figure>
LISTE DES FIGURES<fnref n="1" />

Figure 1-1: Classes Présage décrivant des caractéristiques de réseaux de télécommunications urbains. 28

Figure 1-2: une instance de la classe Cl-Réseau Urbain.2. de Présage et représentant un réseau urbain. 29

Figure 2-1: le Développement et l'Émergence : les deux processus d'évolution. 43

Figure 2-2: Les trois facettes de l'évolution d'objets. 44

Figure 2-3: première classification triptyque : stratégies d'évolution par modification. 59

Figure 2-4: Seconde classification triptyque des stratégies étudiées. 71

Figure 2-5: Principe Général d'un algorithme évolutionnaire. 75

Figure 2-6: les deux processus fondamentaux entre GTYPE et PTYPE 77

Figure 2-7: Le processus de sélection 80

Figure 2-8: croisement à un point 80

Figure 2-9: exemple d'un croisement à deux points. 81

Figure 2-10: la mutation d'un gène au sein d'un chromosome 81

Figure 2-11: Processus d'Évolution d'Objets sous l'optique de l'Évolution Artificielle 82

Figure 3-1: un exemple de modélisation des membres d'une université 89

Figure 3-2: relations entre GH et GS 95

Figure 3-3: Schème permanent de la classe Chercheur 98

Figure 3-4: le même exemple sous GENOME 99

Figure 3-5: Architecture du modèle Génome selon le formalisme d'UML 101

Figure 4-1: les processus d'évolution entre deux états stables du modèle. 110

Figure 4-2: Formalisme du diagramme Etats-Transitions d'UML 111

<footnote n="1">¹ Les figures sont identifiées par le **numéro de chapitre** et leur **ordre d'apparition séquentiel** dans ce même chapitre, ainsi que le **numéro de page** dans le manuscrit, sur le modèle : *Figure numChapitre-numFiguredansChapitre* et le **numéro de page**.</footnote>
<table>
  <tbody>
    <tr>
      <td>Figure 4-3: Les trois phases d'un processus d'évolution</td>
      <td>113</td>
    </tr>
    <tr>
      <td>Figure 4-4. Étapes de la phase d'Extraction</td>
      <td>126</td>
    </tr>
    <tr>
      <td>Figure 4-5. Étapes de la phase d'Exploration</td>
      <td>129</td>
    </tr>
    <tr>
      <td>Figure 4-6: adaptation des classes à O<sub>1</sub>.</td>
      <td>130</td>
    </tr>
    <tr>
      <td>Figure 4-7: adaptation des classes à O<sub>2</sub>.</td>
      <td>131</td>
    </tr>
    <tr>
      <td>Figure 4-8: adaptation des classes à O<sub>3</sub>.</td>
      <td>132</td>
    </tr>
    <tr>
      <td>Figure 4-9. Étapes de l'Émergence Locale</td>
      <td>139</td>
    </tr>
    <tr>
      <td>Figure 4-10. Étapes de l'Émergence Globale Directe.</td>
      <td>141</td>
    </tr>
    <tr>
      <td>Figure 4-11: prédominance d'un parent sur un enfant.</td>
      <td>144</td>
    </tr>
    <tr>
      <td>Figure 4-12: Transmission des gènes lors du croisement</td>
      <td>144</td>
    </tr>
    <tr>
      <td>Figure 4-13. Le croisement : cœur du processus d'émergence globale</td>
      <td>146</td>
    </tr>
    <tr>
      <td>Figure 4-14: le Développement et l'Émergence : les deux processus d'évolution.</td>
      <td>157</td>
    </tr>
    <tr>
      <td>Figure 4-15: Lien d'évolution</td>
      <td>159</td>
    </tr>
    <tr>
      <td>Figure 4-16: les liens d'évolution</td>
      <td>161</td>
    </tr>
    <tr>
      <td>Figure 4-17: Hiérarchie de classes et Graphes de Liens d'évolution.</td>
      <td>163</td>
    </tr>
    <tr>
      <td>Figure 5-1: démarche descendante de la technique GQM.</td>
      <td>176</td>
    </tr>
    <tr>
      <td>Figure 5-2: Insertion d'Enseignant-Chercheur dans la population de Membre-Université.</td>
      <td>198</td>
    </tr>
    <tr>
      <td>Figure 5-3: Hiérarchie de classes et Graphes de Liens d'évolution.</td>
      <td>199</td>
    </tr>
    <tr>
      <td>Figure 6-1: Présage: prise en charge de la dynamicité des classes dans C<sup>++</sup>.</td>
      <td>207</td>
    </tr>
    <tr>
      <td>Figure 6-2: Interactions Présage/Genome.</td>
      <td>208</td>
    </tr>
    <tr>
      <td>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.</td>
      <td>217</td>
    </tr>
    <tr>
      <td>Figure 6-4: résultat de l'évolution.</td>
      <td>218</td>
    </tr>
    <tr>
      <td>Figure 6-5: Évolution de la Va Max au cours des itérations du croisement.</td>
      <td>220</td>
    </tr>
    <tr>
      <td>Figure 6-6: Composition et association entre objets</td>
      <td>233</td>
    </tr>
  </tbody>
</table>
LISTE DES TABLEAUX<fnref n="2" />

Tableau 2-1: actions menées dans le déroulement de l'algorithme incrémental de la réorganisation. 50

Tableau 2-2: taxonomie des opérations et leur sémantique pour la réorganisation de classes. 51

Tableau 2-3: taxonomie détaillée des opérations de modifications 54

Tableau 2-4: taxonomie des opérations de modifications utilisées dans GemStone 55

Tableau 2-5: les opérations pour la migration de caractéristiques de classes 58

Tableau 2-6: opérations de base 64

Tableau 2-7: opérations avancées 65

Tableau 2-8: stratégies d'évolution par modification d'une hiérarchie de classes 66

Tableau 4-1: table de vérité de l'opérateur ∧. 119

Tableau 4-2: deux schèmes à comparer. 120

Tableau 4-3: les deux schèmes uniformisés. 120

Tableau 4-4: Classification des opérateurs objets 121

Tableau 4-5: Utilisation des opérateurs durant les phases des processus d'évolution. 122

Tableau 4-6: l'état initial des instances de l'exemple. 123

Tableau 4-7: les instances dans leur nouvel état. 124

Tableau 4-8: résultat de la phase d'extraction: les schèmes temporaires 127

Tableau 4-9: exploration de classes pour O₁. 130

Tableau 4-10: exploration de classes pour O₂. 131

<footnote n="2">² Les tableaux sont identifiés par le **numéro de chapitre** et leur **ordre d'apparition séquentiel** dans ce même chapitre, ainsi que le **numéro de page** dans le manuscrit, sur le modèle : *Tableau numChapitre-numTableaudansChapitre* et le **numéro de page**.</footnote>
<table><tr><td>Tableau 4-11: exploration de classes pour O<sub>3</sub></td><td>132</td></tr><tr><td>Tableau 4-12: exploration de classes pour O<sub>4</sub></td><td>133</td></tr><tr><td>Tableau 4-13: adaptation des classes à O<sub>4</sub></td><td>133</td></tr><tr><td>Tableau 4-14: exploration de classes pour O<sub>5</sub></td><td>134</td></tr><tr><td>Tableau 4-15: adaptation des classes à O<sub>5</sub></td><td>134</td></tr><tr><td>Tableau 4-16: résultats de l'exploration</td><td>135</td></tr><tr><td>Tableau 4-17: l'algorithme permettant d'exploiter, dans un premier temps, les résultats de la phase d'exploration</td><td>136</td></tr><tr><td>Tableau 4-18: Processus d'évolution pour chaque objet</td><td>138</td></tr><tr><td>Tableau 4-19: Les deux étapes de toute itération d'un croisement au travers d'un exemple</td><td>148</td></tr><tr><td>Tableau 4-20: la seconde génération est croisée</td><td>149</td></tr><tr><td>Tableau 4-21: troisième et dernière itération du croisement</td><td>149</td></tr><tr><td>Tableau 4-22: les étapes du croisement sur le schème temporaire représentant O<sub>5</sub></td><td>150</td></tr><tr><td>Tableau 4-23: calcul de la d.s pour chaque schème permanent ayant participé au croisement pour E4</td><td>153</td></tr><tr><td>Tableau 4-24: calcul de la d.s pour chaque schème permanent ayant participé au croisement pour E5</td><td>153</td></tr><tr><td>Tableau 4-25: calcul de la d.s pour chaque schème permanent ayant participé au croisement pour E5</td><td>154</td></tr><tr><td>Tableau 5-1: des exemples de métriques de contexte d'application</td><td>173</td></tr><tr><td>Tableau 5-2: des exemples de métriques de contexte de classe</td><td>174</td></tr><tr><td>Tableau 5-3: des exemples de métriques de contexte de fonction</td><td>175</td></tr><tr><td>Tableau 5-4: une première application de la technique GQM</td><td>178</td></tr><tr><td>Tableau 5-5: application approfondie de la technique GQM</td><td>181</td></tr><tr><td>Tableau 5-6: métriques inter-structures et invariants associés</td><td>190</td></tr><tr><td>Tableau 5-7: les deux schèmes émergents E4 et E5 pour O<sub>1</sub></td><td>192</td></tr><tr><td>Tableau 5-8: applications des métriques intra-structure pour les schèmes émergents de l'objet O<sub>1</sub></td><td>192</td></tr><tr><td>Tableau 5-9: application de la d.s sur le schème émergent de O<sub>1</sub></td><td>193</td></tr><tr><td>Tableau 5-10: Métriques inter-structures sur le schème émergent de O<sub>1</sub></td><td>194</td></tr><tr><td>Tableau 5-11: Métriques intra-structures sur le schème émergent de O<sub>5</sub></td><td>195</td></tr><tr><td>Tableau 5-12: application de la d.s sur le schème émergent de O<sub>5</sub></td><td>195</td></tr><tr><td>Tableau 5-13: Métriques inter-structures sur le schème émergent de O<sub>5</sub></td><td>196</td></tr><tr><td>Tableau 5-14: les structures conceptuelles émergentes</td><td>197</td></tr></table>
INTRODUCTION
## 1.1 - Cadre de l'étude

Les caractéristiques de l'approche objet telles que l'héritage, la composition, l'abstraction, le polymorphisme... permettent de modéliser des systèmes et de développer des applications de plus en plus robustes mais en même temps de plus en plus complexes, ce qui a immanquablement posé le problème crucial de l'évolution, de l'adaptation et de la maintenance de ces systèmes et de ces applications. Grâce à ces caractéristiques, l'approche objet est souvent vue comme l'approche par excellence rendant possible l'extension et l'adaptation d'un système en réutilisant le plus possible l'existant. Il est vrai que les méthodes d'analyse et de conception orientées objet contribuent au développement d'applications ouvertes mais restent malheureusement confrontées aux problèmes d'évolution de spécifications existantes et d'auto-adaptation. En effet, la plupart des stratégies d'évolution intègrent uniquement le concept d'évolution mais n'intègrent pas le processus d'analyse et de conception de l'évolution.

Il est connu que les besoins, aussi bien en termes de spécifications que d'évolution, peuvent être non identifiés ou mal définis. En effet, ces problèmes liés à l'évolution peuvent concerner un modèle et apparaître durant tout son cycle de vie (conception, utilisation, maintenance).

Les modèles à objets courants [Banerjee& 87], [Bratsberg 93], [Casais 91], [Kim& 88], [Nguyen& 89], UML [Rational 97], C++ [Stroustrup 96], Java [Sun 98] ... souffrent de manque de concepts pour prendre en compte les besoins et lacunes suscités mais en même temps disposent de puissants concepts (héritage, encapsulation, surdéfinition...) pour adresser de tels problèmes. Notre objectif est de répondre à ces insuffisances en proposant un modèle objet évolutif visant à :
- offrir à un concepteur un outil permettant de simuler l'évolution d'objets sur des applications existantes ;

- expliciter les différents processus d'évolution d'un objet aussi bien durant la conception que durant l'exploitation.

## 1.2 - Objectif : un Modèle pour la Simulation de l'Évolution d'Objets

Nous considérons que l'évolution d'objets peut aussi bien être abordée à partir des spécifications conceptuelles, donc des classes et de leur hiérarchie, qu'à partir des instances quand cela est utile. Nous proposons une approche complémentaire de l'évolution d'objets classique, qui est généralement axée sur l'évolution de classes. Pour permettre de faire face à des situations de changements imprévues dans le cadre d'applications d'ingénieries complexes et volumineuses, nous proposons à un concepteur un modèle d'évolution basé sur la simulation. Notre objectif est de rechercher et de dégager diverses voies d'évolution des structures conceptuelles à partir de l'évolution dynamique de la structure d'instances. Afin de ne pas provoquer de rupture dans le cycle de vie du système, nous permettons au concepteur d'exprimer directement de nouveaux besoins sur des instances, et de simuler diverses voies possibles d'évolution. Nous nous assurons que cette simulation reste cohérente avec les spécifications existantes. Le principe général sur lequel nous nous reposons est d'arriver à faire émerger des structures conceptuelles adaptées et plus complètes à partir des besoins ponctuels et des informations présentes dans la base. Nous permettons par la suite de choisir la structure la plus intéressante puis de détecter les endroits d'insertion et de changements dans le modèle de classes, et de cerner les impacts aussi bien au niveau du modèle de classes que sur les instances existantes. Le processus d'évolution que nous proposons s'appuie sur des processus de recherche de données plus ou moins adaptées au problème, d'extraction et de combinaisons de spécifications. Ceci fait l'objet en détails de ce manuscrit dans les chapitres 3, 4 et 5.

Nous abordons dans ce manuscrit notre approche de la problématique d'évolution d'objets, ainsi que les solutions que nous préconisons. Le manuscrit est organisé en chapitres. Voici son plan de lecture :
## 1.3 - Plan du manuscrit

Outre cette introduction, le manuscrit est organisé en six chapitres principaux, suivis d'une conclusion :

### 1.3.1. Chapitre 1 : Contexte de travail, motivations et hypothèses de travail

Dans ce chapitre, nous situons et décrivons le contexte initiateur de notre travail. Il s'agit d'un contexte de modélisation de réseaux de télécommunications. La description du contexte nous permet d'introduire, au vu d'un exemple illustratif, la problématique d'évolution d'objets à laquelle nous nous intéressons.

En effet, la problématique initiatrice de nos travaux est celle de l'évolution des réseaux de télécommunications face à des situations et des besoins d'évolution nouveaux. Ces situations et ces besoins peuvent ne pas être nouveaux mais peuvent être partiellement définis ou mal spécifiés.

Pour un concepteur, la gestion de tels besoins d'évolution est d'autant plus accrue que ces applications sont particulièrement volumineuses et complexes. Ce type de problèmes se rencontre dans tout type d'applications importantes, tel qu'en CAO par exemple. De plus, Le concepteur, qui a la charge de telles applications, a du mal à faire face à des évolutions imprévues ou mal cernées. La seule certitude dont dispose le concepteur est l'endroit ponctuel et local où il peut apporter des modifications, à savoir une ou plusieurs instances existantes.

Aussi, nous mettons en avant dans ce chapitre nos motivations : la problématique de l'évolution d'applications complexes et volumineuses face à des situations de changements imprévues nous conduit à aborder l'évolution à partir de l'évolution dynamique de la structure d'instances. Celles-ci permettent alors l'apparition de nouvelles structures conceptuelles : c'est l'Émergence.

Nous complétons ce chapitre en posant clairement nos différentes hypothèses de travail ainsi que quelques définitions que nous jugeons nécessaires, notamment celle de produit pour désigner toute structure conceptuelle (classe, attribut, lien, instance). Ces hypothèses de travail permettent de faciliter la compréhension au lecteur du manuscrit, et par conséquent la démarche de notre travail.

### 1.3.2. Chapitre 2 : État de l'Art

Nous consacrons ce second chapitre à l'état de l'art. Nous en consacrons la majeure partie à l'évolution d'objets. Nous consacrons la seconde partie à l'Évolution Artificielle car elle représente notre source d'inspiration pour quelques aspects, notamment l'idée de permettre l'évolution dynamique d'instances et d'en tirer profit.
Nous nous intéressons à plusieurs aspects dans la principale partie de l'état de l'art :

– Notre premier intérêt se porte sur la description de l'évolution d'objets par rapport à ses propres caractéristiques, que nous dénommons *facettes*. Nous définissons ainsi l'objet de l'évolution, le type de l'évolution et le processus de l'évolution. L'objectif est de décrire complètement l'évolution d'objets au travers de ses caractéristiques et de pouvoir classifier les stratégies d'évolution existantes par rapport à ces facettes. Nous définissons ainsi une représentation triptyque de l'évolution d'objets.

– Nous nous intéressons par la suite à une problématique particulière de l'évolution d'objets. Nous nous focalisons en effet sur la problématique de l'évolution du produit (aussi bien l'évolution de classes que l'évolution d'instances). Pour cela, nous nous intéressons aux principales stratégies d'évolution par modifications de classes, car elles présentent la même approche que la nôtre : celle de modifier directement les structures conceptuelles existantes. Nous rappelons pour chacune d'entre elles son principe, ses avantages et ses inconvénients.

– Pour pouvoir mieux comprendre leur fonctionnement et comparer les stratégies d'évolution par modifications de classes, nous élaborons une taxonomie d'opérations d'évolution. Nous proposons une taxonomie d'opérations de base et d'opérations avancées. Ces taxonomies non seulement dégagent les opérations d'évolution et leur séquencement pour les stratégies d'évolution étudiées, mais elles mettent également en évidence qu'elles ne suffisent pas à mener notre approche de l'évolution, celle de la simulation de l'évolution par l'évolution dynamique d'instances, c'est-à-dire l'Émergence de nouvelles structures conceptuelles.

– Nous présentons également des travaux connexes. Pour la plupart, il s'agit de stratégies d'évolution connues qui assurent l'évolution non pas par modification mais par dérivation. Toutes les stratégies étudiées sont situées par rapport aux facettes de l'évolution. D'autres travaux sont également cités. Il s'agit de divers travaux s'étant inspirés plus ou moins directement de travaux de l'Évolution Artificielle.

L'Évolution Artificielle est la partie qui clos ce chapitre de l'état de l'art. Nous présentons les principaux travaux qui nous ont inspirés dans certaines idées et certains concepts. Il s'agit des travaux de la Vie Artificielle et des Algorithmes Génétiques.

Les trois chapitres suivants se complètent et décrivent le modèle que nous proposons. Nous dénommons ce modèle GENOME pour *Génétique pour l'Evolution Objet et Modèle* ou encore *Genetic Evolution Object Model*. Le terme génétique est utilisé pour noter l'inspiration des Algorithmes Génétiques et de la Vie Artificielle pour traiter l'évolution d'objets face à des situations de changements imprévues.
### 1.3.3. Chapitre 3 : GENOME : les concepts

Nous présentons dans ce chapitre les concepts du modèle GENOME basé sur un modèle objet classique (classe/instance), enrichi de nouvelles notions et de nouveaux concepts nécessaires pour mener à bien nos objectifs.

Les concepts de GENOME sont de deux types :

- Les concepts de base qui véhiculent en fait les concepts objet de base (classe, instance, attributs, méthodes). Nous présentons ces concepts sous l'évocation 'génétique'. Ainsi, les concepts d'attribut et de méthode sont des caractéristiques élémentaires et nous les considérons comme des *gènes*. Ces gènes sont définis dans les classes qui jouent ainsi le rôle de *génotypes*. Elles permettent de créer des instances, qui sont ainsi des *phénotypes*, et forment ainsi une ou plusieurs *populations*.

- Les concepts avancés étendent les concepts de base, les enrichissent et les complètent. Nous montrons aussi que nous considérons différents types de gènes, chacun ayant un rôle et une prédominance précis. Ces concepts interviennent grandement dans les processus d'évolution, principalement le concept de *schème*.

Nous illustrons les concepts de modèle sur un exemple simple et didactique. Cet exemple revient dans les chapitres suivants également pour illustrer les différents concepts et notions que nous définissons.

Nous complétons ce chapitre en donnant la synoptique du méta-modèle pour prendre en compte l'évolution.

### 1.3.4. Chapitre 4 : GENOME : les processus d'évolution

Nous présentons dans ce chapitre les processus d'évolution du modèle GENOME. Nous définissons les deux principaux processus d'évolution du modèle GENOME : le *développement* et l'émergence. Afin de décrire un processus d'évolution, nous le définissons au travers de trois *phases* distinctes, par lesquelles passe tout processus d'évolution de GENOME.

Pour mener les étapes opératoires d'un processus d'évolution, nous définissons un certain nombre d'opérateurs que nous qualifions d'opérateurs *objets génétiques*, dont le plus important est le *croisement* qui permet l'émergence de nouvelles structures conceptuelles mieux adaptées aux nouveaux besoins.

Chaque phase d'un processus d'évolution est spécifiée de manière détaillée par un automate décrit grâce à des diagrammes d'états-transitions. Chaque cas d'évolution est illustré par au moins un exemple. Une discussion achève cette partie.

La dernière partie de ce chapitre présente le concept du *lien d'évolution*. Il s'agit d'un lien qui est spécifié entre deux classes après qu'une évolution aura été menée à terme. Il permet ainsi de *capitaliser* toute nouvelle évolution. Il permet ainsi au modèle de pouvoir réagir et répondre si une telle situation d'évolution survient à nouveau.
### 1.3.5. Chapitre 5 : GENOME : les métriques pour contrôler l'émergence

Nous présentons dans ce chapitre le contrôle de l'émergence dans GENOME. Nous proposons d'utiliser des métriques. Nous rappelons l'introduction des métriques dans l'approche objet et présentons quelques métriques objet standards. Nous présentons par la suite une technique, la technique GQM, que nous utilisons pour détecter avec précision à quels endroits d'un processus d'évolution une métrique peut être utile.

Nous proposons deux catégories de métriques. La première permet de mesurer certaines caractéristiques de la constitution interne d'une structure conceptuelle émergente et pour permettre de détecter d'éventuelles anomalies. La seconde catégorie de métriques permet de mesurer certains critères d'une structure conceptuelle émergente par rapport à la hiérarchie de classes existantes. Nous montrons également que l'utilisation des métriques peut parfois obéir à des exigences du concepteur. Nous dénommons ces exigences comme étant des *invariants*.

### 1.3.6. Chapitre 6 : Implémentation

Ce chapitre présente les parties du modèle ayant fait jusqu'à présent l'objet d'une implémentation. Nous présentons avant tout le projet Présage qui permet de modéliser les réseaux de télécommunications. En effet, le modèle proposé doit s'intégrer comme une nouvelle fonctionnalité pour gérer l'évolution des réseaux de télécommunications par simulation que le concepteur pourra mener. Ce chapitre met en évidence les étapes du développement et les raisons des choix faits. Il met également en évidence les limites et les extensions nécessaires à apporter.

### 1.3.7. Conclusion : Contributions et Perspectives

Enfin, ce chapitre conclue notre présent manuscrit. Il rappelle les contributions de nos travaux mais met également en évidence les limites et les quelques perspectives d'ouvertures.
# Chapitre 1 : CONTEXTE DE TRAVAIL, MOTIVATIONS ET HYPOTHESES DE TRAVAIL
# 1.1 - Introduction

L'intérêt suscité par l'approche objet depuis une trentaine d'années dans différents domaines (Bases de Données [Kim& 90], Conception Assistée par Ordinateur [Orel& 95], Méthodes de Conception de Systèmes d'Information [Coad 90], Intelligence Artificielle [Haton& 91]) a permis le développement de systèmes et d'applications de plus en plus robustes mais en même temps de plus en plus complexes. Cette expansion a immanquablement posé le problème crucial de l'évolution, de l'adaptation et de la maintenance de ces systèmes et de ces applications. De par les caractéristiques d'abstraction et de modularité, l'approche objet est considérée comme étant celle qui se prête le mieux à la gestion de la complexité, à l'extension et à l'adaptation des systèmes en réutilisant le plus possible les spécifications existantes. Pourtant, les résultats obtenus en pratique montrent que les systèmes modélisés et les applications développées ont une faible flexibilité et des difficultés d'adaptation.

En effet, l'expérience et le recul acquis aujourd'hui dans le développement de systèmes et d'applications objets permettent de cerner certaines de leurs lacunes. Parmi elles, celles qui reviennent à l'écart non comblé entre la réalité et le modèle objet qui en est abstrait :

- La réalité est souvent empreinte de nuances ; un modèle objet est impératif et strict : les données de la réalité ne se prêtent pas toujours à une modélisation selon une classification aux structures pré-établies. En raison de la variété des mécanismes proposés par les langages orientés objets, les meilleurs choix à faire pour modéliser la réalité en termes de classes ne sont pas évidents à faire. De plus, la modélisation objet s'appuie lourdement sur le mécanisme d'héritage qui porte plusieurs significations (héritage de code, spécialisation, partage de propriétés et de code, application de contraintes...). Il n'est pas évident de dégager et d'exprimer la sémantique souhaitée par le concepteur. Souvent dans le contexte réel, les représentants d'une même entité
réelle ne partagent pas forcément les mêmes caractéristiques. Ils peuvent varier, dans une certaine mesure, dans leurs propriétés et leurs comportements. Pour distinguer de telles différences au niveau de la modélisation, il n'y a pas d'autre issue que de développer autant de sous-classes que nécessaire. Cette action conduit inévitablement à la construction d'importantes hiérarchies de classes. Cette rigidité devient alors une contrainte et pénalise drastiquement les applications : les classes obtenues ne reflètent pas la réalité du système ainsi abstrait. Cette contrainte se fait particulièrement ressentir dans les nouvelles applications d'ingénierie (CAO, Multimédia, librairies digitales, ...) où les objets manipulés présentent la particularité de ne pas être facilement modélisés avec les concepts classiques du paradigme objet.

— Les besoins peuvent être non identifiés ou mal définis ; les spécifications conceptuelles sont établies de façon fixe : sauf si elles sont modifiées explicitement pour s'adapter. Les problèmes liés à l'évolution peuvent aussi bien concerner un modèle en phase de conception qu'en phase d'utilisation et de maintenance. Dans le premier cas, le modèle peut souvent être instable et partiellement défini, nécessitant une spécification incrémentale. Dans le second cas, il peut être revu et reformulé durant son exploitation et sa maintenance. Sa stabilité et son entière spécification passent alors par divers processus de validation. Ces processus peuvent être stratégiques (changements de besoins, de stratégie de conception, ...) ou purement techniques (tests et vérifications).

Nous verrons dans la section qui suit un cas d'applications concernées par ces problèmes :

## 1.2 - Contexte du travail : Modélisation des réseaux de télécommunications

Nous présentons dans cette section le contexte à partir duquel le présent travail a été initié. Le contexte est celui d'un système de planification de réseaux de télécommunications. Les besoins sont des besoins d'évolution de ces réseaux. Nous présentons par la suite la problématique d'évolution et nous soulignerons que la problématique ne concerne pas uniquement ce type de système, mais tous les systèmes à objets manipulant de grandes bases d'objets.

### 1.2.1. Le projet Présage

Le système Présage est un outil d'aide à la planification de réseaux de télécommunications [Caminada 92, Talens 94]. Il s'appuie sur une modélisation objets des réseaux de télécommunications. Un des principaux besoins est la maintenance et l'évolution de ces réseaux. En effet, une fois qu'ils sont modélisés, ils doivent pouvoir évoluer pour prendre en compte les nouvelles technologies, ainsi que les nouveaux
besoins et problèmes qui leur sont associés. Nous pouvons considérer que les besoins d'évolution se départagent en deux catégories :

– Les besoins connus à l'avance et pouvant être intégrés dans le cadre des spécifications conceptuelles. L'évolution est donc prise en compte et peut être menée à bien lorsque le besoin se présente. Les travaux de [Talens 94] et [Urtado 98] ont été développés dans ce cadre et se basent sur des stratégies d'évolution telles que le versionnement ;

– Les nouveaux besoins imprévus, les besoins mal ou faiblement définis. Généralement, le système ne peut pas réagir à ces situations, et il peut connaître une conjoncture de rupture dans son cycle de vie. Il est souhaitable d'éviter ce type de problèmes. Nous nous intéressons à ce type de problèmes de l'évolution.

Dans ce chapitre, nous présentons les caractéristiques des réseaux de télécommunications ainsi que leur modélisation dans le cadre de Présage. Par la suite, nous expliquons les besoins que peut rencontrer un concepteur chargé de la maintenance et de l'évolution dans le cadre du fonctionnement des modèles de réseaux de télécommunications. L'énumération de ces besoins nous amènera alors à une problématique plus large, aux motivations et aux objectifs de ce travail ainsi qu'à préciser également nos hypothèses de travail.

### 1.2.2. L'évolution dans les réseaux de télécommunications

Le domaine des Télécommunications [Peyrade 87] se caractérise par la complexité et l'évolution rapide des besoins en communication et des technologies utilisées. La planification des réseaux de télécommunications consiste à calculer l'évolution d'un réseau initial vers un état final. Cette évolution doit satisfaire un certain nombre de contraintes dues d'une part, à l'état initial du réseau et d'autre part, aux nouvelles exigences de transmission : contraintes techniques dues aux équipements utilisés, règles d'ingénierie, contraintes économiques reflétant la politique générale suivie quant à l'évolution globale du réseau... Les calculs sont effectués sous la forme de séries d'exécution de programmes de planification qui font évoluer la structure du réseau et le flot de données que le réseau supporte [Talens 94].

Les difficultés de modélisation et de gestion de l'évolution des réseaux de télécommunications viennent de :

– leur *complexité* : un réseau est composé de nœuds et d'arêtes et un nœud et/ou une arête peut se décomposer en plusieurs nœuds et arêtes ;

– la *grande quantité* et la *grande diversité* d'informations qu'ils contiennent et qu'il faut gérer ;

– la *diversité* des types de réseaux à traiter ;

– l'évolution rapide de la technologie de télécommunications : les réseaux évoluent, il faut donc pouvoir prendre en compte cette évolution. Les nouveaux réseaux sont utilisés pour des études futures.
### 1.2.3. Modélisation des réseaux de télécommunications et illustration par un exemple

Dans le cadre des projets initiateurs de Présage [Caminada 92] et au vu des besoins et objectifs respectifs, les réseaux de télécommunications sont modélisés dans Présage sur les bases suivantes :

- Une classe représente un modèle d'applications de réseaux. Elle décrit principalement les différents types d'éléments utilisés pour modéliser un type donné de réseaux (urbain, longue distance...). Elle comporte notamment les différents types de nœuds et d'arêtes. Une classe décrit par exemple les différents types d'éléments utilisés dans un réseau urbain ;

- Une instance d'une classe est un graphe représentant un réseau de télécommunications. Ce graphe est créé en utilisant les différents types d'éléments décrits dans la classe. Une instance représente par exemple la structure d'un réseau urbain donné aussi bien dans sa configuration spatiale que dans sa composante matérielle.

Considérons les classes décrivant des caractéristiques de réseaux urbains :

<figure><img src="image_3.png" /><figcaption>Figure 1-1: Classes Présage décrivant des caractéristiques de réseaux de télécommunications urbains.</figcaption></figure>

La première classe, **Cl-Réseau Urbain**, permet de définir des graphes de réseaux constitués de nœuds de type **MIE-STM1** reliés entre eux avec des arêtes de type **Anneau-STM1**. La seconde classe, **Cl-Réseau Urbain.2**, qui spécialise la première, définit des arêtes de type **Arête-Système**, en plus de ceux définis dans sa super-classe.

La Figure 1-2 illustre une instance de la classe **Cl-Réseau Urbain.2** et donne la configuration suivante d'un réseau de télécommunications urbain :
<figure><img src="image_4.png" /><figcaption>Figure 1-2 : une instance de la classe Cl-Réseau Urbain.2. de Présage et représentant un réseau urbain.</figcaption></figure>

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**. Le réseau urbain, représenté par cette instance, est donc constitué de composants dont le type est décrit 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.

La problématique d'évolution de ces réseaux dans leur modélisation est abordée dans la section suivante :

## 1.3 - Problématique

Nous abordons dans cette section un aspect particulier des besoins d'évolution auxquels un concepteur d'applications de réseaux de télécommunications est confronté, à savoir les besoins d'évolution inconnus, mal ou pauvrement spécifiés. Nous illustrons ce type de besoins par un exemple avant d'exprimer cette même problématique en termes de modélisation objet.

### 1.3.1. Problématique du concepteur

La problématique initiatrice du travail se résume comme suit. Le concepteur a la charge de la gestion, la manipulation et la planification des réseaux modélisés dans la
base. Plusieurs données lui parviennent ayant trait plus ou moins directement aux différents types de réseaux. Elles peuvent porter sur des contraintes techniques, des règles d'ingénierie, des contraintes économiques, des études de planification.... L'analyse de ces données lui révèle, par exemple, que certains réseaux urbains risquent d'arriver à saturation. C'est une situation courante. Dans le cadre de la planification, il est crucial d'anticiper ce genre de problèmes. Les réseaux peuvent nécessiter d'être modifiés dans leur structure et/ou dans les types de composants (nœuds et/ou arêtes) pour être plus adaptés à la conjoncture.

La plupart des besoins d'évolution sont soit nécessaire pour faire face à un problème qui se présente et qu'il faut de suite prendre en charge, soit pour anticiper justement les problèmes de saturation, les problèmes d'économie ou de sécurisation de réseaux existants. Cette anticipation nécessite un travail de planification, dans le cadre duquel le concepteur souhaite pouvoir simuler diverses évolutions possibles de réseaux, pouvoir comparer les différents résultats et pouvoir choisir la plus adéquate au vu des contraintes et des acquis.

En résumé, dans le cadre de l'évolution des réseaux de télécommunications, le concepteur désire pourvoir manipuler la structure des réseaux, c'est-à-dire :

- ajouter, enlever ou modifier des nœuds et/ou arêtes et des types de nœuds et/ou arêtes, tout en respectant leurs contraintes spécifiques ;

- chercher diverses combinaisons et les évaluer ;

- pouvoir choisir parmi les modèles de réseaux dégagés ;

- intégrer les plus adaptés dans la base existante.

Nous avons utilisé la terminologie propre à la modélisation des réseaux de télécommunications pour décrire la problématique et le contexte réel de travail d'un concepteur d'applications pour situer ses besoins et leur importance. Il s'agit pour nous d'exprimer et de projeter la problématique du concepteur en termes de problématique d'évolution de modèles à objets.

### 1.3.2. Problématique sous l'angle de vue de la modélisation et de l'évolution d'objets

Pour répondre aux besoins sus-cités, il est nécessaire de porter les modifications nécessaires au niveau de la classe, principalement pour modifier les types de composants. En soit, l'opération est certes lourde et coûteuse, mais elle s'avère nécessaire. Le concepteur explique qu'il prendrait malgré tout le parti de l'appliquer s'il pouvait déterminer sans ambiguïté l'emplacement des changements à apporter au niveau des spécifications existantes. Or, les modifications apportées peuvent s'avérer inadéquates, et qu'il n'est par conséquent pas approprié d'intégrer dans la base. Les modifications auront été non seulement coûteuses en termes de temps, de réorganisation et mises à jour de la base, et de blocage d'accès, mais elles auront été également inutiles. Le besoin d'évolution n'aura finalement pas été résolu et il y aurait eu en sus beaucoup de pertes.
Dans le cadre de la planification de ce type d'applications, il est nécessaire de pouvoir simuler, voire parfois tâtonner, en expérimentant des changements aussi bien sur la dimension spatiale que sur la dimension composante d'un réseau, puis observer et retenir les meilleures structures. Une fois cette sélection faite, les structures retenues peuvent être intégrées de manière durable dans la base en qualité d'un modèle de réseaux nouvellement admis.

### 1.3.3. Conclusion

Ce type de besoins d'évolution n'est pas le propre des applications de télécommunications, mais peut s'appliquer à tous les domaines de modélisation manipulant des applications orientées-objet complexes et volumineuses et connaissant des besoins importants d'évolution. A titre d'exemple, nous citerons le domaine de la CAO (Conception Assistée par Ordinateur). En effet, la marge de nouvelles conceptions en CAO est de l'ordre de 20% alors que le reste des efforts s'inscrivent dans le cas de reconception et donc d'adaptation par évolution de projets de conception existants, soit l'évolution et l'adaptation de modèles existants [Harani 97]. Les instances en CAO peuvent modéliser des objets en cours d'élaboration : elles sont alors soit incomplètes, temporairement incohérentes, multi-représentées et dépendantes fonctionnellement ou existentiellement d'autres instances [Rieu 99]. D'autres travaux se sont également intéressés à la problématique de l'évolution d'applications volumineuses et complexes dans la composante particulière que sont les relations. Dans [Rashid& 99], les auteurs s'intéressent à l'évolution dynamique de tous les types possibles de relations au sein d'un modèle à objet.

Nous développons dans la section qui suit notre approche d'une telle problématique d'évolution :

## 1.4 - Approche de la problématique

La problématique du concepteur dans un domaine d'ingénierie, comme nous l'avons vu, n'est pas typique uniquement de la planification des réseaux de télécommunications, mais elle s'étend et se justifie pour toutes les applications orientées-objet complexes et volumineuses.
1.4.1. Nos motivations : faire face à des situations imprévues de
changements

Un système orienté objet dit évolutif doit garantir la cohérence, la consistance et la pertinence des informations modélisées. Le processus d'évolution doit être harmonieux et doit éviter au maximum l'introduction d'incohérences et une refonte inutile dudit système. En effet, les problèmes liés à l'évolution se posent tout au long du cycle de vie des modèles et des applications. Ils peuvent aussi bien concerner un modèle en phase de conception qu'en phase d'utilisation et de maintenance. Pour gérer l'évolution d'applications d'ingénierie, un concepteur dispose d'un grand nombre de stratégies. Elles diffèrent dans la manière de gérer l'évolution suivant les buts et les besoins mais elles ont pour point commun de s'appliquer sur les schémas de classes et les classes. Un concepteur peut utiliser, selon ses besoins, une ou plusieurs de ces stratégies, à condition d'avoir cerné tous les besoins durant la phase d'analyse et de les avoir intégrés dans la phase de conception.

Tant qu'une application rencontre des besoins prévus, son cycle de vie ne connaît pas
ou peu de perturbations importantes. Par contre, lorsque de nouveaux besoins
apparaissent, qu'ils soient mal spécifiés ou nouvellement identifiés, le concepteur doit
les intégrer dans les spécifications de classes. Dans le cadre d'applications d'ingénierie
présentant d'importants graphes de classes avec des bases volumineuses d'objets, le
problème de l'évolution, de l'adaptation et de la maintenance se pose de manière
cruciale. Les besoins d'évolution sont souvent imprévus, mal définis ou mal anticipés
et leur intégration s'avère être une tâche particulièrement délicate. Étant donné le
volume important de données, le concepteur n'arrive pas toujours à avoir une vision à
la fois globale et détaillée de l'application. Il peut alors rencontrer de grandes
difficultés pour détecter à quel endroit du graphe de classes et sur quelle partie des
spécifications (bout de schéma, classe(s), lien(s)...) il doit apporter les modifications. Il
aura de plus grandes difficultés à anticiper et à évaluer les impacts, peut être
préjudiciables, de ces modifications. Son unique certitude réside dans les changements
nécessaires à apporter à son application pour répondre à un problème donné. Ces
changements sont en général mieux perçus au niveau de l'application, donc des
instances. Malheureusement, la dualité entre les concepts de classe et d'instance ne le
permet pas. Les spécifications conceptuelles prédominent et dirigent, souvent
pleinement, l'évolution. Ceci explique que la plupart des stratégies d'évolution ont été
développées pour gérer l'évolution de classes et de schémas de classes ainsi que leurs
impacts sur les instances mais uniquement comme conséquence.

A notre connaissance, peu de stratégies (à titre d'exemple, les travaux décrits dans
[Li& 94] au chapitre 2) permettent de gérer l'évolution d'instances avec des impacts sur
les classes. Aussi, lorsqu'un concepteur doit faire évoluer une base importante d'objets,
il dispose uniquement d'outils de la première catégorie. Pourtant, l'expérience montre
[Li& 98], [Price 97] que le plus souvent, les nouveaux besoins ou les besoins mal définis
apparaissent durant la manipulation d'applications, donc des instances.
Notre approche de la problématique se base sur la manière dont nous proposons de considérer les instances :

### 1.4.2. Reconsidérons les instances

L'évolution d'une instance passe généralement par celle de ses classes génératrices. La gestion de l'évolution des classes a pris le pas sur celle des instances qui leur restent conformes, au point où cette règle est ressentie, dans certaines situations, comme étant une contrainte. A la base, le concept de *classe* a été introduit pour spécifier une structure et un comportement communs à un ensemble d'objets (appelés instances de la classe) qui modélisent des entités réelles. Or, ces dernières ont une grande capacité d'évolution, ce qui n'est pas le cas de leurs représentants objets. En effet, certaines applications nécessitent des données nouvelles qui n'ont pas été spécifiées au niveau des classes et qui gagneraient à être prises en compte directement au niveau des instances.

Comment ? En considérant les instances, en tant que représentantes d'entités réelles, comme des *individus* à part entière. Une instance a donc connaissance de ses propres spécificités, et surtout permet l'acquisition de nouvelles connaissances plus adaptées à son nouvel environnement. Elle peut ainsi s'adapter et faire remonter au niveau conceptuel non seulement des données mais également une voie possible d'évolution pour les instances issues de la même classe.

Cette manière de considérer les instances induit de facto l'analogie avec des individus tels qu'ils sont considérés dans le cadre des travaux de l'Évolution Artificielle ([Holland 75], [Heudin 94], [Goldberg 94] ...), du moins dans certaines de leurs propriétés : celles d'évoluer dans leur environnement en s'y adaptant. Une adaptation d'un individu ne se cantonnera pas à lui seul mais sera répercutée dans son espèce en modifiant son code génétique. Cet individu fera ainsi profiter de son évolution sa population et sa progéniture.

### 1.4.3. Notre contribution : un modèle pour la simulation d'évolution

Compte tenu que l'évolution de classes a été largement traitée dans la littérature [Banerjee& 87], [Bratsberg 93], [Casais 91], [Nguyen& 89], [Kim& 88], [Oussalah& 99] ..., notre approche de l'évolution se veut complémentaire car notre intérêt se porte essentiellement sur l'évolution d'instances. Elle nous paraît en effet cruciale dans le développement et l'exploitation d'applications réelles. Le modèle d'évolution que nous proposons doit prendre en compte des besoins non ou mal anticipés en permettant à un objet d'évoluer par lui-même à partir de l'information qu'il détient mais aussi qu'il peut retrouver et déduire, minimisant ainsi l'intervention externe du concepteur (celle-ci devient essentiellement stratégique), en proposant la création de nouvelles structures conceptuelles.
Pour ce faire, nous proposons d'étendre l'évolution d'instances de la simple modification de leurs valeurs à la modification de leur structure (ajout / retrait d'attributs) selon les besoins qu'exprimerait directement le concepteur sur l'instance. Nous étudions également les processus d'évolution d'un modèle à objets de manière à lui permettre de s'adapter par lui-même lorsqu'un changement s'opère.

## 1.5 - Hypothèses de travail

Nous regroupons dans cette section les principales hypothèses de travail :

- Nous nous intéressons à l'évolution d'un modèle à objets à partir de l'évolution dynamique de la structure d'instances existantes. Notre objectif est de dégager plusieurs structures conceptuelles au vu de ces évolutions d'instances. Pour cela, nous nous intéressons uniquement à l'évolution de structures. Nous utilisons donc le terme de **'structure conceptuelle'** pour désigner toute entité constituée d'un ensemble d'attributs. Nous pouvons ainsi avoir des structures conceptuelles existantes, à savoir les attributs définis dans une classe ; des structures conceptuelles émergentes de l'évolution d'instances ; des structures conceptuelles véhiculées par des instances qui évoluent, et qui peuvent ne plus être conformes aux structures conceptuelles de classes existantes.

Toutefois, lorsque l'expression **'structure conceptuelle'** est trop lourde dans la formulation d'un paragraphe, nous parlerons alors tout simplement de **'structure'**.

- Nous ne traitons pas de l'évolution du comportement des instances. Nous ne nous intéressons donc pas à l'évolution des méthodes, du moins pas de manière directe. Une partie de la gestion des méthodes est une conséquence de l'évolution de structures conceptuelles. Faire évoluer une instance dans sa structure revient à ajouter, enlever ou modifier un attribut. Le seul contrôle que nous pouvons faire sur les méthodes est de vérifier que l'attribut est manipulé par des méthodes. Nous ne pourrons contrôler que les paramètres de la signature. Il en est de même pour les attributs retirés de la structure d'une instance. Le contrôle que nous proposons s'applique uniquement sur la signature des méthodes. Nous ne contrôlons pas le corps des méthodes.

- Il est important de souligner que nous considérons les choix de conception initiaux comme étant corrects. L'évolution se base sur les spécifications existantes, et elle ne cherche pas à vérifier la cohérence et la complétude de la conception établie. Par contre, si des contradictions apparaissent entre les propositions d'évolution et les spécifications existantes, celles-ci sont signalées et peuvent par conséquent être prises en compte pour réviser les choix de conception initiaux.

- Nous utilisons indifféremment les termes **'objet'** et **'instance'** tout au long du présent manuscrit. De plus, lorsque nous parlons de **'propriété'**, il s'agit indifféremment d'attribut ou de méthode.
## 1.6 - Conclusion

Dans le cadre de besoins d'évolution d'applications orientées objet complexes et volumineuses, nous nous intéressons à la possibilité de prendre en compte et d'intégrer au mieux les besoins imprévus ou mal définis lorsqu'ils apparaissent tout au long du cycle de vie. L'ensemble des besoins change en raison de la nature instable des nécessités des applications pour répondre aux attentes.

### Cycle de vie : Besoins -> Conception -> Implémentation

Nous considérons que les besoins de changements sont de deux catégories :

1. Les besoins d'évolution qui sont perçus lors de la phase d'analyse et sont pris en compte lors de la phase de conception ;

2. Les besoins d'évolution imprévus, faiblement ou mal spécifiés qui s'imposent durant le cycle de vie des applications.

Il est difficile d'évaluer la part d'importance de chacun des deux types de besoins, mais le second cas de figure est loin de représenter des situations exceptionnelles ; bien au contraire. Les deux catégories de besoins peuvent concerner tous les niveaux des applications :

- *Conceptuel* : schéma de classes (mettant en jeu les différents liens d'héritage, d'associations, de composition...) et classes (les attributs dans leur définition, leur type et les méthodes dans leur nom, leur signature et leur corps).

- *Implémentation* : les instances (création, attribution de valeurs) et les programmes.

Pour gérer les besoins d'évolution, une multitude de stratégies ont été définies et développées ([Banerjee& 87], [Bancilhon& 88], [Bertino 92], [Borgida 88], [Bratsberg 93], [Casais 91], [Clamen 94], [Kim& 90], [Nguyen& 89], [Zdonik 90] ...). Certaines ont été particulièrement utilisées et le sont toujours. Elles ont également inspiré bon nombre d'autres stratégies. Les stratégies d'évolution s'accordent sur certains points, dont bien sûr celui de gérer l'évolution, et diffèrent sur bon nombre d'autres points, et qui concernent :

- Le domaine de recherche et d'application (Intelligence Artificielle, Génie Logiciel, BDOO...);

- La politique d'évolution adoptée (garder l'historique, dériver les propriétés,...);

- Les niveaux sur lesquels s'appliquent les changements (classes - liens - instances - programmes);
- Les concepts manipulés ainsi que les concepts et processus proposés pour
supporter l'évolution.

Nous remarquons que les aspects traités ainsi que la façon dont ils sont traités rendent
toutes les stratégies difficiles à appréhender d'une façon identique, ce qui rend leur
comparaison difficile.

Nous abordons dans le chapitre suivant l'état de l'art sur l'évolution d'objets.
# Chapitre 2 : ÉTAT DE L'ART

<figure><img src="image_5.png" /></figure>
## 2.1 - Introduction

Nous abordons l'évolution orientée objet dans le présent chapitre en deux principales parties :

1. l'évolution d'objets décrite dans ses caractéristiques et les stratégies d'évolution vues selon ces mêmes caractéristiques ;

2. le positionnement de notre approche de la problématique de l'évolution aussi bien par rapport à l'évolution d'objets qu'à l'évolution artificielle.

La première partie a pour but de positionner, de définir et de décrire l'évolution d'objets dans ses caractéristiques que nous dénommons *facettes*. Ensuite, nous montrons comment situer toute stratégie d'évolution par rapport à ces facettes. Selon la facette abordée, les stratégies se positionnant sur celle-ci, peuvent être comparées entre elles. Nous considérons que cette manière d'aborder l'évolution d'objets a pour principal avantage de mettre en évidence tous les aspects de l'évolution, et de positionner une stratégie par rapport à un référentiel commun et indépendant, et non par rapport à une autre stratégie.

Ce chapitre se termine en abordant toujours l'évolution mais cette fois dans le cadre des travaux de l'Évolution Artificielle, car nous nous sommes inspirés de certains principes et de quelques concepts de ces travaux pour proposer l'évolution d'objets à partir de l'évolution dynamique de structures d'instances.
## 2.2 - Les trois facettes de l'Évolution d'Objets

### 2.2.1. Introduction

La problématique de l'évolution dans les systèmes à objets concerne plusieurs domaines d'activités : la Conception Assistée par Ordinateur, le Génie Logiciel, l'Intelligence Artificielle, les Systèmes d'Information, les Interfaces Homme-Machine, les Bases de Données ainsi que les domaines de l'Ingénierie. De cette diversité de domaines, divers travaux ont été issus du monde de la recherche et de l'industrie. Ils définissent des systèmes et des langages de programmation à objets proposant des stratégies et des mécanismes pour gérer l'évolution. L'expérience a montré, aussi bien au niveau de la conception que celui du développement, les limites des approches évolutives actuelles. Les stratégies d'évolution existantes sont diverses et variées et ne répondent que partiellement aux besoins.

De façon générale, pour préparer un système ou une application à l'évolution, il est nécessaire de pouvoir :

a) Formuler les changements afin d'atteindre l'objectif visé (le modèle d'arrivée, à savoir le modèle ayant évolué).

b) Gérer l'impact engendré par ces changements.

c) Établir le lien entre le modèle de départ et le modèle d'arrivée.

Plutôt que de classifier quelques stratégies d'évolution en prenant comme repère des critères qui leur sont communs mais qui ne sont pas exhaustifs, nous proposons une classification reposant sur les critères propres à l'évolution. Cette classification présente un double avantage : celui de cerner les aspects traités de ceux non ou peu traités de l'évolution, et celui de pouvoir positionner les principales stratégies d'évolution existantes par rapport au même référentiel.

### 2.2.2. Les trois facettes de l'évolution d'objets

Avant de pouvoir choisir quelle approche adopter, voire quelle stratégie adopter, pour gérer l'évolution d'un modèle à objets, il est important avant tout de connaître le contexte de travail. Le choix d'une stratégie à adopter doit venir en aval. Les aspects qui nous paraissent importants dans l'évolution sont introduits sous forme d'interrogations :

- Sur quoi porte l'évolution, autrement dit quel est l'objet de l'évolution : l'aspect statique ou l'aspect dynamique ?

- Comment est gérée l'évolution ? Les besoins doivent-ils être impérativement pris en compte lors de la phase d'analyse et spécifiés lors de la phase de conception pour assurer l'évolution ? Ou alors, peuvent-ils survenir ou se préciser tout au long du cycle de vie et l'évolution est malgré tout assurée ?
– A quel(s) niveau(x) de l'application sont effectués les changements et vers quels autres niveaux sont propagés les impacts ?

De ces trois questions fondamentales, il nous apparaît que les trois principaux aspects devant être explicités lorsque l'évolution d'objets est abordée sont :

1- L'Objet de l'évolution ;

2- Le Type de l'évolution ;

3- Le Processus d'évolution.

Nous dénommons ces aspects les *facettes* de l'évolution. Nous les définissons comme suit :

### 2.2.2.1. Objet de l'Évolution

L'évolution peut porter sur un *produit* ou sur un *processus* :

– Nous entendons par *produit* tout élément structurel qui s'intègre directement dans le modèle en cours de conception. Ces éléments sont considérés comme passifs et peuvent être composés, généralement par le concepteur, entre eux grâce à différents liens. Dans l'approche objet, ces éléments peuvent être simples, tels que les attributs, ou complexes, telles que les classes et les instances. Ils peuvent être encore plus complexes tel qu'un schéma de classes dans lequel les classes sont connectées entre elles par des liens d'héritage, d'association ou de composition. Ces éléments sont également nécessaires pour définir des structures plus complexes tels que des domaines d'applications. Pour notre part, nous nous cantonnons aux hiérarchies de classes, les classes, les liens (d'héritage, d'associations, de composition), les instances et les attributs et méthodes.

– Nous entendons par *processus* tout fragment de démarche ou de raisonnement pouvant être exécuté à chaque utilisation. Dans l'approche objet, ces fragments sont généralement décrits sous forme modulaire. Ils peuvent être simples (la construction syntaxique d'un langage de développement), plus élaborés (des sous-programmes, des fonctions, des packages). Ils peuvent être organisés de manière plus complexes, telles que dans des bibliographies de fonctionnalités, et ils peuvent même définir des infrastructures logicielles (frameworks), fournissant ainsi des canevas pour le développement de familles d'applications [Cauvet& 99].

### 2.2.2.2. Type de l'Évolution

Nous considérons qu'il existe deux cas de figures :

– *L'Évolution Préventive* : l'évolution peut être assurée pour les besoins d'évolution pris en compte lors de la phase d'analyse et spécifiés lors de la conception. Il s'agit de besoins qui sont identifiés et cernés dès le début. Dans ce cas, l'évolution est dite préventive ou anticipée. Au vu des trois conditions citées en §2.2.1 pour mener à bien
l'évolution, il y a des situations ou la condition c) n'est pas vérifiée (soit parce qu'elle est impossible à établir ou parce qu'elle n'est pas nécessaire). Aussi :

- L'évolution préventive est dite *avec rupture* si cette condition c) n'est pas vérifiée, c'est-à-dire que le lien ne peut pas être établi entre le modèle *avant* son évolution et *après* son évolution.

- L'évolution préventive est dite *continue* si au contraire, la même condition c) est vérifiée et assurée, c'est-à-dire que le lien peut être établi entre le modèle *avant* son évolution et *après* son évolution.

– L'Évolution Curative : l'évolution peut être assurée pour les besoins nouveaux qui apparaissent de façon imprévue durant le cycle de vie, ou lorsque des besoins ont été mal ou peu spécifiés et que la conjoncture permet enfin de les enrichir ou de les corriger et surtout d'être en mesure de les prendre en compte en les intégrant. Dans ce cas, l'évolution est dite *curative* ou *non-anticipée*.

### 2.2.2.3. Processus d'Évolution

L'évolution de systèmes et d'applications orientés objet est le plus fréquemment menée à partir de celle des spécifications conceptuelles, donc des classes. Aussi, nous distinguons deux principaux cas de figures :

– Le Développement : la plupart des stratégies proposent des processus d'évolution menés à partir de l'évolution des classes. Les impacts peuvent être assurés vers d'autres classes existantes ainsi que l'ensemble des instances concernées. Nous dénommons ce type de processus d'évolution, les processus de développement. Il s'agit : du développement des classes en intention : leurs spécifications ainsi que celles des classes concernées ; du développement des classes en extension : les instances existantes et concernées.

– L'Émergence : peu de processus d'évolution sont assurés à partir de l'évolution d'instances. Nous dénommons ce type de processus, des processus d'émergence. Il s'agit d'émergence de nouvelles informations conceptuelles à partir de l'évolution d'instances<fnref n="3" />. Schématiquement, les processus d'évolution sont représentés comme suit, et mettent en évidence les deux niveaux considérés : celui des classes et celui des instances :

<footnote n="3">³ Confère Vie Artificielle (section 2.8.2.1) pour situer l'inspiration de cette idée d'émergence.</footnote>
<figure><img src="image_6.png" /><figcaption>Figure 2-1: le Développement et l'Émergence : les deux processus d'évolution.</figcaption></figure>

Nous mettons explicitement en évidence les impacts intra et inter-niveaux. Le *développement* représente les impacts d'évolution des classes et des instances. Nous rappelons que l'évolution de classes vers d'autres classes et vers des instances, ainsi que l'évolution d'instances dans leurs valeurs ou dans leur rattachement à une autre classe se situent également dans le processus de développement. *L'émergence* représente les impacts d'évolution des instances vers les classes.

Nous abordons dans la section suivante, la représentation de l'évolution d'objets au travers de ses trois facettes : la *représentation triptyque*.

### 2.2.3. Représentation triptyque

En représentant chacune des trois facettes par un axe. Nous obtenons la caractérisation tridimensionnelle de l'évolution d'objets suivante (Figure 2-2) :
<figure><img src="image_7.png" /><figcaption>Figure 2-2: Les trois facettes de l'évolution d'objets.</figcaption></figure>

Cette représentation triptyque a pour axe principal *Objet de l'Évolution*, c'est-à-dire sur
*quoi* porte l'évolution, quelle est l'entité concernée par l'évolution. Ensuite, se situent le
*Processus d'Évolution* ainsi que le *Type d'Évolution* qui sont menés pour assurer
l'évolution.

En analysant cette figure, nous mettons également en évidence que :

– La problématique de l’évolution du *Produit* et du *Processus* a été plus largement traitée de façon *préventive* et principalement dans le cadre du développement. En situant la plupart des stratégies d’évolution, elles ont effectivement une politique d’évolution majoritairement *préventive* et principalement dans le cadre du développement (confère paragraphe 2.3 -, et plus particulièrement le paragraphe 2.4.7).

– La problématique de l’évolution du *Produit* et du *Processus* a été peu traitée de façon *curative*, et encore moins dans le cadre de l’émergence.

En conclusion, les triplets (*produit* ; *préventive* ; *développement*) et (*processus* ; *préventive* ; *développement*) sont concernés par un bon nombre de stratégies d'évolution. Les aspects *émergence* et *curatif* restent les parents pauvres de l'évolution d'objets.

2.2.4. Comment positionner une stratégie d'évolution ?

Pour classer les stratégies existantes, il suffit de répondre pour chacune d'entre elles
aux trois questions suivantes :
1. Quel est l'objet de l'évolution (produit ou processus) ?

2. Quel est le type d'évolution qu'elle propose (curative ou préventive) ?

3. Quel type de processus permet-elle (développement ou émergence) ?

C'est en répondant à ces questions, que nous avons remarqué que les stratégies étudiées œuvrent exclusivement sur le *produit*. La plupart d'entre elles font de l'évolution *préventive* et s'inscrivent dans des processus de *développement* (paragraphe 2.4.7).

La problématique de l'évolution de produit est abordée dans la section suivante :

## 2.3 - Problématique de l'Évolution du produit

Dans cette section, nous nous focalisons principalement sur une partie de la représentation triptyque de l'évolution. Nous nous intéressons en effet principalement au produit (confère la définition en section 2.2.2.1), car notre approche s'intéresse également sur l'évolution du produit. Nous abordons la problématique au travers de la problématique de l'évolution des classes, des impacts de l'évolution des classes vers les instances et de l'évolution des instances. Dans la présente section, nous nous intéressons uniquement aux stratégies d'évolution par modification de produit, plus précisément de classes, car notre approche préconise également des modifications directes sur le produit invoqué. Les autres stratégies d'évolution ainsi que celles qui gèrent les impacts sur les classes et instances et l'évolution d'instances sont présentées plus sommairement dans la section 2.6.1.

Les différents concepts du produit connaissent une certaine problématique d'évolution et représentent le point d'intérêt de bon nombres de stratégies d'évolution :

### 2.3.1. Problématique dans l'Évolution du Produit

Les opérations d'ajout, de suppression ou de modification de données ou de fonctionnalités d'un système ou d'une application orienté objet conduisent systématiquement à leur évolution. Ainsi, les changements dans la hiérarchie et la définition de classes doivent être propagés aux instances de la classe modifiée et des sous-classes concernées [Nguyen& 89]. Il faut alors gérer les divers impacts tels que : la propagation correcte des changements vers les sous-classes, les problèmes de conflits de noms, la réorganisation des liens d'héritage, etc. [Keen 89], [Kim& 88], [Skarra& 87], [Zdonik 90].

Plusieurs stratégies d'évolution ont été décrites dans la littérature de l'Évolution d'objets, mais chacune ne répond que partiellement aux besoins sus-cités. Nous avons
étudié les stratégies d'évolution les plus importantes portant sur l'évolution de
produit. Nous les présentons en trois catégories, selon le niveau auquel elles
s'intéressent :

– L'évolution de classes : l'évolution peut être par modification, par versionnement ou par dérivation de classes et/ou de schémas de classes ;

- L'impact de l'évolution de classes sur les instances ;

- L'évolution d'instances.

2.3.1.1. Problématique de l'évolution de classes

Une classe spécifie la structure et le comportement de ses instances. Elle peut évoluer tant dans la spécification de la structure que celle du comportement. L'expérience montre que les besoins des utilisateurs sont rarement stables et que les concepteurs trouvent des difficultés à classer des composants logiciels dans des taxonomies prédéfinies. En effet, la représentation de la réalité à l'aide de classes et de liens (héritage, composition, ...) n'est pas toujours triviale : l'information du monde réel présente souvent des nuances et des incomplétudes.

D'autres problèmes sont liés à la difficulté de construire des classes stables et réutilisables, et l'extension d'une hiérarchie par des sous-classes peut entraver la conception et le développement de nouveaux composants. Le premier point s'explique par le fait que des classes stables et réutilisables sont généralement obtenues suite à un processus itératif de tests et de corrections. Le second point s'explique par le fait qu'une hiérarchie constitue un noyau standard de fonctionnalités qui peut être étendu avec des sous-classes additionnelles. Ceci peut gêner la conception et le développement de nouveaux composants et le partage des classes par plusieurs utilisateurs.

2.3.1.2. Problématique de l'évolution d'instances

Dans une approche objet classique, une instance doit toujours être conforme à la spécification de sa (ses) classe(s). Elle peut évoluer selon deux cas de figures : suite à l'évolution de sa (ses) classe(s) ou à sa propre évolution :

– dans le premier cas, toute modification dans la spécification d'une classe peut entraîner l'évolution non seulement d'autres classes, mais aussi de ses instances. Cependant, les besoins sont parfois plus fins et plus nuancés : l'utilisateur peut vouloir modifier une classe sans que toutes les instances soient remises en cause ;

– dans le second cas, tout changement dans les informations portées par des
instances peut provoquer leur évolution directe. Faire évoluer une instance revient à
modifier ses valeurs tout en restant cohérente avec la définition de sa classe
génératrice. L'instance doit obéir à la politique d'évolution dictée par sa classe.
### 2.3.2. Problématique de notre approche

Nous rappelons (chapitre 1) que nous nous intéressons à l'évolution d'objets à partir de l'évolution dynamique de la structure d'instances. C'est le moyen que nous proposons à un concepteur d'applications d'objets complexes et volumineuses pour faire face à des situations de changements imprévus ou mal définis. Pour résumer et situer notre approche par rapport à l'évolution d'objets, nous répondons aux trois questions présentées en section 2.2.4 :

1. Quel est l'objet de l'évolution auquel nous nous intéressons ?

- le produit

2. Quel est le principal type d'évolution que nous proposons ?

- l'évolution curative

3. Quel est le principal type de processus que nous proposons ?

- l'émergence

Nos travaux se veulent complémentaires des stratégies préventives. Nous travaillons donc fondamentalement sur le produit en considérant essentiellement l'émergence et en s'inscrivant dans le cadre de l'évolution curative.

Nous considérons donc le produit comme étant aussi bien la classe, que la hiérarchie de classes (basée sur le lien d'héritage) ainsi que les instances aussi bien dans leur structure que dans leurs valeurs.

### 2.3.3. Stratégies d'Évolution étudiées

Nous présentons dans la section suivante uniquement les principales stratégies d'évolution de produit par modification de classes que nous avons étudiées (les autres sont présentées en section 2.6.1). Chaque stratégie est présentée par son principe général, ses avantages et inconvénients ainsi que le fonctionnement de la politique d'évolution.

Cette section met en évidence leur similarité entre elles et avec notre approche. En effet, toutes ces stratégies modifient le produit, plus précisément les classes et leur hiérarchie.

Ces stratégies ont :

- une politique d'évolution préventive, c'est-à-dire en prenant en compte les besoins connus ;

- et ce, dans le cadre du développement, mis à part la catégorisation qui fait de l'émergence et provoque du développement, c'est-à-dire en provoquant des impacts sur les autres classes et les instances concernées.
Dony, Huchard et Libourel [Dony& 97] rappellent à juste titre dans [Oussalah& 99] que
la conception et l'évolution de hiérarchies sont des tâches complexes en soulignant
entre autres que :

- La taille de certaines hiérarchies les fait échapper à un contrôle critique de leur(s) concepteur(s) ;

- L'évolution des hiérarchies (ajout ou retrait de classes, de propriétés,...) nécessite des modifications qui doivent rester sous le contrôle des concepteurs.

D'où l'intérêt des stratégies qui proposent une automatisation, même partielle, des procédés de construction et de maîtrise de l'évolution de hiérarchies de classes. Les travaux intègrent une dimension algorithmique :

- Ils s'appuient sur des algorithmes de traitement de hiérarchies de classes, ou ils utilisent des primitives de modifications locales.

- Les algorithmes peuvent être globaux : ils construisent la hiérarchie à partir des classes mises à plat.

- Ils peuvent être incrémentaux : ils partent alors d'une hiérarchie pré-existante et d'une classe, et ne modifient que ce qu'il faut de la hiérarchie pour y intégrer convenablement la classe. Sans oublier l'importance de l'intervention du concepteur au cours du processus et dans quelle mesure il peut intervenir.

Aussi, dans le cadre du fonctionnement de l'évolution des stratégies, nous détaillons
pour chacune d'entre elles sur quelle partie du produit elle agit et quelles sont les
actions menées pour assurer le processus d'évolution et le type d'évolution, toujours
guidés par les objectifs et la politique de la stratégie. Nous ne reprenons pas le détail
du déroulement de chacune des stratégies, mais uniquement les actions qu'elles
effectuent dans le cadre de leur application. Dans un premier temps, nous énumérons
les actions menées, et dans un second temps, nous exprimons ces actions en opérations
connues de modification d'une hiérarchie de classes, ainsi que la sémantique qui leur
est associée.

Ensuite, au vu de cette présentation, nous proposons une taxonomie du produit ainsi que des opérations d'évolution par modification que nous départageons en opérations de base et opérations avancées :
## 2.4 - Principales Stratégies d'Évolution par modification de produit

Plusieurs stratégies d'évolution ont été décrites dans la littérature de l'Évolution d'objets, mais chacune ne répond que partiellement aux besoins sus-cités. Nous étudions de manière plus détaillée les stratégies d'évolution qui ont pour politique d'agir directement sur la hiérarchie et la structure des classes, ce qui est également le cas de notre approche. Voici, en substance, leur principe, leur avantages et leurs limites ainsi que leur fonctionnement :

Les trois premières stratégies sont considérées comme étant d'*approche algorithmique* : elles ont pour but d'insérer une classe dans une hiérarchie de classes existante.

### 2.4.1. Réorganisation de classes

#### 2.4.1.1. Principe, avantages et inconvénients

**Principe :** la réorganisation de classes [Casais 91] s'appuie sur un algorithme pour insérer une nouvelle classe en restructurant la hiérarchie de manière à éliminer les redondances d'information et à factoriser les propriétés communes.

**Avantages :** l'intérêt de cette stratégie, ainsi que des deux suivantes, est la factorisation de propriétés communes, évitant ainsi l'existence de propriétés redondantes et de propriétés indéfinies. Elles assurent également la minimalité du nombre de classes.

**Inconvénients :** cependant, la classification peut déranger l'ensemble du schéma de classes, et durant l'exploitation, les conséquences peuvent s'avérer coûteuses. La réorganisation peut insérer des classes uniquement au niveau des feuilles existantes dans la hiérarchie. La catégorisation peut initier des classes mais ne peut pas assurer leur cohérence sémantique.

#### 2.4.1.2. Fonctionnement de l'évolution

Casais propose [Casais 91] un algorithme qui analyse les redéfinitions qui sont apportées lorsqu'une classe est ajoutée dans la hiérarchie, et restructure la hiérarchie pour découvrir des classes éventuellement manquantes. Il estime que les concepts de la réalité doivent être proprement encapsulés en tant que classes, de façon à être facilement spécialisées ou combinées. Une structure de la hiérarchie inadéquate, des classes manquantes dans la hiérarchie, une déficience dans la modélisation peuvent sérieusement affecter la réutilisation. La collection de classes doit alors évoluer de façon à éliminer de tels défauts et améliorer sa robustesse et sa réutilisabilité.
Il distingue deux types de réorganisation : la *décomposition* et la *restructuration* :

- La *décomposition* consiste à éclater diverses classes entremêlées en un lien d'héritage simple. Le but de cette opération est de réduire la surcharge sémantique du lien d'héritage et de détecter de possibles modélisations alternatives.

- La *restructuration* consiste à extraire les propriétés partagées par plusieurs classes et les isoler ensemble au sein d'un nouveau et commun ancêtre. Les buts sont de factoriser les propriétés communes.

Les opérations principalement utilisées dans l'algorithme proposé sont :

<table><caption>Tableau 2-1: actions menées dans le déroulement de l'algorithme incrémental de la réorganisation.</caption><thead><tr><td>Opération</td><td>Produit concerné</td><td>Sémantique</td></tr></thead><tbody><tr><td>Création</td><td>Classe</td><td>Création d'une classe</td></tr><tr><td>Transfert</td><td>attribut d'une classe vers une autre</td><td>Copie dans la classe cible avec/sans suppression dans la classe source</td></tr><tr><td>Scission</td><td>classes en deux (attributs acceptés et attributs restants)</td><td>Manipulation de groupes d'attributs</td></tr><tr><td>Vérification</td><td>de références non résolues</td><td></td></tr><tr><td>Re-direction</td><td>d'un lien d'héritage</td><td>Changement des source et cible du lien (peut se faire par création/suppression de liens)</td></tr><tr><td>Suppression</td><td>de classes redondantes dans le graphe</td><td>Suppression d'attributs/méthodes ainsi que des liens impliqués.</td></tr></tbody></table>

Ces opérations peuvent se décomposer en des ensembles d'opérations plus simples. Elles se résument comme suit :
<table><caption>Tableau 2-2: taxonomie des opérations et leur sémantique pour la réorganisation de classes.</caption><thead><tr><td>Opération</td><td>Produit concerné</td><td>Sémantique</td></tr></thead><tbody><tr><td>Attachement</td><td>d'une classe</td><td>ajout d'un lien d'héritage</td></tr><tr><td>Héritage</td><td>de méthode/attribut</td><td>ajout (copie) de méthode/attribut</td></tr><tr><td>Création</td><td>d'une classe</td><td>création lien d'héritage, attributs/méthodes</td></tr><tr><td>Mise en facteur</td><td>d'attributs</td><td>création d'une classe</td></tr><tr><td>Attachement</td><td>de classes</td><td>ajout/suppression d'arcs</td></tr><tr><td>Déconnexion</td><td>de classes</td><td>ajout/suppression d'arcs</td></tr><tr><td>Fusionne</td><td>des classes</td><td>ajout et suppression d'arcs (+propagation)</td></tr><tr><td>Suppression</td><td>de classes</td><td>suppression d'arcs (+propagation)</td></tr></tbody></table>

Toutes les opérations n'ont pas la même granularité et impliquent des impacts et des propagations plus ou moins limités.

## 2.4.2. Classification de classes

### 2.4.2.1. Principe, avantages et inconvénients

**Principe :** les mécanismes de classification de classes [Dekker 94], [Capponi 94] consistent à organiser et à maintenir une hiérarchie de classes, en insérant de façon appropriée de nouvelles classes.

**Avantages :** l'intérêt de la factorisation de propriétés communes, évitant ainsi l'existence de propriétés redondantes et de propriétés indéfinies. Elles assurent également la minimalité du nombre de classes.

**Inconvénients :** cependant, la classification peut déranger l'ensemble du schéma de classes, et durant l'exploitation, les conséquences peuvent s'avérer coûteuses.

### 2.4.2.2. Fonctionnement de l'évolution

La classification de classes consiste à déterminer la position d'une classe dans la hiérarchie de classes compte-tenu de sa description en termes d'attributs [Capponi 94]. Étant donné que l'algorithme repose essentiellement sur une succession de phases de comparaison et de positionnement des attributs de la classe à classifier et des attributs existants, nous nous intéressons plus aux phases d'insertion et des impacts conséquents qu'au principe détaillé de l'algorithme. Ainsi, l'insertion d'une classe dans
une hiérarchie de classes correspond à l'insertion de chaque attribut de cette classe dans le graphe des attributs. La phase finale de l'algorithme revient à faire un choix final de l'emplacement de la classe. Son insertion provoque la modification de la hiérarchie de classes. Les opérations reviennent à toutes les opérations de manipulation d'une hiérarchie de classes telles que définies de façon détaillée par [Banerjee& 1987].

### 2.4.3. Catégorisation

#### 2.4.3.1. Principe, avantages et inconvénients

**Principe :** La *catégorisation* [Napoli 92] quant à elle regroupe des instances ayant des caractéristiques et un comportement similaires au sein d'une classe, qui doit être ensuite insérée dans la hiérarchie.

**Avantages :** outre l'intérêt de la factorisation de propriétés communes et la minimalité du nombre de classes, la catégorisation peut initier de nouvelles classes mathématiquement correctement définies.

**Inconvénients :** la catégorisation peut initier des classes mais ne peut pas assurer leur cohérence sémantique.

#### 2.4.3.2. Fonctionnement de l'évolution

La catégorisation revient à la construction de spécifications d'une classe à partir d'un ensemble d'instances potentielles. Une fois la spécification trouvée, son insertion nécessite le recours aux même types d'actions que celles utilisées par la classification.

### 2.4.4. Correction de classes ou Chirurgie de classes :

#### 2.4.4.1. Principe, avantages et inconvénients

**Principe :** elle est essentiellement utilisée dans les bases de données orientées objet [Banerjee& 87], [Penney& 87]. Le principe est de répercuter les opérations de mises à jour demandées sur la classe ou la collection de classes impliquée, en la modifiant voire en réorganisant totalement la hiérarchie. Elle rend la mise à jour des classes effective après tout changement. La consistance du modèle est vérifiée et maintenue en cadrant l'évolution des classes par des contraintes d'intégrité qui doivent être satisfaites après chaque modification. Le but étant de maintenir la consistance d'une hiérarchie de classes, tous les ajustements nécessaires doivent être prévus
en respectant des invariants et en définissant une taxonomie des opérations spécifiques et des primitives de modifications.

**Avantages** : le principal avantage est la maintenance de la cohérence et la définition de stratégies de répercussions des changements du schéma de classes vers les instances.

**Inconvénients** : le principal inconvénient de la chirurgie de classes est qu'elle ne donne aucune directive telle que pourquoi et quand des modifications spécifiques doivent être effectuées. Les modifications ont des impacts locaux et ne peuvent pas traiter les changements sur plusieurs classes. La stratégie ne tient pas compte également de l'historique des différentes évolutions qui auront été menées. Elle ne peut donc être utilisée que si l'historique de l'évolution n'est pas souhaité. De plus, la base reste invalide durant les changements, qui peuvent rapidement devenir complexes et onéreux. Les applications qui s'exécutent en utilisant la base de données peuvent également devenir invalides si elles s'appuient sur des caractéristiques qui auront été perdues après la mise à jour [Borgida 88].

### 2.4.4.2. Fonctionnement de l'évolution

Sous le modèle Orion [Banerjee& 87], un concepteur de schémas spécifie une évolution en termes de taxonomie et le système vérifie l'évolution en déterminant si elle est consistante avec les invariants et ensuite ajuste le schéma et la base de données au vu des règles appropriées. Les auteurs proposent une structure formelle pour l'évolution de schéma, en termes d'un ensemble de propriétés invariantes d'un schéma orienté-objet et de règles pour les préserver.

La taxonomie complète des opérations est établie selon que les changements sont apportés au contenu d'un nœud (1), à un arc (2) ou à un nœud (3). La taxonomie est suffisamment détaillée pour exprimer aussi bien les opérations que le produit concerné ainsi que la sémantique :

<table><thead><tr><td>Opération</td><td>Produit concerné</td><td>Sémantique</td></tr></thead><tbody><tr><td>Changement</td><td>Contenu d'un nœud</td><td><ul><li>Ajout d'une nouvelle variable d'instance à une classe</li><li>Retirer une variable d'instance d'une classe</li><li>Changement du nom d'une variable d'instance d'une classe</li><li>Changement du domaine d'une variable d'instance d'une classe</li><li>Changement de l'héritage (parent) d'une variable d'instance (hérite d'une autre variable d'instance avec le même nom)</li></ul></td></tr></tbody></table>
<table><caption>Tableau 2-3: taxonomie détaillée des opérations de modifications</caption><tr><td></td><td></td><td><ul><li>Changement de la valeur par défaut d'une variable d'instance</li><li>Manipulation d'une valeur partagée d'une variable d'instance (Ajout d'une valeur partagée, Modification d'une valeur partagée, Retrait d'une valeur partagée)</li><li>Retrait de la propriété lien de composition pour une variable d'instance</li><li>Changement à une méthode</li></ul></td></tr><tr><td>Changement</td><td>Arc</td><td><ul><li>Rendre une classe S comme une super-classe d'une classe C</li><li>Retirer une classe S de la liste des super-classes de la classe C</li><li>Changer l'ordre des super-classes d'une classe C</li></ul></td></tr><tr><td>Changement</td><td>Nœud</td><td><ul><li>Ajouter une nouvelle classe</li><li>Retirer une classe existante</li><li>Changer le nom d'une classe</li></ul></td></tr></table>

Il est à noter, comme cela est rappelé à juste titre dans [Penney 87], que les problèmes qu'ils traitent vont plus loin que la modification de classes, pour également concerner le versionnement de classes, d'objets et de méthodes. En effet, leur méthodologie implémente la modification en utilisant des versions. De plus, ils travaillent sur des graphes de classes où l'héritage multiple est permis. Dans le cadre de stratégies modifiant la structure de la hiérarchie de classes et dans le cadre de l'héritage simple, cette taxonomie se réduit. Elle est présentée de manière plus appropriée dans [Zicari 1991], qui de plus fait un parallèle entre ces opérations et celles de manipulations de graphes.

GemStone [Penney 87] permet l'ajout d'une classe comme feuille dans l'arbre d'héritage. Les opérations proposées ne sont pas exhaustives. Ils présentent uniquement les opérations qui peuvent apporter des modifications utiles, bien comprises et sont raisonnablement implémentables :

<table><thead><tr><td>Opération</td><td>Produit concerné</td><td>Sémantique</td></tr></thead><tbody><tr><td>Renommer</td><td>le nom d'une variable d'instance</td><td>Le renommage est propagé dans toutes les sous-classes.</td></tr><tr><td>Ajouter</td><td>une variable d'instance nommée (référençable)</td><td>Si le nom de variable d'instance existe déjà, l'opération est rejetée. Sinon, les modifications sont propagées.</td></tr><tr><td>Retirer</td><td>une variable d'instance nommée</td><td>Toutes les instances de la classe sont réécrites pour retirer la variable d'instance. Ne peut être retirée si elle est héritée d'une super-classe.</td></tr></tbody></table>
<table><caption>Tableau 2-4: taxonomie des opérations de modifications utilisées dans
GemStone</caption><tr><td>Modifier</td><td>une contrainte sur une variable d'instance</td><td>Une contrainte peut être spécialisée ou généralisée. Si elle n'est ni héritée si spécialisée, la variable d'instance associée est détruite et re-ajoutée avec la nouvelle contrainte.</td></tr><tr><td>Retirer</td><td>une classe</td><td>Une classe ne peut être enlevée si elle a des instances. Il est possible d'enlever toutes les instances d'une classe. Le passage d'une classe vers une autre peut utiliser les opérations sur l'ajout et le retrait de variables d'instance.</td></tr><tr><td>Ajouter</td><td>une classe</td><td>Ne peut être ajoutée qu'en tant que feuille.</td></tr></table>

Comme conséquence de la sémantique des opérations pré-citées, d'autres opérations sont donc également utilisées, principalement l'ajout, le retrait, et la modification des instances.

## 2.4.5. Versionnement de classes

### 2.4.5.1. Principe, avantages et inconvénients

**Principe :** même si le point fort est le versionnement, il n'empêche que sur une version donnée, les changements se font le plus souvent par modification directe de la hiérarchie de classes. Cette stratégie est largement utilisée dans le domaine des bases de données orientées objet [Kim & 88], [Zdonik 90], [Katz & 87], ainsi qu'en CAO [Talens 93] et en Génie Logiciel [Ahmed-Nacer 94]. Une évolution apportée à une classe provoque la dérivation d'une nouvelle version de cette classe. Le versionnement permet de garder une trace des variations intrinsèques d'une application, d'une hiérarchie de classes ou d'une classe tout au long de ses différents changements. Les mises à jour sont assurées uniquement sur des copies, en créant de nouvelles versions de classes de manière à ce que les applications existantes continuent à se dérouler sur les versions originelles. Les principales actions consistent à structurer les différentes catégories de versions ; de déterminer quelle version est utilisée quand une classe est instanciée ; de décider quelles sont les opérations qui justifient la création de nouvelles versions ; d'utiliser des fonctions de conversions pour garantir une cohérence entre les classes copiées et les classes originelles.

**Avantages :** le versionnement offre l'avantage de ne pas perdre d'informations tout au long de l'évolution de la spécification d'une classe et de garder ses
différents états. La stratégie peut être considérée comme étant une
stratégie complémentaire à la correction de classes. Elle s'avère nécessaire
dans le cadre d'environnements multi-utilisateurs. Elle permet la
restauration et les mises à jour de BDOO, ce qui constitue un avantage
indéniable pour toute application nécessitant la reprise d'anciennes
spécifications, telles qu'en CAO. Elle est également un bon support pour
le processus de conception. Elle permet d'améliorer les performances de
systèmes distribués et constitue un bon support pour garder trace des
différentes évolutions effectuées sur le système.

*Inconvénients* : cependant, c'est une stratégie qui impose une navigation entre deux structures fortement liées : la hiérarchie d'héritage et le graphe de dérivations (des différentes versions). La gestion des différentes versions implique un grand nombre d'informations à gérer. Les mécanismes de propagation de versions peuvent mener à une prolifération de versions inutiles, rendant complexe la gestion et la navigation des graphes d'héritage et de dérivation.

2.4.5.2. Fonctionnement de l'évolution

Nous ne traitons pas le mécanisme de versionnement mais les modifications au sein
d'une même version. Nous pouvons donc considérer qu'il s'agit de l'évolution d'une
hiérarchie de classes. Cela peut se faire par une réorganisation de classes ou une
correction de classes, selon les besoins.

2.4.6. Migration de caractéristiques

2.4.6.1. Principe, avantages et inconvénients

*Principe* : la migration de caractéristiques est utilisée dans les Systèmes d'Information. Une migration est une opération qui transfert des caractéristiques entre classes, valeurs d'attributs d'instances ou d'instances [Jacobson& 91]. Pour cela, il est proposé de définir un graphe de transfert de migration. Un composant d'une migration est une partie de cette migration, constituée de classes de départ et de classes d'arrivées ainsi que de liens de transfert qui transmettent des caractéristiques entre ces deux ensembles de classes [Jiang& 96].

*Avantages* : la stratégie est particulièrement intéressante pour la conception de l'évolution de systèmes orientés-objet avec un grand nombre de classes (>200) et peut supporter les migrations dans le cadre de transformations de modèles (par exemple, d'un modèle Entité-Association vers un modèle Orienté Objet).
***Inconvénients*** : cependant, il est difficile de rechercher et par conséquent de trouver les
meilleures partitions de migrations.

2.4.6.2. Fonctionnement de l'évolution

Les objectifs sont l'analyse, la conception, et l'exécution des migrations des
caractéristiques de classes, de valeurs d'attributs d'instances et d'instances. Le principe
étant de faire migrer des caractéristiques de classes (attributs, contraintes,
opérations...) vers d'autres classes, ils utilisent des opérations pour gérer l'évolution de
hiérarchies de classes [Jiang& 96]. En plus des opérations classiques de modification, ils
définissent des opérations de réutilisation, de migration et de réorganisation :
<table><caption>Tableau 2-5: les opérations pour la migration de caractéristiques de classes</caption><thead><tr><th>Opération</th><th>Produit concerné</th><th>Sémantique</th></tr></thead><tbody><tr><td>Création/ Copie/ Suppression / Modification /</td><td>Classes/ Valeurs d'attributs d'instances/ Caractéristiques de classes : attributs, contraintes, opérations/ Instances</td><td>Opérations de base de modification de hiérarchies de classes et d'instances.</td></tr><tr><td>Réutilisation</td><td>Classes/ Valeurs d'attributs d'instances/ Caractéristiques de classes : attributs, contraintes, opérations/ Instances</td><td>Opérations qui s'appuient sur les opérations de base.</td></tr><tr><td>Transfert</td><td>Caractéristiques</td><td>Le transfert s'appuie sur la migration. Un lien de transfert est défini entre une classe source et une classe cible. Il est à noter que les liens d'héritage ne sont pas transférés.</td></tr><tr><td>Migration</td><td>caractéristiques de classes<br/>valeurs d'attributs d'instances<br/>Instances</td><td>La migration utilise des liens de transferts, organisés en graphe connexe. Pour un lien de transfert, il y a une source et une cible. Le transfert peut se faire avec ou sans suppression dans la source, avec ou sans modification dans la source. La source et la cible sont de même type : classes - valeurs d'attributs d'instances - instances.</td></tr><tr><td>Réorganisation</td><td>hiérarchie de classes</td><td>La hiérarchie nécessite d'être réorganisée après une migration.</td></tr></tbody></table>

Au vu des différentes opérations menées et des différents éléments manipulés, nous remarquons que des opérations ont la même sémantique et invoquent d'autres opérations plus techniques selon l'élément concerné. Pour cela, nous dégageons les taxonomies suivantes de produit et d'opérations. Nous nous inspirons directement de la taxonomie des concepts proposée dans [Zicari 91] et la taxonomie des opérations de mises à jour de schémas de BDOO proposée par [Banerjee& 87].
### 2.4.7. Premier bilan : positionnement des stratégies étudiées dans le triptyque

En répondant pour chacune des stratégies d'évolution par modification étudiées, au triplet de questions de la section 2.2.4, nous arrivons à les situer sur les deux axes *Type d'évolution* et *Processus d'évolution*.

Le positionnement des stratégies étudiées donne :

<figure><img src="image_8.png" /><figcaption>Figure 2-3: première classification triptyque : stratégies d'évolution par modification.</figcaption></figure>

Nous faisons un zoom sur ces stratégies qui agissent sur les mêmes éléments de produit que notre approche, à savoir les stratégies qui agissent directement sur la structure de la hiérarchie de classes, via le lien d'héritage, les spécifications de classes ainsi que le lien d'instanciation.

Nous présentons dans les sections suivantes les principales stratégies d'évolution qui permettent de gérer les impacts d'évolution de classes vers les instances ainsi que celles qui permettent de gérer l'évolution d'instances :
### 2.4.8. Impacts de l'évolution de classes vers les instances

Les modifications sur des classes impliquent le plus souvent leur propagation au niveau des instances. Ces propagations peuvent être mises en place de trois manières différentes :

#### 2.4.8.1. Conversion d'instances

**Principe :** les instances sont rendues conformes à la nouvelle définition de leur classe en les réorganisant physiquement. Il existe deux principales stratégies : la *conversion immédiate* [Penney& 87] et la *conversion différée* [Banerjee& 87], [Lerner& 90]. La conversion immédiate transforme les instances automatiquement après l'évolution de leur classe. La conversion différée consiste, quant à elle, à adapter les instances individuellement uniquement lorsqu'elles sont accédées la première fois suite à la modification de leur classe. Ces deux stratégies peuvent être combinées entre elles, tel que le fait le système O₂ [Bancilhon& 88].

**Avantages :** la conversion immédiate permet de garder la base cohérente. La conversion différée réduit le nombre de conversions et est donc économique en termes d'accès.

**Inconvénients :** la conversion immédiate rend la base inaccessible durant la conversion. Elle est également coûteuse en termes de performances. La conversion différée conserve les données incohérentes simultanément durant le laps de temps que dure la modification de la classe et celle de ses instances.

#### 2.4.8.2. Émulation d'instances

**Principe :** l'émulation d'instances est également appelée filtrage, car elle utilise un filtre pour adapter logiquement (et non physiquement) une instance à une nouvelle définition de sa classe. Lors de l'accès à l'instance, celle-ci est interprétée grâce à ce filtre entre la représentation physique de l'instance et la définition de sa classe. Cette technique est souvent utilisée avec la technique de versionnement de classes [Skarra& 87].

**Avantages :** l'instance est logiquement adaptée et non physiquement, ce qui garantit la cohérence de l'état réel de l'instance et évite de causer des changements peut être inopportuns et coûteux.

**Inconvénients :** l'émulation peut entraîner une dégradation des performances si le nombre d'incompatibilités entre les instances et les classes augmente, et la définition d'une procédure d'exception est lourde à assurer.
### 2.4.8.3. Versionnement d'instances

**Principe :** le principe est d'associer une version d'une instance à chaque version de sa classe [Clamen 94], [Talens& 93]. Ainsi, après la modification d'une classe, dès qu'une instance est accédée, le système en crée automatiquement une version conforme à cette nouvelle version de classe. Des contraintes de dépendance entre les versions d'une classe permettent de garder la cohérence entre elles.

**Avantages :** cette stratégie assure la cohérence des instances et la compatibilité des applications.

**Inconvénients :** l'inconvénient est qu'à chaque nouvelle version d'une classe, une version de chacune de ses instances est créée, avec toutes les conséquences quant aux coûts de stockage, de navigation dans les hiérarchies de classes et celles de versions.

### 2.4.9. Évolution d'instances

L'évolution des instances relève, comme vu précédemment, soit d'une conséquence de l'évolution des classes, soit d'une évolution directe des instances. Dans cette dernière situation, un changement dans la valeur des attributs d'une instance et/ou dans son lien d'appartenance à une classe constituent les deux cas de figures d'évolution d'une instance. Trois principales stratégies existent pour la gérer :

#### 2.4.9.1. Contraintes d'intégrité

**Principe :** elles permettent de baliser l'évolution de l'instance en définissant des contraintes structurelles, comportementales et applicatives. S'il y a violation, l'évolution est rejetée par le système [Meyer 88], [Bounaas 95].

**Avantages :** les contraintes d'intégrité permettent ainsi de contrôler l'évolution des instances en vérifiant la cohérence des valeurs modifiées et/ou de réagir face à une violation d'une contrainte.

**Inconvénients :** elles n'ont qu'un impact local.

#### 2.4.9.2. Versions d'instances

**Principe :** elles sont utilisées pour garder une trace des divers états que peut prendre une instance. Les versions d'instances permettent également de générer des instances constamment conformes à leur définition.

**Avantages :** la stratégie est utile dans les environnements de conception.
**Inconvénients** : mais, elles sont coûteuses et il est difficile de gérer les liens de dépendance entre les versions.

### 2.4.9.3. Classification d'instances

**Principe** : elle est utile lorsqu'une instance n'est plus conforme à la spécification de sa classe d'appartenance. La classification d'instances œuvre à rattacher les instances à des classes de la hiérarchie potentiellement candidates, revenant ainsi à un mécanisme de raisonnement au sens de l'Intelligence Artificielle. Dans cet ensemble de classes candidates peut se trouver une classe plus adéquate au nouvel état de l'instance. Dans ce cas, l'instance est propagée dans le graphe de classes, en complétant les valeurs si nécessaire. Elle est utilisée dans des systèmes à base de connaissances [Rechenman 89].

**Avantages** : la classification d'instances permet à une instance d'évoluer au sein d'une hiérarchie de classes (en termes de rattachement à une classe) et infère les valeurs de façon à la compléter par rapport à sa nouvelle définition (pour être conforme à sa nouvelle classe).

**Inconvénients** : la classification d'instances s'avère être une stratégie coûteuse lorsqu'elle est utilisée dans les langages et les bases de données orientées objet.

Nous nous intéressons maintenant à la manière dont les stratégies d'évolution de classes par modification (présentées en section 2.4 - ) mettent en œuvre l'évolution, autrement dit les opérations qu'elles utilisent. Nous proposons de dégager des taxonomies de produit et d'opérations d'évolution, de manière à mettre en évidence les concepts et les opérations communs aux stratégies d'évolution par modification du produit :

## 2.5 - Taxonomies de produits et d'opérations

### 2.5.1. Taxonomie du produit

Nous considérons la structure hiérarchique de classes comme un graphe constitué de nœuds et d'arcs [Zicari 91] :
### 2.5.1.1. Nœud

Un nœud représente une classe ou une instance (voire une collection de classes pour des stratégies oeuvrant sur des portions ou des schémas de classes). La manipulation d'un nœud dépend du type de nœud. En effet, l'ajout d'une classe et l'ajout d'une instance se ressemblent sémantiquement puisqu'il s'agit d'ajout, mais les opérations techniques invoquées diffèrent.

### 2.5.1.2. Contenu d'un nœud

Il s'agit d'un attribut (variable d'instance) et/ou d'une méthode, voire de contraintes. Selon la stratégie, les actions portent sur aussi bien des attributs que des méthodes ou uniquement d'attributs ou uniquement (voire principalement) de méthodes. Nous nous intéressons principalement aux attributs.

### 2.5.1.3. Arc

Un arc est tout type de lien liant deux nœuds. Il s'agira essentiellement du lien d'héritage, selon l'utilisation qui en est faite (spécialisation, implémentation, restriction). Il peut également s'agir des autres types de liens de références (association, composition) et du lien qui lie une instance à sa classe.

## 2.5.2. Taxonomie des opérations

Nous remarquons, au vu de la politique d'évolution, que nous pouvons dégager deux catégories d'opérations : des *opérations de base* et des *opérations avancées*. Quelques-unes de ces opérations peuvent être invoquées sur les différents types de produit alors que d'autres ne peuvent s'appliquer qu'à un seul type de produit.

### 2.5.2.1. Opérations de base

Nous entendons par *opération de base* toute opération qui s'applique sur un produit donné : un nœud, le contenu d'un nœud ou un arc. Une opération de base a une *sémantique* donnée : *modification, ajout ou suppression*. Selon le produit concerné, l'implémentation d'une opération est différente et sa portée est également différente. L'implémentation d'une opération dépendra donc du produit. La portée de l'opération dépend également du produit :
<table><thead><tr><th colspan="2">Opération</th><th rowspan="2">Modification</th><th rowspan="2">Ajout</th><th rowspan="2">Suppression</th></tr><tr><th colspan="2">Produit</th></tr></thead><tbody><tr><td rowspan="2">Nœud</td><td>Instance</td><td>⊕</td><td>⊕⊕</td><td>⊕⊕</td></tr><tr><td>Classe</td><td>⊕⊕⊕</td><td>⊕⊕⊕</td><td>⊕⊕⊕</td></tr><tr><td rowspan="3">Contenu d'un<br>nœud</td><td>Attribut</td><td>⊕⊕⊕</td><td>⊕⊕⊕</td><td>⊕⊕⊕</td></tr><tr><td>Valeur d'attribut</td><td>⊕</td><td>⊕</td><td>⊕</td></tr><tr><td>Méthode</td><td>⊕⊕⊕</td><td>⊕⊕⊕</td><td>⊕⊕⊕</td></tr><tr><td rowspan="2">Arc</td><td>Lien d'héritage</td><td>⊕⊕⊕</td><td>⊕⊕⊕</td><td>⊕⊕⊕</td></tr><tr><td>Lien de référence<br>(association,<br>composition)</td><td>⊕⊕⊕</td><td>⊕⊕⊕</td><td>⊕⊕⊕</td></tr></tbody></table>

⊕ : portée ponctuelle (au niveau du produit invoqué)

⊕⊕ : portée ponctuelle ∨ portée locale (vers les instances)

⊕⊕⊕ : portée ponctuelle ∨ portée locale ∨ portée globale (vers d'autres classes et les instances)

∨ : opérateur 'ou_logique'

<caption>Tableau 2-6: opérations de base</caption>

Ainsi, l'ajout d'une instance est différent de l'ajout d'une classe. La portée de l'ajout d'une instance est à la fois ponctuelle (ajout de l'instance) et locale (modification de l'extension d'une classe). De même, l'ajout d'une classe en tant que nœud interne d'une hiérarchie ou en tant que feuille d'une hiérarchie implique des portées différentes. Dans le premier cas, la portée concerne l'ensemble des sous-classes et les instances existantes. Dans le second cas, elle concerne l'ajout de la classe (et par conséquent de ses attributs et méthodes) et, par la suite, la création et la manipulation de ses instances.

### 2.5.2.2. Opérations avancées

Nous entendons par opération avancée toute opération qui s'applique sur deux produits. Le premier produit est la source de l'opération et le second est sa cible. Nous dégageons, au vu de l'étude des opérations mises en jeu par les stratégies étudiées de manière plus approfondie, et distinguons les opérations avancées suivantes : *Transfert* (ou *Migration*), *Scission* et *Fusion*. Une opération avancée, tout comme une opération de base, a une sémantique donnée. Selon le produit concerné, le transfert d'une instance vers une classe est différent du transfert d'une classe vers une autre hiérarchie de classes. L'implémentation des deux transferts est différente et les impacts sont également différents. De plus, la première nécessite, après la vérification de conformité à la nouvelle classe, la migration de l'instance. Alors que la seconde nécessite de faire appel aussi bien à des opérations de base qu'à des opérations avancées (selon la
politique de la stratégie) pour mener à bien le transfert et ses impacts. L'implémentation d'une opération avancée dépend donc du type du produit source et de celui du produit cible. La portée de l'opération en dépend également. Nous représentons les opérations avancées comme suit :

<table><caption>Tableau 2-7: opérations avancées</caption><thead><tr><th rowspan="2"></th><th rowspan="2"></th><th colspan="2">Transfert</th><th colspan="2">Scission</th><th colspan="2">Fusion</th></tr><tr><th>Source</th><th>Cible</th><th>Source</th><th>Cible</th><th>Source</th><th>Cible</th></tr></thead><tbody><tr><td rowspan="2">Nœud</td><td>Instance</td><td>Instance<br>Classe</td><td>Instance<br>Classe</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Classe</td><td>Classe</td><td>Classe</td><td>Classe</td><td>Classes</td><td>Classes</td><td>Classe</td></tr><tr><td rowspan="3">Contenu<br>d'un<br>nœud</td><td>Attribut</td><td>Classe</td><td>Classe</td><td>-</td><td>-</td><td>Attributs</td><td>Classe</td></tr><tr><td>Valeur<br>d'attribut</td><td>Instance</td><td>Instance</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Méthode<br>(signature et<br>corps)</td><td>Classe</td><td>Classe</td><td>-</td><td>-</td><td>Méthodes</td><td>Classe</td></tr><tr><td rowspan="2">Arc</td><td>Lien<br>d'héritage</td><td>Schéma</td><td>Schéma</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Lien de<br>référence<br>(association,<br>composition)</td><td>Classe<br>Schéma</td><td>Classe<br>Schéma</td><td>Classe</td><td>Classe</td><td>Classe</td><td>Classe</td></tr></tbody></table>

Chaque opération avancée nécessite, pour son implémentation, d'avoir recours aux opérations de base. Nous mettons en évidence principalement la source et la cible de chaque opération avancée, selon le type de produit. Nous n'exprimons pas la portée de chaque opération premièrement pour des raisons de lisibilité et secondement parce qu'elle peut se déduire des opérations de base qui sont nécessaires pour mener à bien chaque opération avancée.

Il est à noter que les opérations de base sont nécessaires dans la mise en œuvre de toutes les stratégies, mais les opérations avancées ne sont pas forcément toutes utilisées : cela dépend de la politique de la stratégie d'évolution choisie.

### 2.5.3. Bilan

Nous avons initié la présentation des opérations et la distinction entre les opérations de base et les opérations avancées pour plusieurs raisons :
- Cette façon de considérer les opérations, aussi bien de base qu'avancées, permet d'uniformiser la présentation des stratégies, et par conséquent de les comparer.

- De plus, elles permettent d'exprimer, en termes d'opérations recensées et connues, la politique d'évolution de chaque stratégie.

- Cela permet de mettre en évidence comment est assuré le processus d'évolution de développement ou d'émergence et quelles sont les opérations menées et surtout la source et la cible des opérations ainsi que leur séquence. Ainsi, il est possible d'exprimer de façon opératoire comment est assuré le type d'évolution : du curatif ou du préventif (avec rupture ou continu). En effet, les mêmes opérations peuvent être utilisées dans les deux cas, aussi bien pour du développement que de l'émergence, mais la différence est marquée par :

- Le niveau de départ de l'évolution (classes ou instances) ;

- La séquence dans laquelle les opérations sont effectuées ;

- Le niveau final de l'achèvement de l'évolution ainsi que ses impacts.

De plus, pour exprimer la politique d'évolution de toute stratégie faisant de la modification d'une hiérarchie de classes, nous pouvons avoir recours à ces deux ensembles d'opérations. En conclusion, nous pouvons exprimer de manière plus claire la représentation triptyque de l'évolution d'objets par modification de hiérarchies de classes. L'axe principal reste le produit, et le type d'évolution ainsi que le processus d'évolution se complètent mutuellement par rapport au produit considéré.

Nous récapitulons en faisant remarquer que ces opérations d'évolution sur le produit sont utilisées différemment mais surtout dans des séquences différentes lors de l'exécution (de façon automatisée ou non) pour assurer les objectifs des stratégies :

<table><caption>Tableau 2-8: stratégies d'évolution par modification d'une hiérarchie de classes</caption><thead><tr><th rowspan="2">Type Évolution<br>Processus d'Évolution</th><th colspan="2">Préventif</th><th rowspan="2">Curatif</th></tr><tr><th>avec rupture</th><th>continu</th></tr></thead><tbody><tr><th>Développement</th><td>- Réorganisation de classes<br>- Classification de classes<br>- Correction de classes</td><td>- Versionnement de classes<br>- Migration de caractéristiques</td><td></td></tr><tr><th>Émergence</th><td>Catégorisation</td><td></td><td>Notre modèle</td></tr></tbody></table>

En ce qui concerne notre approche d'émergence curative, pouvons-nous utiliser uniquement des opérations de ces deux taxonomies ? Pour pouvoir répondre à cette
question, nous rappelons les objectifs que nous nous sommes fixés jusque là (chapitre 1). Ces objectifs sont classés par ordre décroissant, du plus conceptuel au plus 'technique':

- Offrir un modèle pour la simulation d'évolution,

- À partir de l'évolution dynamique de la structure d'instances.

- Pour cela, il faut tirer parti d'une part des structures véhiculées par les instances (qui ne sont probablement plus entièrement conformes aux classes existantes) et des informations déjà connues, donc des structures existantes. L'objectif est de trouver d'éventuelles nouvelles structures, en combinant celles précédemment citées,

- Comment les combiner ? Comment varier les solutions tout en assurant un minimum de cohérence et de sémantique pour ces solutions ? Car il faut en effet arriver à faire émerger plusieurs structures potentiellement candidates,

- Il faut ensuite faire un choix et répercuter les conséquences de ce choix dans la hiérarchie de classes existante.

- Il apparaît que nous pouvons avoir recours à quelques-unes des opérations, voire à l'ensemble des opérations de modifications lors de la modification de la hiérarchie de classes. Nous pouvons également avoir recours aux opérations de base d'ajout et de suppression d'attributs sur des instances existantes. Par contre, aucune ne nous permet de mener la simulation et les résultats escomptés de cette simulation d'évolution à partir de l'évolution d'instances.

Avant d'aborder dans la section 2.7 - comment nous proposons d'aborder l'émergence curative, nous présentons dans la section suivante d'autres stratégies d'évolution :

## 2.6 - Autres travaux portant sur l'Évolution d'Objets

Nous présentons dans cette section quelques stratégies d'évolution connues pour illustrer différentes politiques et techniques d'évolution proposées autres que par modification, avant de faire un bilan aussi bien en termes de limites rencontrées que de positionnement de toutes les stratégies présentées dans le triptyque. Nous parlerons également de quelques stratégies d'évolution de processus simplement à titre illustratif de cette problématique complémentaire à celle du produit.
## 2.6.1. Autres stratégies d'évolution de classes

Nous avons étudié les stratégies d'évolution les plus importantes portant sur l'évolution de produit par modification en section 2.4 - . Nous présentons dans cette section d'autres stratégies d'évolution de classes. Voici, en substance, leur principe, leur avantages et leurs limites :

### 2.6.1.1. Ajustement de classes

**Principe :** elle est principalement utilisée en Intelligence Artificielle et en Génie Logiciel. Elle consiste à adapter légèrement les définitions de classes lorsque ces dernières ne se prêtent pas à une spécialisation aisée. Les définitions existantes des classes ne sont pas directement modifiées et les adaptations sont appliquées aux propriétés héritées au moment de dériver de nouvelles sous-classes. Le but principal est de garder une hiérarchie de classes stable en évitant de la modifier à chaque évolution. Les mécanismes habituellement utilisés sont ceux des langages orientés objet : le renommage d'attributs et de méthodes, la redéfinition de propriétés (types des variables, corps des méthodes et les interfaces de classes) ainsi que la surcharge [Meyer 88].

**Avantages :** l'ajustement est utile pour assurer de légers ajustements, par exemple pour des changements sur la définition d'une classe, tels que le renommage ou la surcharge, dans le but de permettre plus de flexibilité dans la conception, et ce au vu de la rigidité d'une hiérarchie. De plus, elle ne nécessite pas de factorisation de propriétés communes et les techniques utilisées peuvent être facilement implémentées.

**Inconvénients :** cependant, il existe certains risques si l'on ne reste pas vigilant quant à son utilisation. Elle peut mener à des structures de spécialisation incompréhensives et l'utilisateur n'a aucun moyen d'éviter le développement de collections de classes désorganisées. Une utilisation intempestive peut rapidement alourdir et compliquer le graphe de classes.

### 2.6.1.2. Approches de représentations multiples : Points de vue, Rôles, Vues

**Principe :** ces stratégies s'intéressent à l'évolution du comportement. Le but des Points de vue(7) [Bratsberg 93] est de rendre l'évolution d'une classe transparente en représentant son évolution grâce à des points de vue qui reflètent la sémantique. Un point de vue confère sur un objet de nouvelles propriétés qui ne sont pas dérivées de propriétés existantes [Benatallah& 97]. Le concept de Rôle a été introduit pour répondre aux besoins de représentation d'un comportement évolutif et variable d'un
objet et lui permet d'avoir des rôles multiples durant son cycle de vie
[Pernici 91]. Quant aux Vues, elles permettent de représenter différentes
perspectives de la même entité. Elles ont été utilisées pour gérer
l'évolution de schéma [Bertino 92]. Les modifications de schémas ne sont
pas réellement effectuées sur le schéma mais sont simulées par la création
de classes virtuelles.

**Avantages :** leur principal avantage réside dans leur aptitude à permettre d'étendre et d'enrichir la définition de l'entité à modéliser. De plus, le mécanisme est dynamique (les données ne sont pas stockées mais elles sont calculées dès que la vue est utilisée). Elles constituent un outil performant pour la conception incrémentale, principalement parce que l'utilisateur peut modifier le schéma (dans le cas des vues), le rôle et le point de vue (dans le cas respectivement des rôles et des points de vue) sans propagation des modifications dans le schéma/rôle/point de vue partagé par les autres utilisateurs.

**Inconvénients :** l'expression de contraintes sur et entre les points de vues, ou les rôles ou les vues est relativement ardue. Cependant, le mécanisme de vue est généralement insuffisant pour supporter des évolutions de schémas supplémentaires et rencontre des problèmes pour positionner une classe virtuelle dans un schéma.

### 2.6.1.3. Approche par Scénario

**Principe :** c'est une stratégie qui s'inscrit également dans la gestion de l'évolution de processus. Un scénario est un comportement défini pour un ensemble d'objets associé à une classe. Il spécifie les interactions de ces objets avec leur environnement d'exécution. Il permet l'évolution de leur comportement dans le temps, au regard de situations changeantes et imprévisibles. Un scénario est donc défini et attaché à une classe et représente une définition d'un comportement au vu d'un environnement d'exécution [Guetari 95].

**Avantages :** elle est utile pour prendre en compte des changements imprévus étant donné qu'un scénario est décrit en termes de règles qui sont activées selon la situation.

**Inconvénients :** cependant, des contradictions peuvent exister entre des scénarios si certaines règles sont contradictoires entre elles. De plus, le concepteur n'a pas de visibilité globale des différents scénarios.

## 2.6.2. Limites des approches actuelles

Les travaux présentés précédemment montrent qu'il y a actuellement plusieurs propositions, traitant chacune un aspect de l'évolution d'objets suivant le type de
problèmes auxquels est confronté l'utilisateur. La plus large part des stratégies revient
à la gestion de l'évolution des classes. Les différentes stratégies précitées offrent des
techniques pour assurer l'évolution des spécifications de classes ainsi que leurs
répercussions. Chacune d'entre elles présente des avantages et des inconvénients.

Par exemple :

– La réorganisation, la classification ainsi que la catégorisation touchent à la hiérarchie de classes. Elles s'articulent essentiellement autour du repositionnement de classes au sein d'un graphe après l'insertion d'une nouvelle classe.

– La correction, l’ajustement et le versionnement de classes portent, quant à elles, sur la gestion des modifications des spécifications au sein d’une classe. Chacune œuvre à optimiser un aspect du modèle. La première rend la mise à jour des classes effective après tout changement et préserve la cohérence globale. La seconde quant à elle, propose de légers ajustements dans la définition d’une classe. Le versionnement quant à lui garde une trace des évolutions des spécifications d’une classe.

– Enfin, les techniques de l’impact de l’évolution des classes sur les instances et l’évolution des instances elles-mêmes n’offrent pas de stratégies réelles d’évolution mais se contentent uniquement de rendre les instances conformes à la spécification de leurs classes.

L'évolution d'objets est basée sur la prédominance du concept de classe, et par conséquent de son évolution, alors que le concept a été initialement introduit pour représenter et abstraire les caractéristiques d'entités du monde réel. Ces dernières sont représentées par des instances qui sont bien plus bridées que les entités qu'elles représentent. Les changements se font de manière plus naturelle dans la réalité que dans les modèles qui les abstraient. L'évolution d'instances est toujours limitée par celle des classes, un aspect rigide et non naturel de leur évolution.

2.6.3. Second bilan : positionnement des principales stratégies
dans le triptyque

Il est important de noter que nous n'avons présenté que les stratégies d'évolution qui nous semblent pertinentes pour notre travail. Parmi celles-ci, nous avons cité et étudié les stratégies les plus connues et les plus utilisées pour gérer l'évolution de produit. En répondant pour chacune d'entre elles au triplet de questions de la section 2.2.4, nous arrivons à situer les stratégies sur les deux axes *Type d'évolution* et *Processus d'évolution* (selon qu'elles agissent au niveau classe, des classes vers les instances ou au niveau des instances). De la même manière, nous pourrons situer toute stratégie d'évolution par rapport au repère triptyque de l'évolution d'objets en répondant au triplet de question.

Le positionnement des stratégies étudiées donne :
<figure><img src="image_9.png" /><figcaption>Figure 2-4: Seconde classification triptyque des stratégies étudiées.</figcaption></figure>

Nous nous intéressons à la gestion de l'évolution de produit, que ce soit dans un cadre préventif ou curatif, et que ce soit dans le cadre du développement ou de l'émergence. Nous avons pu situer les stratégies d'évolution présentées par rapport aux facettes de l'évolution. Nous mettons en évidence, par le biais de cette illustration des stratégies d'évolution, les aspects de l'évolution d'objets qui sont traités plus ou moins largement dans la littérature de l'évolution d'objets.

Nous abordons dans la section suivante certains travaux de recherche qui présentent des similitudes sur des aspects différents, et parfois ponctuels, avec notre approche et notre problématique. Nous dénommons ces travaux comme étant connexes au nôtre et non pas comme étant forcément relatifs car ne présentant pas les mêmes objectifs ni les mêmes démarches.
2.6.4. Travaux connexes

Nous présentons dans cette section quelques travaux de recherche que nous considérons comme connexes, car ayant un ou plusieurs points communs avec nos travaux.

La problématique de [Segapeli& 99] est l'élaboration d'une méthode de conception permettant de concevoir un schéma objet à partir d'exemples. La méthode permet de définir des spécifications « floues » à partir d'informations connues d'exemples et d'affiner au fur et à mesure dès qu'il y a plus d'informations. Le processus de conception est ainsi incrémental. C'est une méthode d'aide à la construction d'un schéma de classes en permettant de gérer l'imprécision et l'incertitude en ayant recours à la théorie du flou. La méthode se base principalement sur la catégorisation pour l'aspect conception. Les auteurs utilisent des opérateurs et des règles pour modifier le schéma de classes floues et le transformer en un schéma objet. La méthode est d'un intérêt certain pour la conception et la spécification incrémentales faces à des situations imprécises et instables. Cependant, comme la construction se fait à partir des exemples, le schéma de classes en est trop tributaire.

Les travaux de [Li& 94] s'inscrivent dans le cadre de la problématique de l'évolution des bases de données objet. Leur approche est l'adaptation d'un modèle objet aux instances. A notre connaissance, ils représentent l'un des seuls travaux s'intéressant à l'adaptation d'un modèle objet aux instances, mais sans toucher à la structure d'instances existantes. Le principe est de pouvoir tirer profit de ce que veut l'utilisateur pour faire évoluer la base de données grâce à des techniques d'apprentissage. Pour cela, ils définissent un noyau de modèle et un niveau plus élevé. Ils considèrent qu'un objet peut évoluer d'un état à un autre, donc d'un niveau à un autre. Ils proposent un certain nombre de règles et de primitives de manipulation pour assurer ces évolutions.

Le modèle proposé à l'avantage d'avoir été mené à terme depuis la conception jusqu'au développement. Cependant, il nous apparaît que la gestion qu'une évolution nécessite est lourde. De plus, le système ne réagit qu'au cas par cas et de façon tout à fait ponctuelle. Il n'ouvre pas d'horizon pour l'évolution face à des situations de changement imprévues.

Une étude empirique [Li& 98] a montré l'importance et l'impact que peut avoir le niveau d'implémentation sur le niveau conceptuel tout au long du cycle de vie d'une application. En partant des hypothèses que l'évolution du modèle de conception influence l'évolution du modèle d'implémentation, et inversement, les auteurs ont mené cette étude. L'étude s'est particulièrement intéressée aux interactions et influences entre le niveau conceptuel et le niveau implémentation. Il apparaît, entre autres, que le niveau conceptuel a peu d'impacts sur l'évolution du niveau implémentation durant la vie de l'application. Par contre, la croissance du niveau d'implémentation tend à dominer la phase finale du projet, et connaît des besoins d'évolution particulièrement importants. La principale conclusion à laquelle leur étude mène est que la croissance du modèle d'implémentation peut largement influencer l'évolution du modèle de conception.
Astudillo [Astudillo 97] propose une métaphore biologique pour des hiérarchies d'objets, qu'il utilise pour spécifier et construire de manière incrémentale, et organiser les classes et les types séparément et de manière optimale. L'objectif est de permettre une maîtrise de ces spécifications afin d'offrir une évolution et une réutilisabilité plus accrues. Astudillo s'appuie sur des résultats des sciences biologiques et de la théorie des types. Ses travaux de recherche montrent que le monde des objets peut tirer profit des aptitudes naturelles à la fois simples et puissantes qui nous entourent, et de les adapter aux spécificités des objets.

## 2.7 - L'émergence curative : comment ?

Nous considérons les instances, en tant que représentantes d'entités réelles, comme des individus à part entière. Une instance a donc connaissance de ses propres spécificités, et surtout permet l'acquisition de nouvelles connaissances plus adaptées à son nouvel environnement. Elle pourra ainsi s'adapter et faire remonter au niveau conceptuel non seulement des structures conceptuelles mais également une voie possible d'évolution pour les instances issues de la même classe. Cette manière de considérer les instances, induit de facto l'analogie avec des individus vivants, du moins dans certaines de leurs propriétés : celles d'évoluer dans leur environnement en s'y adaptant. Une adaptation d'un individu ne se cantonnera pas à lui seul mais sera répercutée dans son espèce en modifiant son code génétique. Cet individu fera ainsi profiter de son évolution, sa population et sa progéniture.

En effet, dans la Vie Artificielle [Heudin 94], il est question de processus d'évolution d'un individu et de répercussion sur son code génétique. Les Algorithmes Génétiques [Holland 75] considèrent, pour des problèmes d'optimisation combinatoire, les diverses solutions potentielles comme des ensembles d'individus qui évoluent quasi aveuglément dans leur environnement instable et qui se reproduisent jusqu'à aboutir à un ensemble de solutions élitistes. Pour cela, des mécanismes ont été développés en s'appuyant sur ce qui a été observé dans la nature : la sélection naturelle et la reproduction d'individus ; le croisement et la mutation de leur code génétique.

D'un point de vue philosophique, cela revient à un processus d'apprentissage nécessaire et qui se rapporte à l'apprentissage de toute espèce vivante pour s'adapter et survivre. L'évolution, l'adaptation, les mutations se rencontrent à tous les niveaux, aussi bien d'un point de vue psychologique que physiologique que d'un point de vue temporel (une vie, une génération ou toute une espèce).

Nous nous inspirons pour cela des quelques principes et concepts des travaux de l'Évolution Artificielle. L'évolution d'instances et l'adaptation du modèle de classes aux nouveaux besoins permettra l'émergence de nouvelles structures conceptuelles.
## 2.8 - Les travaux de l'Évolution Artificielle

Nous abordons dans cette section l'Évolution Artificielle et ses principes et nous détaillons un peu plus deux principaux axes de recherche de l'Évolution Artificielle : la Vie Artificielle et les Algorithmes Génétiques. Ces travaux nous ont inspirés dans quelques notions et concepts :

### 2.8.1. L'Évolution Artificielle

Nous regroupons sous l'expression *d'Évolution Artificielle* les travaux de recherche qui se sont intéressés à la définition et à la mise en œuvre de systèmes artificiels évolutifs et adaptatifs. Certains de ces travaux s'inspirent de la biologie pour en extraire les capacités d'évolution, et les simuler à des fins différentes sur des supports, principalement l'ordinateur. Ils sont également dénommés *Algorithmes Évolutionnaires* car ils s'inspirent du concept de *sélection naturelle* élaboré par Charles Darwin. Les notions, entres autres, d'*individus* (solutions potentielles), de *population*, de *gènes* (variables), de *chromosomes*, de *parents*, de *descendants*, de *reproduction* et de *mutations* sont manipulées. Le point clef est l'apparition, par hasard, de variations individuelles. La Vie Artificielle et les Algorithmes Génétiques s'inscrivent dans cette lignée [Langton& 90] et servent de support à cette étude.

### 2.8.2. Principe général

Le principe général est esquissé par la figure suivante, avec l'image de Darwin en filigrane qui rappelle la source d'inspiration :

<figure><img src="image_10.png" /></figure>
Figure 2-5: Principe Général d'un algorithme évolutionnaire.

La Figure 2-5 présente l'organigramme d'un algorithme évolutionnaire. Il s'agit de simuler l'évolution d'une population d'individus divers (généralement tirée aléatoirement au départ) à laquelle on applique différents opérateurs (recombinaisons, mutations...) et que l'on soumet à une sélection, à chaque génération. Si la sélection s'opère à partir de l'adaptation, alors la population tend à s'améliorer. Un tel algorithme ne nécessite aucune connaissance du problème : on peut représenter celui-ci par une boîte noire comportant des entrées (les variables) et des sorties (les fonctions objectif). L'algorithme ne fait que manipuler les entrées, lire les sorties, manipuler à nouveau les entrées de façon à améliorer les sorties, etc.

### 2.8.2.1. La Vie Artificielle

> « ...Les modèles de la Vie Artificielle ... sont suffisamment puissants pour capturer une majeure partie de la complexité de systèmes vivants, déjà sous une forme plus aisément manipulable, répétitive, et sujette à des contrôles expérimentaux plus précis que ne peuvent l'être les systèmes naturels correspondants. » C. Taylor et D. Jefferson. 'Artificial Life as a tool for biological inquiry'. Artificial Life Journal, Volume 1, Number 1/2, Pages 1-13, 1994. The MIT Press, Cambridge, MA.

#### 1) - Définition

La Vie Artificielle est un domaine de recherche récent. Le premier workshop a eu lieu en 1987 à Los Alamos (USA), avant de devenir le sujet de conférences internationales. Son principal objectif est la simulation et la synthèse des phénomènes biologiques. Elle repose sur l'abstraction des propriétés caractéristiques des êtres vivants, puis sur leur implémentation sur des supports arbitraires. Elle s'efforce ainsi à la compréhension de la vie en essayant de généraliser les principes sous-jacents aux phénomènes biologiques et de recréer ces principes. La Vie Artificielle propose pour cela une démarche en deux étapes. Dans un premier temps, elle tente d'abstraire les principes fondamentaux du vivant. Dans un second temps, elle 'réalise' ces principes sur un support arbitraire, l'ordinateur par exemple.

Elle s'intéresse aux processus d'évolution et elle est considérée comme la science des propriétés émergentes. En effet, du fait de leurs interactions, un ensemble de structures engendre des propriétés qui ne résultent pas de la simple superposition de leurs contributions individuelles mais donne également naissance spontanément à de nouvelles propriétés globales, absentes au niveau des structures prises indépendamment.

#### 2) - Concepts

Aussi, pour prendre en compte les processus d'évolution, les notions de GTYPE et de PTYPE ont été empruntées respectivement au génotype et au phénotype de la biologie [Heudin 94] :
– Le génotype correspond à l'ensemble des informations génétiques encodées dans l'ADN.

– Le phénotype est l'organisme lui-même, autrement dit la structure qui émerge du développement du génotype dans le milieu environnant. Le processus du déploiement du phénotype est plus connu sous le nom de *morphogenèse*.

La Vie Artificielle généralise ces deux notions. Elle définit un génotype généralisé, appelé GTYPE et un phénotype généralisé, appelé PTYPE :

– Le GTYPE correspond à l'ensemble des informations génétiques d'un système étudié. Ses informations sont encodées sous forme de gènes au sein de chromosomes.

– Le PTYPE est constitué des individus représentatifs d'un système étudié et qui sont la réalisation du GTYPE dans un environnement donné.

### 3) - *Principes d'évolution*

Heudin [Heudin 94] précise qu'il est généralement impossible de prédire un PTYPE par une simple inspection d'un GTYPE et des données initiales de l'environnement... De la même manière, il est très difficile de spécifier les modifications à apporter à un GTYPE pour obtenir un résultat particulier au niveau de son PTYPE. La seule façon générale et efficace de procéder est d'exécuter le programme dans un processus itératif d'essais et de corrections d'erreurs. Ce processus est proche du principe de sélection naturelle ... En retour, cette imprévisibilité fondamentale autorise une grande richesse de variétés possibles des PTYPE.

Le GTYPE et le PTYPE sont sans cesse en interaction pour s'enrichir et s'adapter. Cela se fait au travers de processus de *développement* (souvent décrit dans la littérature comme la *morphogenèse*) et d'émergence<fnref n="4" /> :

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

<footnote n="4">⁴ Dans la littérature de la Vie Artificielle, le processus d'émergence est souvent dénommé *Reproduction*. Quant à nous, le choix se porte sur le terme d'émergence, au lieu du terme *reproduction*, pour éviter toute confusion avec le mécanisme de reproduction des algorithmes génétiques.</footnote>
<caption>Figure 2-6: les deux processus fondamentaux entre GTYPE et PTYPE</caption>

- Le processus de *développement* décrit le développement du GTYPE pour créer de nouveaux individus et enrichir le PTYPE.

- Le processus d'émergence décrit l'émergence de nouvelles propriétés au niveau des individus, donc du PTYPE, et qui doivent être insérées dans le GTYPE. Il est basé sur les connaissances détenues de l'espèce, de l'environnement et du contexte ponctuel.

Trois types d'Algorithmes Évolutionnaires ont été développés isolément et à peu près simultanément, dans les années 60, par différentes communautés scientifiques : les Algorithmes Génétiques, les Stratégies d'Évolution, et la Programmation Évolutionnaire. Nous nous sommes plus précisément intéressés aux Algorithmes Génétiques. Les raisons de notre choix sont explicitées au travers de la définition que nous donnons des Algorithmes Génétiques :

### 2.8.2.2. Les Algorithmes Génétiques

Inspirés de la théorie de l'évolution par sélection naturelle, les Algorithmes Génétiques [Holland 75] s'adaptent particulièrement aux besoins d'amélioration ou plus exactement de recherche de meilleures solutions à un problème donné, dans un processus itératif. Ce type d'algorithmes évolutionnistes a été appliqué à des problèmes d'optimisation combinatoire. Cependant, ils ont rarement été utilisés pour étudier l'évolution en elle-même. En effet, les chercheurs se focalisent plutôt sur les résultats que sur le processus d'évolution en lui-même, pourtant bien prometteur.

#### 1) - Définition

Les Algorithmes Génétiques appartiennent à la classe des algorithmes basés sur l'émergence. Les Algorithmes Génétiques sont, compte tenu de leurs caractéristiques, particulièrement adaptés au problème de l'optimisation des configurations pour lesquelles l'univers des solutions potentielles est trop complexe à explorer par heuristiques, itératives ou non, « déductives » ou de calculs inverses [Holland 75].

Holland a formalisé les principes fondamentaux des Algorithmes Génétiques, dont voici la synthèse :

- La capacité de représentations élémentaires, comme les chaînes de bits, à coder des structures complexes.

- Le pouvoir de transformations élémentaires à améliorer de telles structures.

Plus récemment, Goldberg [Goldberg 94] enrichit la théorie des algorithmes génétiques. Il s'appuya sur le parallèle suivant:

- Un individu est lié à un environnement par son code génétique.

- Une solution est liée à un problème par sa valeur d'adaptation.
Une « bonne » solution à un problème donné peut être vue comme un individu susceptible de survivre dans un environnement donné.

L'étude des Algorithmes Génétiques est motivée par deux objectifs. Le premier est de tenter d'expliquer le processus d'évolution et d'adaptation des systèmes naturels. Le second est d'utiliser ce processus pour la conception de systèmes artificiels plus robustes, c'est-à-dire capables de s'adapter aux perturbations de l'environnement. Ils associent, pour cela, la diversité du hasard et la survie du plus adapté. Par ailleurs, les Algorithmes Génétiques permettent de produire toute une population de solutions potentielles. Ils réalisent ainsi une recherche multidirectionnelle tout en encourageant la formation de nouvelles solutions et l'échange d'information parmi ces solutions. La population subit une évolution à chaque génération, au cours de laquelle les solutions relativement acceptables se reproduisent tandis que les autres disparaissent. Les différents « morceaux » constituant la bonne solution se propagent d'une manière exponentielle au sein de la population (c'est le parallélisme implicite). Une fonction d'évaluation, représentant l'environnement et caractéristique du domaine applicatif traité, permet de différencier les solutions.

## 2) - Concepts

L'algorithme génétique de base repose sur la représentation binaire. Ce choix le rend virtuellement applicable à tous les problèmes dont les solutions sont transposables en binaire. Il emploie par ailleurs les mécanismes élémentaires de la théorie des algorithmes génétiques. La terminologie employée est empruntée à la génétique :

- Les *chromosomes* sont les éléments à partir desquels sont élaborés les solutions.

- La *population* est l'ensemble des chromosomes. Les populations sont également appelées des générations.

- La *reproduction* est l'étape de combinaison des chromosomes. La *mutation* et le *croisement génétique* sont des méthodes de reproduction.

D'autres notions sont propres au domaine des algorithmes génétiques :

- La *valeur d'adaptation*, aussi appelé indice de performance, est une mesure abstraite permettant de classer les chromosomes par ordre décroissant en tant que solution à un problème.

- La *fonction d'adaptation* est la formule théorique qui permet de calculer la valeur d'adaptation d'un chromosome.

## 3) - Principes d'évolution

Le principe de fonctionnement peut être résumé en la recherche du maximum d'une fonction du type y=f(x). Un algorithme génétique travaille à partir d'un ensemble d'éléments choisis au hasard dans un espace de solutions potentielles. Sa connaissance du problème à résoudre se résume à une fonction d'évaluation qui mesure la qualité d'un élément en tant que solution au problème. L'algorithme génétique tire partie des meilleurs éléments à sa disposition pour fabriquer de toutes pièces un nouvel ensemble d'éléments répondant en moyenne de mieux en mieux au problème.
## Fonctionnement Général

1. Création de la population initiale.

2. Évaluation de chacun des chromosomes de la population initiale.

3. Sélection et regroupement des chromosomes par paires.

4. Application du croisement et de la mutation à chacune des paires.

5. Évaluation des nouveaux chromosomes et insertion dans la population suivante.

6. Si le critère d'arrêt est atteint, l'algorithme génétique s'arrête et rend le meilleur chromosome produit; sinon, l'algorithme retourne à l'étape 3.

Pour passer de l'ancien au nouvel ensemble, les éléments sont sélectionnés aléatoirement et proportionnellement à leur qualité en tant que solution au problème. Si un élément est retenu, il contribuera à améliorer les éléments du nouvel ensemble. Dans le cas contraire, il est irrémédiablement perdu pour les ensembles futurs. Les éléments sélectionnés sont ensuite combinés en de nouveaux éléments grâce à des méthodes inspirées de phénomènes naturels, comme le croisement génétique ou la mutation.

L'algorithme génétique travaille ensuite par générations successives jusqu'à un critère d'arrêt :

- soit le temps imparti est écoulé,

- soit le meilleur élément de la dernière génération atteint un seuil de qualité fixé au départ.

Ces différentes étapes se répartissent en deux phases, sur lesquelles les Algorithmes Génétiques opèrent [Goldberg 94] :

- L'exploration des différentes solutions possibles à la recherche des meilleures ;

- L'exploitation des résultats de ces recherches. Ils opèrent sur des individus (espaces de solutions) ayant un code génétique.

Ces individus ont la caractéristique d'évoluer « aveuglément » en se reproduisant et en perpétuant les meilleurs gènes au travers des individus porteurs. Pour les mener à bien, des mécanismes génétiques sont utilisés :

- La sélection aléatoire d'individus adaptés : la sélection des codes génétiques les plus adaptés implique la mesure quantitative de cette adaptation dite valeur d'adaptation grâce à une fonction d'adaptation. Une des idées directrices des algorithmes génétiques est donc d'affecter une probabilité de sélection supérieure aux meilleurs individus et, inversement, d'éliminer au fur et à mesure les plus mauvais. La performance d'un individu correspond aux capacités d'adaptation qu'il développe vis à
vis du monde dans lequel il évolue. La performance de l'individu est directement liée à
la valeur de la fonction d'adaptation aux coordonnées de son phénotype.

<figure><img src="image_12.png" /><figcaption>Figure 2-7: Le processus de sélection</figcaption></figure>

- Le croisement du code génétique de ces individus pour récupérer les meilleurs gènes : l'opérateur de croisement peut être perçu comme une méthode de brassage des codes génétiques des différents individus. Elle consiste en fait à couper et à mélanger les différents patrimoines génétiques et, en alliance avec la sélection, à favoriser les meilleurs. Il existe plusieurs sortes de croisement. Le croisement binaire s'applique à une paire de chromosomes. Il est également appelé 'croisement binaire à 1 point' car les chromosomes se croisent autour d'une seule position appelée 'point de croisement'. Le point de croisement est positionné au hasard sur les chromosomes. Les bits à droite du point de croisement sont ensuite échangés pour former les deux nouveaux chromosomes.

<figure><img src="image_13.png" /><figcaption>Figure 2-8: croisement à un point</figcaption></figure>

- Il existe une variante, appelée croisement à n points, où les bits sont échangés entre les n points de croisement.
<figure><img src="image_14.png" /><figcaption>Figure 2-9: exemple d'un croisement à deux points.</figcaption></figure>

- L'intérêt du croisement est de combiner les différents patrimoines génétiques de différents individus.

- La *mutation* pour faire muter favorablement un gène : contrairement au croisement, la mutation intervient sur un gène. Elle consiste à introduire une valeur aléatoire sur une position donnée, avec une probabilité assez faible d'intervenir.

<figure><img src="image_15.png" /><figcaption>Figure 2-10: la mutation d'un gène au sein d'un chromosome</figcaption></figure>

L'opérateur de mutation s'apparente à un apport de nouvelles données génétiques. Il permet en fait de faire réapparaître des gènes qui n'ont pas été sélectionnés au départ mais qui peuvent être performants par la suite.

- Les *schèmes* : un schème est une entité ayant la même structure génétique que la population qu'il représente. Il permet de spécifier un sous-ensemble de gènes d'une population. Ainsi, le schème `11###` permet de représenter les individus d'une population donnée ayant les deux premiers gènes présents. Les gènes non spécifiés (les trois derniers dans l'exemple) sont considérés comme indifférents. Le schème est un moyen à la fois simple et puissant pour modéliser en même temps un ensemble d'individus.

### 2.8.3. Conclusion

Nous proposons dans ce chapitre une approche originale consistant à aborder l'évolution d'objets sous un angle d'évolution artificielle. L'évolution des classes a été
largement traitée. Par contre, la réflexion portant sur les instances en tant qu'individus capables d'évoluer reste à définir et à approfondir. Pour cela, nous considérons un modèle à objets comme étant un système se mouvant et évoluant dans un environnement donné. L'objet devra, de manière générale, évoluer et s'adapter en se basant sur sa propre connaissance et sur les perturbations émanant de l'environnement sans cesse instable.

Compte tenu du rôle des classes (respectivement GTYPE) et des instances (respectivement PTYPE) dans la modélisation d'un système réel ou artificiel, nous assimilons donc une classe à un génotype et une instance à un phénotype. Nous proposons d'expliciter le processus général d'évolution d'un modèle objet dans une boucle rétroactive et itérative sous l'optique de l'Évolution Artificielle en s'inspirant de [Heudin 94].

<figure><img src="image_16.png" /><figcaption>Figure 2-11. Processus d'Évolution d'Objets sous l'optique de l'Évolution Artificielle</figcaption></figure>

Nous considérons l'ensemble des instances d'une classe comme son phénotype<fnref n="5" />, et par conséquent que les gènes de l'instance sont ceux définis dans sa classe. Une classe, comme tout génotype, peut être modifiée par des mutations et des recombinaisons. Une instance est créée et modifiée à partir de sa (ses) classe(s) dans le *Processus de Développement*. Une classe peut être créée et modifiée à partir de l'expression de nouvelles caractéristiques au sein des instances dans le *Processus d'Émergence*.

A notre connaissance, peu de travaux de recherche ont combiné les approches basées sur le paradigme objet et sur la Vie Artificielle ([Astudillo 97], [Meslati& 97]). Il nous

<footnote n="5">⁵ Une instance est une réalisation d'une classe de la même manière qu'un phénotype est une réalisation d'un génotype.</footnote>
semble que cette nouvelle voie est prometteuse dans l'analyse et la conception de l'évolution d'objets, et peut fournir, somme toute, de nouveaux outils de modélisation et de simulation de systèmes complexes.

## 2.9 - Conclusion

Nous avons abordé plusieurs aspects dans le présent chapitre. Un des premiers aspects a été de proposer une classification de l'évolution d'objets par rapport à ses caractéristiques que nous avons dénommées *facettes*, qui sont au nombre de trois : l'objet de l'évolution, le type de l'évolution ainsi que le processus de l'évolution. La classification de l'évolution d'objets par rapport à ces facettes permet d'offrir un référentiel commun et indépendant des stratégies d'évolution. Chaque stratégie peut être positionnée par rapport à ce référentiel triptyque en précisant sur quel élément de chaque facette elle agit.

Par la suite, notre intérêt s'est principalement porté sur l'évolution de produit (classes - hiérarchies de classes - instances). Nous avons présenté certaines des stratégies d'évolution, chacune dans son principe (politique d'évolution et domaine d'utilisation), ses avantages et ses limites. Ces stratégies sont présentées selon qu'elles agissent au niveau classe, des classes vers les instances ou sur les instances. Par la suite, nous avons classifié ces stratégies par rapport aux facettes de l'évolution de produit. La principale conclusion est que la majorité des stratégies d'évolution font du préventif, et ce dans le cadre du développement. Notre approche, qui se veut complémentaire des stratégies d'évolution existantes, s'intéresse à faire de l'évolution de produit principalement de manière curative et principalement dans le cadre de l'émergence.

Nous nous sommes focalisés, par la suite, aux mécanismes d'évolution proposés par les stratégies d'évolution basées sur la modification de hiérarchies de classes. Nous dégageons une taxonomie des opérations de base et une taxonomie des opérations avancées. Cette taxonomie permet de définir de façon opératoire comment s'applique la politique de ces stratégies et dans quelle séquence. Elle permet également de décrire le type de l'évolution et le processus d'évolution.

Comme nous proposons un modèle pour la simulation d'évolution à partir de l'évolution dynamique dans la structure d'instances, nous remarquons que la taxonomie des opérations ne nous suffit pas pour mener à bien nos objectifs. Elle est utile en amont et en aval de la simulation mais s'avère insuffisante pour la manipulation dynamique de la structure des instances et surtout pour la simulation d'évolution. Pour cela, il est nécessaire de définir un modèle objet en gardant les avantages de la modélisation objet mais en l'étendant (en termes de concepts et de mécanismes) pour supporter une évolution de produit curative dans le cadre de l'émergence. Comment ? En s'inspirant des travaux de l'Évolution Artificielle qui considèrent et permettent aux individus d'évoluer et de s'adapter en perpétuant les meilleurs individus, donc les meilleures combinaisons génétiques. Le tout dans un but
de survie et d'adaptation à un environnement méconnu et instable. En effet, les changements se font de manière plus naturelle dans la réalité que dans les modèles objets qui les représentent, alors que l'approche objet est basée sur la prédominance du concept de classe.

Nous allons voir dans le chapitre suivant comment définir notre modèle.
# Chapitre 3 : GENOME : LES CONCEPTS

<figure><img src="image_17.png" /></figure>
## 3.1 - Introduction

Pour gérer l'évolution d'objets au vu de notre problématique et de nos objectifs, nous proposons un modèle. Nous dénommons ce modèle objet GENOME pour Génétique pour l'EvolutioN Objet et ModèlE ou encore Genetic EvolutioN Object ModEl.

Nous abordons dans le présent chapitre la présentation et la définition des différents concepts de GENOME. Pour mieux les comprendre, nous introduisons en premier les préliminaires nécessaires pour présenter les processus d'évolution de GENOME.

Il est important de noter que nous nous basons sur un modèle objet classique s'appuyant sur les concepts de base que sont la classe, l'instance, l'héritage simple, l'attribut (simple, composé ou de référence) et la méthode. Nous nous basons sur des concepts de langages orientés objet existants et nous voulons les étendre pour prendre en compte l'évolution dynamique de la structure d'instance. Cette évolution se fait sous l'influence des perturbations émanant de l'environnement et peut provoquer des modifications dans la hiérarchie de classes existante. Nous considérons que ces perturbations sont exprimées et répercutées par la main du concepteur ayant la charge de la gestion de l'application. Pour véhiculer nos objectifs, nous enrichissons certains de ces concepts et les complétons en leur associant de nouveaux concepts.

Étant donné que nous abordons l'évolution de la structure d'instances avec des répercussions sur la hiérarchie de classes, nous avons proposé de considérer les instances comme des individus ayant la possibilité d'agir sur leurs caractéristiques, donc sur leur 'patrimoine génétique'. Pour cela, la notion la plus importante à introduire et à prendre en compte dans GENOME est celle de **mémoire génétique**, ainsi que sa perpétuation partielle ou totale selon les besoins d'adaptation.
Cette notion de mémoire génétique est en effet importante car elle permet d'une part l'éclosion, l'existence et la fin d'individus, et d'autre part elle peut être modifiée par recombinations et mutations grâce à la capacité des individus à s'adapter.

Cette notion de mémoire génétique se décline de diverses manières. Nous considérons qu'il existe trois entités qui la véhiculent entièrement :

- Il y a avant tout l'**espèce** considérée. Celle-ci regroupe les gènes communs à tous ses individus. Elle se perpétue par leur biais (par reproduction en biologie, par exemple). Ce groupe de gènes communs est donc l'essence même de la définition de l'espèce et justifie ainsi l'appartenance d'un individu ou non en son sein. Une **population** d'une espèce est constituée d'un ensemble d'individus existants sur une période donnée.

- Ensuite, il y a ce qui caractérise un peu plus les individus entre eux. Des groupes d'individus d'une même espèce présentent tout de même des différences. Outre l'appartenance à la même espèce, des individus peuvent avoir des similitudes plus ou moins nuancées qui les regroupent. Elles sont véhiculées par les gènes transmis par leurs **ancêtres**. Cette mémoire, ajoutée à celle commune de l'espèce, permet de définir tout l'héritage d'un individu.

- Enfin, il y a ce qui caractérise chaque **individu**, en plus de son appartenance à une espèce et à ses ascendants, les caractéristiques qui lui sont propres et uniques. Ce qui permet d'assurer la diversité et la richesse de toute une population, et voire même de toute une espèce.

Nous considérons qu'il est important de représenter et d'abstraire correctement ces différentes notions au travers de concepts et de pouvoir les manipuler. C'est ce qui fait l'objet de ce chapitre :

## 3.2 - Exemple

Pour illustrer au fur et à mesure les concepts, nous nous basons sur un exemple didactique modélisant les différents membres d'une université. Le modèle de classes suivant représente, à un instant donné, le modèle objet qui en a été abstrait :
<figure><img src="image_18.png" /><figcaption>Figure 3-1: un exemple de modélisation des membres d'une université</figcaption></figure>

Les différentes classes constituant les membres d'une université sont représentées. Celles-ci sont en relation avec d'autres classes (Thème-Recherche, Laboratoire, Module, Equipe ou encore Projet) ne représentant pas des membres d'université, mais elles appartiennent au système global. Elles peuvent donc être considérées comme faisant partie de l'environnement des membres d'une université.

La conception faite (qui est rarement unique et rarement stable au premier jet) met en évidence la classe Membre-Université. Celle-ci regroupe les caractéristiques communes à tous les membres. Elle constitue ainsi la racine de la hiérarchie d'héritage. Elle représente une population de l'espèce Membre-Université. Il est à noter que nous représentons uniquement les attributs. Les méthodes sont masquées, premièrement pour des raisons de lisibilité et deuxièmement nous rappelons que nous travaillons essentiellement sur les attributs.

Le modèle obtenu met également en évidence trois principaux membres d'université : Administratif, Enseignant et Chercheur. Chacun étant représenté par une classe.

Les chercheurs se scindent en Chercheurs Temporaires et Chercheurs Permanents. La principale distinction se fait sur la base de la durée de la présence du chercheur au sein de l'université :

- Un chercheur permanent est potentiellement à l'université de manière illimitée dans le temps (jusqu'à la démission, la retraite ou le décès). C'est
pour cela que seul l'attribut 'Date-Début' est défini pour représenter la date de prise de fonction. Pour l'instant, la classe *Senior-Chercheur* est la seule modélisée.

- Un chercheur temporaire est présent pour un laps de temps précis, représenté par l'attribut *Durée*. Il n'y a pas de distinction faite sur son statut d'étudiant, de salarié ou autre. Deux classes sont représentées :

- les *ATER*, qui en plus de leur recherche, assurent des enseignements ;

- les *Elèves-Chercheurs* qui travaillent sous la direction d'un directeur de thèse.

Une contrainte est également posée par le concepteur. Il précise en effet que l'attribut *'Durée'* défini dans *Temporaire* et l'attribut *'Date-Début'* défini dans *Permanent* sont contradictoires, c'est-à-dire qu'un membre de l'université ne peut pas valuer les deux attributs en même temps.

Nous donnons dans la suite les notions, concepts et définitions de base de GENOME :

## 3.3 - Préliminaire des processus d'évolution

Les principales notions que nous introduisons dans l'évolution d'objets sont celles d'émergence et de développement, préalablement introduites dans le chapitre 2. Elles représentent en effet l'une des trois facettes de l'évolution d'objets : la facette *Processus d'évolution*. Ces notions sont empruntées à la Vie Artificielle (chapitre 2).

Nous rappelons que nous nous intéressons à l'évolution de produit. Nous considérons que toute évolution du produit est soit un processus de développement, soit un processus d'émergence.

### 3.3.1. Le développement

Le développement est un processus qui permet l'évolution d'un modèle en modifiant les structures conceptuelles détenues par les classes, avec tous les impacts engendrés comme conséquence sur les classes et les instances concernées. Nous reviendrons plus loin (chapitre 4) sur le détail de la définition suivante (introduite dans le chapitre 2) : il s'agit du développement des classes en intention (leurs spécifications ainsi que celles des classes concernées) et en extension (les instances existantes et concernées).
### 3.3.2. L'émergence

L'émergence est un processus qui permet l'évolution des structures conceptuelles d'un modèle comme conséquence de l'évolution de la structure de ses instances. Nous reviendrons plus loin (chapitre 4) sur le détail de la définition suivante (introduite dans le chapitre 2) : il s'agit d'émergence de nouvelles informations conceptuelles à partir de l'évolution d'instances.

Ces deux processus de développement et d'émergence se complètent et couvrent ainsi tout le cycle d'évolution d'un modèle objet. Ils peuvent également s' interpeller pour se compléter. Nous verrons (chapitre 4) que l'émergence fait appel au développement afin d'assurer la gestion des impacts de l'émergence.

Nous présentons les concepts du modèle GENOME. Nous distinguons des concepts de base et des concepts avancés.

## 3.4 - Les concepts de base

Les concepts de base sont plus une manière de considérer les concepts objets classiques que la définition de nouveaux concepts à proprement parler. Nos concepts de base sont les concepts objets classiques (que sont l'attribut et la méthode, la classe ainsi que l'instance) vus au travers des concepts et des notions générales, et parfois philosophiques, de l'Évolution Artificielle.

Nous estimons en effet que les concepts objets se prêtent bien à une telle interprétation. C'est ainsi que nous empruntons le rôle des concepts de gène, de GTYPE, de PTYPE ainsi que les notions de population et de patrimoine génétique à l'Évolution Artificielle pour les adapter et les étendre au formalisme objet (classe/instance).

### 3.4.1. Gène

Un gène est toute propriété structurelle (attribut ou variable d'instance) ou comportementale (méthode) pouvant être définie dans une classe et permettant ainsi de spécifier une caractéristique des instances (directes ou indirectes) de cette classe. C'est le concept élémentaire dans GENOME. Ainsi, chacun des attributs *Num-Identification*, *Nom* et *Prénom* est un gène défini dans la classe *Membre-Université* de l'exemple en Figure 3-1.
### 3.4.2. Classe-GTYPE

Le rôle d'une classe est de regrouper les similarités d'un groupe d'objets, tous décrits par les mêmes variables d'instances et répondant aux même messages. Une classe regroupe donc des gènes. Elle définit le code génétique de ses instances. Une classe peut ne pas avoir d'instances, du moins de manière directe (classe abstraite). Les propriétés qu'elle définit sont toutefois généralement transmises, par héritage, dans des sous-classes.

Une classe représente donc le génotype de ses instances. Nous qualifions une classe par une *Classe-GTYPE*, GTYPE par analogie au GTYPE de la Vie Artificielle. Ainsi, la classe Enseignant de l'exemple en Figure 3-1 détient les gènes, donc le génotype, de toutes ses instances.

Par souci de simplicité, nous utilisons parfois dans la suite du manuscrit le terme de *classe* en lieu et place du terme *classe-GTYPE*.

### 3.4.3. Instance-PTYPE

Le rôle d'une instance est de représenter une entité donnée du système modélisé. Elle est rattachée à une classe dont elle prend les attributs qu'elle value, et dont elle dépend en terme de comportement. Elle représente l'**individu** présenté en introduction.

Une instance est donc une réalisation d'une classe dans un environnement et un contexte donnés. Elle sera moulée et réagira selon ce qui a été défini dans sa classe d'appartenance et des ancêtres de celle-ci. Nous qualifierons une instance par une *Instance-PTYPE*, PTYPE par analogie au PTYPE de la Vie Artificielle. Ainsi, les objets $O_4$et $O_5$ de l'exemple en Figure 3-1 sont des instances-PTYPE de la classe-GTYPE Ater.

Par souci de simplicité, nous utilisons parfois dans la suite du manuscrit le terme d'Instance en lieu et place du terme *Instance-PTYPE*.

### 3.4.4. Population et Patrimoine Génétique

Une **population** est constituée d'un ensemble d'individus ayant un patrimoine génétique. Ce patrimoine génétique présente une partie commune à tous ces individus et identifie la population, donc l'**espèce**. Certains individus partagent en outre une partie de ce patrimoine qui est un héritage de leurs **ancêtres**. Et chaque individu peut introduire en plus quelques gènes dans ce patrimoine.

D'un point de vue objet, et en l'occurrence dans GENOME, une **population** est représentée par une classe qui est généralement la racine d'une hiérarchie de classes, et qui détient tous les gènes communs à cette hiérarchie (cf. section 3.5 - pour plus de détails sur les différents types de gènes). C'est le cas de la classe *Membre-Université* de l'exemple en Figure 3-1. L'ensemble des individus est l'ensemble des instances-PTYPE. Le patrimoine génétique est réparti dans les différentes classes-GTYPE. Ce que les
individus peuvent hériter de leurs ancêtres est transmis par le lien d'héritage d'un **ancêtre**, en fait une super-classe, vers un de ses éventuels descendants, en fait une de ses **sous-classes**. Ainsi, la classe Chercheur de la Figure 3-1 est l'ancêtre direct de la classe Temporaire et de la classe Permanent, qui sont à leur tour des ancêtres d'autres sous-classes. Enfin, ce qui caractérise directement un groupe d'individus, donc d'instances, est défini dans leur classe. Ainsi, la classe Ater de la Figure 3-1 introduit le **gène**, donc l'attribut, Nbr-Heures qui le distingue de la classe Eleve-Chercheur. De plus, un individu peut avoir des valeurs différentes.

- **Patrimoine Génétique** : l'ensemble des gènes définis par les classes d'une population constitue le *Patrimoine Génétique* de la dite population. Toute instance de la population prendra ses gènes dans la partie de ce patrimoine définie par sa classe. Nous considérons également que toute instance qui évolue au sein de la population peut potentiellement perdre un de ces gènes (qu'elle a déjà) et qu'elle peut potentiellement acquérir des gènes existants parmi ceux du patrimoine, même s'ils ne sont pas définis par sa classe. Elle peut en outre introduire de nouveaux gènes.

Pour délimiter une population, le choix est fait durant la phase de conception. Il peut être subjectif car il est laissé à l'appréciation du (ou des) concepteur(s). De la même manière que des choix sont faits pour délimiter et définir une classe, la délimitation et la définition d'une population dépendra des choix de conception faits. Par exemple, le concepteur peut décider de définir une population de *Personnes* puis une sous-population *Membre-Universite*. Un autre choix pourrait être de définir directement la population *Membre-Universite*.

Donc, au vu de toutes ces définitions, notre exemple en Figure 3-1 représente la population *Membres-Université*. La classe *Membre-Université* est la racine de la hiérarchie d'héritage associée et elle est composée de plusieurs classes et d'un ensemble d'instances.

Nous abordons maintenant la définition des concepts avancés du modèle GENOME :

## 3.5 - Les concepts avancés

Les concepts avancés sont de nouveaux concepts que nous proposons. Ils enrichissent et complètent les concepts de base et constituent un support pour gérer l'évolution. Nous distinguons les trois concepts avancés qui traitent du concept de classe-GTYPE et du concept avancé de schème.

Une classe définit le génotype de l'ensemble de ses instances. Chaque gène ne joue pas le même rôle et n'a pas la même prédominance ni dans la sémantique qu'il porte ni
dans l'influence qu'il peut avoir sur l'évolution des instances, ni sur la spécification d'éventuels descendants.

Au vu de nos objectifs et des notions d'espèce et de population, d'ancêtre et d'individu, nous considérons que toute classe est entièrement spécifiée au travers de trois génotypes. Chaque génotype étant constitué d'un ensemble de gènes.

### 3.5.1. Génotype Fondamental

#### 3.5.1.1. Définition

D'un point de vue biologique, toute espèce du monde présente des caractéristiques fondamentales qui font sa raison d'être. Ses individus y répondent forcément tous. Autrement, ils ne pourraient pas être de cette espèce.

D'un point de vue de la modélisation objet, toute population est définie par un ensemble précis de gènes. Toutes ses classes détiennent ce même ensemble de gènes fondamentaux. Ces caractéristiques sont représentées par des gènes particuliers représentant la sémantique minimale et nécessaire sans laquelle un objet de chacune de ces classes ne peut plus appartenir à la population. Nous dénommons ce groupe de gènes le *Génotype Fondamental* ou GF. Ainsi, les trois propriétés *Num-Identification*, *Nom* et *Prénom* constituent le *Génotype Fondamental* de la population *Membre-Université*. C'est le **Génotype Fondamental** qui représente en fait l'**espèce**.

Nous faisons toutefois remarquer qu'une classe qui introduit le GF d'une population, peut également avoir comme toute autre classe, d'autres types de gènes (sections 3.5.2 et 3.5.3).

#### 3.5.1.2. Principales propriétés du Génotype Fondamental

Le principal avantage du GF est d'une part de situer conceptuellement toutes les classes (et instances) d'une même population, et d'autre part de cerner l'évolution des instances. Une instance d'une des classes de *Membre-Université* peut évoluer parmi sa population, mais ne pourra pas évoluer en allant à l'encontre de sa propre population vers une autre population. Elle ne pourra pas par exemple devenir une voiture. Le GF constitue une sorte de garde-fou face à des évolutions intempestives et non contrôlées dans leur sémantique.

Une population (section 3.4.4) est donc spécifiée via son GF qui est partagé par l'ensemble de ses classes. Même si les propriétés que définissent les classes d'une population diffèrent, elles ont toutes ce groupe de gènes fondamentaux qui exprime leur appartenance à la même population.

L'existence d'une population passe donc par celui de son GF. Dès que le GF change (par le biais du concepteur) au sein d'une classe ou d'une instance, l'essence même d'une autre population (même vaguement cernée) est en train d'être exprimée.
Comme nous l'avons illustré, le GF est défini au sein d'une classe qui représente la population et qui est la racine de la hiérarchie d'héritage de toutes les classes de cette population. Le GF se transmet à ces classes via le lien d'héritage sans pouvoir être redéfini ou surchargé.

Cette même classe, comme nous l'avons déjà coté, peut définir d'autres gènes qui ne font pas partie du GF. Ces gènes se transmettent également via le lien d'héritage, mais contrairement aux gènes constitutifs du GF, ils peuvent être redéfinis ou surchargés par les sous-classes. Ceci est décrit plus en détails dans les deux sections qui suivent.

### 3.5.2. Génotype Hérité

Le Génotype Hérité ou GH d'une classe représente l'ensemble des gènes hérités de sa super-classe. C'est l'héritage de l'**ancêtre**. Le GH d'une classe constitue l'ensemble des caractéristiques héritées des ancêtres et qui peuvent être adaptées à la classe. Ainsi, comme toutes les propriétés héritées par une classe, celles-ci peuvent être redéfinies et surchargées selon les besoins de conception.

Le Génotype Hérité d'une classe est constitué du génotype hérité de sa super-classe et du génotype spécifique de cette même super-classe (la section 3.5.3. présente le génotype spécifique) :

<figure><img src="image_19.png" /><figcaption>Figure 3-2: relations entre GH et GS</figcaption></figure>

Les classes A, B et C appartenant à la même population. Le GF est donc identique car il définit la population.
### 3.5.3. Génotype Spécifique

Le Génotype Spécifique ou GS est constitué de tous les gènes localement définis au sein d'une classe, qui lui sont donc spécifiques. C'est ce qui caractérise un même groupe d'individus des autres individus de la même population.

Les GH et GS sont issus des spécificités liées à l'environnement et au contexte dans lesquels vivent les individus de la population, alors que le GF correspond aux caractéristiques spécifiques à cette même population, donc de l'espèce.

### 3.5.4. Le schème

Nous introduisons le concept de *schème* comme une entité qui transcrit de manière simple et précise la structure d'une classe ou d'une instance. Nous l'empruntons aux Algorithmes Génétiques dans le cadre desquels un schème est une entité ayant la même structure génétique que la population qu'il représente.

Il permet de spécifier à la fois un sous-ensemble de gènes du patrimoine génétique d'une population ainsi que leur présence ou non. Ainsi, le schème `11#0` permet de représenter à la fois tous les individus d'une population ayant :

- les deux premiers gènes du patrimoine génétique obligatoirement présents ;

- les deux suivants indifférents (ils peuvent être séparément ou en même temps présents ou absents) ;

- le dernier gène obligatoirement absent.

Le schème est un moyen à la fois simple et puissant pour modéliser en même temps un ensemble d'individus répondant à des critères donnés.

Nous le considérons comme l'expression d'une contrainte génétique à laquelle sont soumis les individus et qui permettra d'effectuer sans ambiguïté des choix sur des classes et des instances.

Nous considérons pour cela deux types de schèmes : les *schèmes permanents* et les *schèmes temporaires*. Les premiers sont spécifiés en même temps que les classes. Les seconds sont déclarés et utilisés avec les premiers lors des diverses étapes des processus d'évolution.

#### 3.5.4.1. Schème permanent

A chaque classe lui est associé un schème de manière permanente. Il a une structure identique à la sienne car il exprime le code génétique de ses instances. Un schème permanent comporte par conséquent trois parties : *génotype fondamental*, *génotype hérité* et *génotype spécifique*. A chaque fois qu'une classe est spécifiée, le type de ses propriétés (1 : obligatoirement présente ; 0 : obligatoirement absente ; # : optionnel) est traduit au
sein d'un schème permanent. Il représente une transcription simple de la structure d'une classe et de celle de ses instances. Une instance ne se voit donc pas attribuer de schème permanent, étant donné qu'elle respecte celui de sa classe. Le seul cas où l'instance se voit associer un schème, c'est lorsqu'elle évolue et se démarque de sa classe. Cette situation se présente dans le cadre d'un processus d'évolution, et le schème qui lui est alors associé est dit *schème temporaire*.

### 3.5.4.2. Schème temporaire

Un schème temporaire a la même structure qu'un schème permanent. C'est une unité de sélection d'un ensemble d'entités (instances ou classes) ayant des caractéristiques communes. Un schème temporaire est surtout utile lors de l'évolution d'une instance. Il est utilisé comme un filtre permettant la sélection d'entités adaptées au problème traité. Il permet également de manipuler rapidement et sans confusion classes et instances. Il constitue la base sur laquelle opèrent les processus d'évolution (chapitre 4). Nous verrons par la suite comment le schème est l'entité impliquée dans une compétition avec d'autres entités du même type et comment se feront la sélection et la propagation de gènes.

### 3.5.4.3. Représentation d'un schème

Nous décrivons un schème à l'aide de l'alphabet minimal suivant {0, 1, #}. A chaque fois qu'une classe est spécifiée, le type obligatoire ou optionnel de ses propriétés (attribut/méthode) est traduit au sein d'un schème permanent. La correspondance entre le type d'une propriété et son gène représentant dans le schème est comme suit :

- une propriété obligatoirement présente est représentée par 1 ;

- une propriété dont la présence est optionnelle est représentée par # (ce qui introduit une souplesse dans les spécifications des instances d'une classe) ;

- une propriété obligatoirement absente est représentée par 0 (ce dernier point est particulièrement utile lors des étapes transitoires dans les processus d'évolution).

De par les concepts et les définitions introduites, nous pouvons déduire et donc présenter le schème de la classe *Chercheur* qui est représenté par :
<figure><img src="image_20.png" /><figcaption>Figure 3-3. Schème permanent de la classe Chercheur</figcaption></figure>

Tout chercheur doit donc toujours respecter le Génotype Fondamental en valuant obligatoirement les attributs le constituant (*Num-Identification* ; *Nom* ; *Prénom*) ainsi que l'attribut *Thème-Recherche* qui est défini dans le Génotype Spécifique. Par contre, la valuation de l'attribut *Nbr-Publications* n'est pas obligatoire (en effet, un *Eleve-Chercheur* qui débute n'a pas de publications).

Nous notons le cas particulier suivant : il n'y a pas de gènes définis dans le Génotype Hérité de la classe *Chercheur*. En effet, même si sa super-classe est *Membre-Université*, la classe Chercheur hérite uniquement du Génotype Fondamental. Elle n'a pas de Génotype Hérité car la classe *Membre-Université* ne définit pas de Génotype Spécifique. Ce cas ne contredit en rien la manière dont est constitué le Génotype Hérité de toute classe, telle que défini dans la Figure 3-2.

### 3.5.5. Le lien d'évolution

Une fois la structure conceptuelle émergente créée et insérée dans le modèle de classes, les objets ayant évolué sont rattachés aux classes correspondantes. Un lien est créé entre la classe source (initiale) de l'instance vers sa classe cible (nouvelle). Ce lien exprime en fait l'un de nos objectifs, celui de permettre au modèle d'apprendre un des ses comportements futurs. Le modèle apprend un nouveau comportement évolutif et une voie possible d'évolution non seulement de ses instances, mais également de son modèle de classes. Le lien d'évolution est abordé de manière plus détaillée dans le chapitre suivant.

## 3.6 - L'exemple et sa représentation

Le modèle de l'exemple présenté dans la Figure 3-1 est décrit dans GENOME comme suit :
<figure><img src="image_21.png" /><figcaption>Figure 3-4: le même exemple sous GENOME</figcaption></figure>

La classe Membre-Université définit uniquement le GF de la population. Elle n'a pas de GH car elle n'hérite d'aucune classe, et ne définit pas de gènes pouvant être hérités par les sous-classe. Le modèle de la Figure 3-4 met en évidence les différents génotypes ainsi que les schèmes permanents. Ainsi :

$$GH_{\text{(Eleve\_Chercheur)}} = GH_{\text{(Temporaire)}} + GS_{\text{(Temporaire)}} \text{ et } GH_{\text{(Temporaire)}} = GH_{\text{(Chercheur)}} + GS_{\text{(Chercheur)}},$$

avec l'éventualité de renommage et de surcharge des génotypes hérités $GH_{\text{(Eleve\_Chercheur)}}$ et $GH_{\text{(Temporaire)}}$.

De plus, le schème permanent de *Senior-Chercheur* montre que l'attribut *Nbr-Publications* est obligatoirement présent (1) dans toutes ses instances, alors qu'il est optionnel (#) pour la classe *Temporaire* et ses sous-classes.
## 3.7 - Le méta-modèle

Après avoir introduit et défini les concepts du modèle, nous pouvons exprimer les spécifications de ce dernier. Tous les concepts sont réifiés. En effet, nous nécessitons d'exprimer et de manipuler aussi bien les classes que les instances, les attributs et les méthodes.

Nous présentons la structure du modèle dans ce qui suit. Nous présentons en premier lieu le formalisme utilisé.

### 3.7.1.1. Formalisme utilisé

Pour décrire les principaux concepts de GENOME, nous empruntons le formalisme d'UML [Muller 97]. Aussi, les concepts clés de classe, d'héritage, de composition et d'associations seront utilisés, ainsi que les notions de rôles et de multiplicité (cardinalités) sur les relations.

### 3.7.1.2. Synoptique du modèle

Le méta-modèle met en évidence les concepts présentés. Aussi, la présentation qui en est faite se focalise principalement sur la manière dont sont organisés les concepts et présente leurs caractéristiques structurelles. Les seuls attributs présentés dans le méta-modèle sont ceux qui reflètent la sémantique et les caractéristiques des concepts présentés au niveau du chapitre. Les méthodes de chaque classe ne sont pas présentées afin d'avoir un modèle de lecture aisée. Les méthodes ainsi que d'autres attributs nécessaires à l'implémentation du modèle sont définis et utilisés dans la phase d'implémentation durant la tâche de développement du prototype (chapitre 6).

Le méta-modèle est décrit par le modèle de classes UML suivant :
<figure><img src="image_22.png" /><figcaption>Figure 3-5. Architecture du modèle GENOME selon le formalisme d'UML</figcaption></figure>

Les classes et les liens décrits au sein du modèle sont la représentation des concepts présentés tout au long de ce chapitre. Nous définissons séparément les classes et les liens :

### 3.7.1.3. Définition et rôle des classes

#### 1) - Population

Cette classe modélise les populations. Chaque population est caractérisée par un nom et le Génotype Fondamental. Ce dernier est constitué d'un certain nombre de méthodes et d'attributs. Il est le même pour toutes les classes de la même population. Le génotype fondamental est fixé lors de la création de la population et il ne peut pas être modifié, sauf spécification explicite de la part du concepteur.

#### 2) - PatrimoineGenetique

La classe PatrimoineGenetique permet de définir l'ensemble des propriétés (attributs et méthodes) présentes dans toute la population. Une instance de PatrimoineGenetique