Spécifications de l`algorithme de transformation incrémentale d`un

Projet MVC-CD
Spécifications de l'algorithme de transformation
incrémentale de MCD en MLD-R
Créé par P.-A. Sunier, le 12 juin 2013
Modifié par P.-A. Sunier, le 7 février 2014
Page 1 sur 21
Table des matières
1
Préambule ....................................................................................................................................... 3
2
Organisation du référentiel ............................................................................................................. 3
3
Choix du mode de transformation .................................................................................................. 3
4
Transformation incrémentale ......................................................................................................... 3
4.1
5
Référencement entre MCD et MLD......................................................................................... 3
4.1.1
Cible logique .................................................................................................................... 3
4.1.2
Source conceptuelle ........................................................................................................ 4
4.1.3
Diagrammes logiques de données .................................................................................. 4
Algorithme principal - 1ère esquisse ................................................................................................. 5
5.1
Concept ................................................................................................................................... 5
5.1.1
Aspect dynamique ........................................................................................................... 5
5.1.2
Aspect statique ................................................................................................................ 6
5.2
Découpage en activités ........................................................................................................... 8
5.2.1
6
Algorithme principal - 2ème esquisse.............................................................................................. 10
6.1
Concept ................................................................................................................................. 10
6.1.1
Aspect dynamique ......................................................................................................... 10
6.1.2
Aspect statique .............................................................................................................. 10
6.2
Découpage en activités ......................................................................................................... 16
6.2.1
7
Activité - Contrôle de conformité du MCD .................................................................... 17
Algorithme principal - 3ème esquisse.............................................................................................. 18
7.1
Concept ................................................................................................................................. 18
7.1.1
Aspect dynamique ......................................................................................................... 18
7.1.2
Aspect statique .............................................................................................................. 18
7.2
8
Activité - Contrôle de conformité du MCD ...................................................................... 9
Découpage en activités ......................................................................................................... 19
Références internes au projet ....................................................................................................... 19
Page 2 sur 21
1 Préambule
L'algorithme de transformation incrémentale d'un modèle conceptuel de données en un modèle
logique relationnel s'appuie sur les modalités de transformation que nous avons décrites dans le
document Spécifications de transformation d'un MCD en un MLD-R [RF-2] et sur les Spécifications
de transformation incrémentale entre MCD et MLD décrites dans [RF-3].
2 Organisation du référentiel
Le référentiel sera organisé selon les préceptes qui ont été présenté en [RF-1a]
3 Choix du mode de transformation
L'algorithme de transformation doit tenir compte du choix du modélisateur d'obtenir:



un modèle logique basé sur des dépendances entre tables - MLD-DT;
un modèle logique basé sur des tables indépendantes - MLD-TI;
les deux modèles ci-dessus.
[Plus de détails en RF-3 – Chapitre Cohérence du modèle logique entre itérations]
Toutefois, la transformation incrémentale d'un modèle logique basé sur des tables dépendantes est
tellement contraignante que nous y renonçons dans un premier temps.
Dès lors, nous retenons les modes de faire suivants:


la transformation incrémentale sera assurée pour les modèles basés sur des tables
indépendantes;
les modèles logiques basés sur des dépendances entre tables sont effacés et recréés
complètement à chaque transformation.
4 Transformation incrémentale
4.1 Référencement entre MCD et MLD
Un référencement croisé entre élément(s) de niveau conceptuel et objet(s) de niveau logique est
réalisé lors de la création des objets de niveau logique et maintenu entre les différentes itérations.
Le référencement est réalisé par des tags.
4.1.1 Cible logique
Tout élément de niveau conceptuel doit référencer le ou les objets de niveau logique dont il est
source de dépendance.
La référence sera double:


Un tag MLDTargetId qui réfère l'id Visual Paradigm de l'objet logique;
Un tag MLDVPElementName qui contient le nom de l'objet logique.
Le premier tag MLDVPElementId est en fait une clé primaire et sera utilisé en tant que tel.
Page 3 sur 21
Le second tag MLDVPElementId est en fait un identifiant naturel qui, à terme, nous permettrait de
recréer un objet de niveau logique qui aurait été supprimé par erreur.
4.1.2 Source conceptuelle
Tout objet de niveau logique doit référencer le ou les éléments de niveau conceptuel dont il est cible
de dépendance.
La référence sera double:


Un tag MCDVPElementId qui réfère l'id Visual Paradigm de l'élément conceptuel;
Un tag MCDVPElementName qui contient le nom de l'élément conceptuel.
Le premier tag MCDVPElementId est en fait une clé primaire et sera utilisé en tant que tel.
Le second tag MCDVPElementId est en fait un identifiant naturel qui, à terme, nous permettrait de
recréer un objet de niveau conceptuel qui aurait été supprimé par erreur.
4.1.3 Diagrammes logiques de données
Les diagrammes ne sont pas effacés entre les différentes itérations.
Page 4 sur 21
5 Algorithme principal - 1ère esquisse
5.1 Concept
5.1.1 Aspect dynamique
Le principe de l'algorithme principal est représenté par le scénario nominal ci-dessous.
Nous y avons mis en évidence:


le référentiel de VP qui contient:
o le MCD à transformer;
o le MLD existant (lors de la 1ère itération, le MLD n'existe pas)
o le nouvel MLD obtenu par adaptation du MLD aux spécifications contenues dans le
MCD.
les objets essentiels en mémoire du plugin:
o MCDElement - les éléments du MCD à transformer;
o MLDElementExistant - les éléments du MLD existant et à adapter;
o MLDAObtenirElement - les éléments du MLD tels qu'ils devront être après la
transformation;
o MLDAdaptateur - les spécifications de base de réalisation du delta entre éléments du
MLD à obtenir et éléments existants.
Figure 1 - Scénario nominal de l'algorithme principal
Page 5 sur 21
5.1.2 Aspect statique
Les classes essentielles requises par l'algorithme de transformation sont représentées ci-dessous.
Figure 2 - Classes essentielles à la réalisation de la transformation
Dans le modèle de classes essentiel ci-dessus, nous trouvons:


les classes:
o MCDElement - éléments du modèle conceptuel de données (entités, associations,
attributs, contraintes…);
o MLDElement - éléments du modèles logique de données (tables, colonnes…);
o MLDAdaptaeur - spécifications élémentaires de réalisation du delta entre MLD à
obtenir et MLD exoistant;
les interfaces:
o MLDAObtenirElement: éléments du modèle logique à obtenir en fin de
transformation; il s'agit d'une spécialisation de MLDElement;
o MLDExistantElement: éléments du modèle logique existant avant la transformation;
il s'agit d'une spécialisation de MLDElement;
Page 6 sur 21

les relations (UML):
o de dépendance:
 1 - De MLDAObtenirElement à MCDElement: référence à l'élément
conceptuel ayant amené à l'instantiation de MLDAObtenirElement;
 2- De MLDAExistantElement à MCDElement: référence à l'élément
conceptuel ayant amené à l'instantiation de MLDAExistantElement;
 3- De MCDElement à MLDAExistantElement: référence à l'élément logique
existant d'un élément conceptuel (utile au traçage entre les différentes
itérations);
 4 - De MLDAdaptateur à MLDAObtenirElement: référence à l'élément
logique servant de situation finale à MLDAdapteur;
 5 - De MLDAdaptateur à MLDAExistantElement: référence à l'élément
logique servant de situation initiale à MLDAdapteur;
o de réalisation:
 entre l'interface MLDAObtenirElement et la classe MLDElement;
 entre l'interface MLDExistantElement et la classe MLDElement;
Page 7 sur 21
5.2 Découpage en activités
Figure 3 - Diagramme d'activités principales
Page 8 sur 21
Le diagramme de la Figure 3 - Diagramme d'activités principalesmontre les activités principales de
l'algorithme de transformation à savoir:





5.2.1
Contrôle de conformité du MCD - la logique de l'algorithme peut s'arrêter à cette seule
activité si seul le contrôle de conformité est souhaité par l'utilisateur.
Si le modèle est conforme, les objets MCDElement sont créés en mémoire.
[L'activité est décrite en Figure 4]
Lecture du MLD existant et mise en mémoire - lecture du MLD existant et création des
objets MLDExistantElement en mémoire.
La lecture du MLD existant est effectuée si la transformation est incrémentale et que le MLD
a été créé lors d'une itération précédente.
Génération du nouvel MLD en mémoire - lecture des objets MCDElement conformes
existants en mémoire et création des objets MLDACreerElement en mémoire.
Elaboration du delta entre MLD existant en mémoire et MLD nouveau en mémoire création des objets MLDAdaptateur qui vont contenir les spécifications de correction du
delta entre MLD existant et MLD à obtenir.
Si la transformation n'est pas incrémenatle ou qu'il s'agit de la 1ère itération, le delta
correspond à la réalisation du MLD à obtenir.
Génération du MLD - Exécution du code de transformation contenu dans les objets
MLDAdaptateur.
Activité - Contrôle de conformité du MCD
Figure 4 - Activité "Contrôle de conformité du MCD"
Page 9 sur 21
6 Algorithme principal - 2ème esquisse
6.1 Concept
6.1.1 Aspect dynamique
Le principe de la 1ère esquisse est maintenu [5.1].
6.1.2 Aspect statique
Par rapport à la 1ère esquisse, nous avons avancé dans la réalisation et affiné la structure de données
6.1.2.1 MLD
Les éléments du modèle logique à obtenir , MLDAObtenirElement, et existant, MLDExistantElement,
ne sont plus des interfaces; ils sont différenciés par l'instanciation en mémoire de deux modèles
logiques [Figure 5].
Figure 5 - 2 instances du modèle logique de données
Page 10 sur 21
6.1.2.2 Liens en mémoire entre référentiel VP et modèles de données
Figure 6 - Classes en charge de la traçabilité de la transformation incrémentale
Page 11 sur 21
Le modèle de la Figure 6 représente les classes essentielles qui vont permettre de garder la trace des
dépendances entre éléments de modèles de niveaux différents. Nous pouvons observer:

Les classes
o MCDElement - ancêtre de tous les éléments de niveau conceptuel en mémoire,
comme par exemple: entité, attribut, association…
o MLDElement - ancêtre de tous les éléments de niveau logique en mémoire, comme
par exemple: table, colonne…
Il y aura des éléments de niveau logique propres à l'instance du MLD à obtenir et
d'autres du MLD existant.
o VPElement - ancêtre des éléments du référentiel de VP qui sont chargés en mémoire.
L'attribut idIME est l'identifiant unique de tout élément du référentiel de VP.
Les éléments du référentiel de VP en mémoire sont utiles pour mettre en place le
double référencement [4.1] entre MCD et MLD et en assurer ensuite la persistance
au sein du référentiel de VP.
o VPElementMCD - sert à faire le lien entre un élément de niveau conceptuel et son
éventuelle représentation au niveau logique. Par exemple: la référence à la table de
niveau logique qui est créée à partir de l'entité de niveau conceptuel.
Concrètement, sont stockés:
 L'identifiant de l'élément du référentiel de VP de niveau logique.
 Le nom de l'élément du référentiel de VP de niveau logique.
o VPElementMLD - sert à faire le lien entre un élément de niveau logique et son
éventuelle représentation (ou source) au niveau conceptuel. Par exemple: la
référence à l'entité de niveau conceptuel qui a été source de création de la table de
niveau logique.
Concrètement, sont stockés:
 L'identifiant de l'élément du référentiel de VP de niveau conceptuel.
 Le nom de l'élément du référentiel de VP de niveau conceptuel.

Les dépendances
Page 12 sur 21
6.1.2.3
Les adaptateurs de correction du delta
4
2
3
Figure 7 - Adaptateur de correction du delta entre MLD existant et à obtenir
Page 13 sur 21
1
Le modèle de la Figure 7 représente les classes essentielles qui vont permettre de définir les
opérations à réaliser pour adapter le MLD existant dans le référentiel de VP. Nous pouvons observer:
Les classes






Adapter - singleton représentant l'ensemble des adaptations à faire au MLD de VP pour
corriger le delta avec le nouvel MCD, respectivement MLD.
AdapterElement - ancêtre de tous les adaptateurs spécifiques de delta.
Il est associé à une opération à effectuer.
AdapterTable - adaptateur spécialisé "Table".
Il est associé aux éléments en mémoire suivants:
o existing - L'éventuelle table existante.
o toObtain - La table à obtenir.
AdapterColumn - adaptateur spécialisé "Colonne".
Il est associé aux éléments en mémoire suivants:
o existing - L'éventuelle colonne existante.
o toObtain -La colonne à obtenir.
AdapterOperation - liste des opérations supportées:
o A - Ajouter un élément inexistant.
o S - Supprimer un élément obsolète.
o M - Modifier les propriétés d'un élément existant en prévenant les effets de bord sur
une éventuelle implantation physique ou autre contrainte.
o R - Remplacer les propriétés d'un élément existant sans tenir compte d'effets de
bord sur une éventuelle implantation physique ou autre contrainte.
AdapterNature - liste des natures d'éléments de modèle logique en mémoire susceptibles
d'être dotés d'un adaptateur:
o TABLE
o COLUMN
Les associations

L'association ① représente le paramétrage de transformation du delta.
Remarque importante: L'utilisateur ne peut choisir qu'une opération entre M-Modifier et RRemplacer.
Page 14 sur 21
Les adaptateurs seront créés par les méthodes createAdapterTable() ou createAdapterColumn(); ces
méthodes sont implantées au sein de la classe singleton Adapter.
Ces méthodes sont appelées par une méthode execute() ou autre de la classe singleton Adapter.
Cette méthode va parcourir tous les éléments à adapter (tables, colonnes…) de l'instance toObtain
du MLD.
Pour chaque élément, elle va chercher, via la structure représentée en Figure 6, s'il y a un élément
existant. S'il est trouvé un élément existant, elle va vérifier si les attributs des deux éléments sont
différents ou pas. Ensuite, un adaptateur est créé en respect des règles 1, 2 et 3 de la table de
décision ci-après.
Après avoir parcouru l'instance toObtain du MLD, la méthode execute() va parcourir les éléments de
l'instance existing.
Pour chaque élément, elle va contrôler sil est orphelin (non rattachée à un élément du MCD) ou pas.
Si l'élément est orphelin, un adaptateur est créé en respect de la règle 4 de la table de décision.
Création des adaptateurs
C1 existing
C2 toObtain
C3 Attr(existing) <> Attr(toObtain)
R1
O
O
O
A1
A2
A3
A4
A5
X
X
Créer adaptateur
Modifier ou Remplacer existant
Supprimer existant
Ajouter nouveau
Erreur
R2
O
O
N
R3
O
N
-
R4
N
O
-
X
X
R5
N
N
-
X
X
X
Naturellement, les adaptateurs ne seront créés que si l'utilisateur autorise l'opération pour la nature
de l'élément traité (association ①).
C'est aussi par le paramétrage de l'utilisateur que l'on saura dans le cas de la condition C3 de la table
de décision quelle est l'opération de l'action A2 à prendre en compte.
Lors de la création d'un adaptateur, l'association ④ est créée pour faciliter la reprise des
adaptateurs lors de leur exécution.
Page 15 sur 21
6.2 Découpage en activités
Nous avons affiné la production et l'utilisation des différentes instances des modèles MCD et MLD.
Page 16 sur 21
6.2.1
Activité - Contrôle de conformité du MCD
Page 17 sur 21
7 Algorithme principal - 3ème esquisse
7.1 Concept
7.1.1
Aspect dynamique
Par rapport à la première esquisse, nous avons réalisé le diagramme ci-dessous sur la base des
classes et méthodes planifiées
Figure 8 - Scénario nominal de l'algorithme principal de l'esquisse 3
Remarque: Nous avons limité le scénario ci-dessus, pour certains échanges, à quelques messages
explicatifs du concept. Par exemple, MCDLoader va envoyer le message createEntity() mais aussi
createAttribute(), createAssLink()… ou encore MCDToMLD va envoyer createTable() mais aussi
createColumn(), createPackage()…
7.1.2 Aspect statique
Le principe de la 2ème esquisse est maintenu [6.1.2].
Page 18 sur 21
7.2 Découpage en activités
Nous avons simplifié le découpage en activités pour bien montrer les flux et branchements
principaux.
Figure 9 - Diagrammes d'activités principales de l'esquisse 3
8 Références internes au projet
[RF-1a]
Spécifications d'organisation du référentiel
http://lgl.isnetne.ch/Sagex35793/Specifications/specificationsReferentiel.pdf
[RF-1]
Spécifications de réalisation de MCD
http://lgl.isnetne.ch/Sagex35793/Specifications/specificationsMCD.pdf
Page 19 sur 21
[RF-2]
Spécifications de transformation d'un MCD en un MLD-R
http://lgl.isnetne.ch/Sagex35793/Specifications/specificationsMCD-MLDR.pdf
[RF-3]
Spécifications de transformation incrémentale d'un MCD en un MLD-R
http://lgl.isnetne.ch/Sagex35793/Specifications/SpecificationsMCD-MLDRIteratif.pdf
Page 20 sur 21
Les contraintes de clés étrangères sont aussi considérés comme des éléments susceptibles d'être adaptés
Page 21 sur 21