Looping Version 4.0 maintenant disponible !

Bonjour à tous,

La version 4.0 de Looping est maintenant disponible sur https://www.looping-mcd.fr

Voici les fonctionnalités supplémentaires apportées par cette nouvelle version :

- Drag & Drop des rubriques sur l'ensemble du modèle
- Ascenseurs pour les grandes classes d'entités
- Mise en évidence des sélections d'objets
- Arrondi automatique des cassures de liens
- Représentation simplifiée des associations avec DF
- Visualisation simplifiée des diagrammes de classes UML
- Liens "Crow's foot" pour les MLD
- Personnalisation des libellés des identifiants automatiques
- Personnalisation des noms de clés étrangères
- Caractères de protection dans les instructions DDL
- Urbanisation des grands modèles : définition de vues partielles
- Liens entre modèles et sous-modèles
+ plein d'autres optimisations, astuces et petits ajustements !

Je tiens à remercier les contributeurs de ce forum qui, par leurs idées et leur expertise, ont permis cette évolution majeure de Looping.
:chin:

Bonjour,

Merci pour cette nouvelle version.

Je ne suis plus un consommateur important, mais utile de temps en temps.

Bon courage pour la suite.

Bonjour Paprick,

Mon antivirus m'a fait quelques misères lors de l'installation, mais après validation de quelques pop-up, tout s'est bien passé :).

je viens de faire quelques tests rapides qui sont concluants.

Le retour d'un fonctionnement classique de la roulette est une très bonne nouvelle :ccool:, le déplacement d'attributs d'une entité ou d'une association vers une autre est d'une simplicité désarmante. Du coup j'ai essayé le copier-coller d'attributs, mais sans succès (peut être pour une prochaine version ;))

La représentation du MLD en pattes d'oies est vraiment sympa, adoptée :)

L'inversion varbinary/binary récemment signalée a bien été corrigée :)

Je n'ai pas compris quel peut être l'usage de la "Personnalisation des libellés des identifiants automatiques"
Je suppose qu'il s'agit de la zone "autre clef==> index"
Utilisé sur un type d'entité forte, il ne semble rien se passer au niveau SQL
Utilisé sur un type d'entité faible, ça provoque la création d'une contrainte "unique" sur l'identifiant de l'ET faible (ce faisant, la PK naturelle incluant la FK de l'ET forte devient une sur-clef).

Je n'ai pas non plus compris ce que signifie "Caractères de protection dans les instructions DDL" ?

Quoi qu'il en soit, merci encore pour cette nouvelle version, je n'aurai guère de temps pour la tester en profondeur ces prochains jours, mais ce sera fait dès que possible.

À très bientôt :P

Bonjour,

Citation:

---

Envoyé par escartefigue

le déplacement d'attributs d'une entité ou d'une association vers une autre est d'une simplicité désarmante. Du coup j'ai essayé le copier-coller d'attributs, mais sans succès (peut être pour une prochaine version ;))

---

Tu n'auras pas besoin d'attendre, le copier-coller existe déjà... mais il est bien caché ;) !
En fait, lors d'un Drag & Drop, il te suffit d'appuyer sur la touche "Ctrl", et la rubrique sera dupliquée au lieu d'être seulement déplacée (ça fonctionne aussi au sein d'une même classe d'entités) :lun:.

Citation:

---

Je n'ai pas compris quel peut être l'usage de la "Personnalisation des libellés des identifiants automatiques"
Je suppose qu'il s'agit de la zone "autre clef==> index"

---

Il s'agit de la génération automatique d'un identifiant quand tu es dans la fenêtre "Entité" en appuyant sur le bouton "dessin clé Auto" : jusqu'à présent, ça générait un libellé du type "Id_Client" ; maintenant, tu peux paramétrer ce libellé dans le menu "Propriétés" option "Identifiant automatique".

Citation:

---

Je n'ai pas non plus compris ce que signifie "Caractères de protection dans les instructions DDL" ?

---

Ce sont des caractères du style " ou [] qui entourent les attributs dans le fichier DDL : c'est utile pour certains SGBD.

Voilà pour les premiers éclaircissements sur cette nouvelle version :zoubi: !

Merci pour ton implication et à bientôt !

Bonjour Paprick

Je crains d'avoir trouvé un bug : j'ai créé une asso ternaire entre trois types d'entité E1, E2 et E3 ; E3 étant ciblée par une CIF
or, je constate que dans le MLD c'est non pas l'identifiant de E3 qui se retrouve comme simple attribut non clef de la table associative, mais l'identifiant de E2 :weird:

Voici le MCD :

Pièce jointe 619609

Et le MLD

Pièce jointe 619610

Par contre, le DDL est correct, seul le MLD est défaillant

Bonjour Capitaine,
Tout me semble correct dans ton exemple :weird:...
La CIF cible GTA_grille_tarifaire et GTA_ident est bien exclue de la clé dans AFF_affecter.
Peux-tu me préciser où est-ce que tu vois le souci ? :koi:

Ah mais oui !
Sur mon petit écran je n'avais pas vu l'attribut souligné, du coup j'ai cru que le bleu symbolisait la PK dans la table associative, d'où ma méprise !
Du coup tout va bien, désolé pour cette fausse alerte

Bonjour,

Quelle que soit son évolution, au demeurant toujours harmonieuse, une chose est sûre : Looping est conforme à la norme afcet définie par le groupe 135, car il est à même d’en reprendre sans difficulté le métamodèle des contraintes (cf. pages 47 et 50 du document de référence Formalisme de données "Individuel" (entité-relation): extension des contraintes, où sont considérées les contraintes d’extension et d’unicité). Si vous voulez serrer de plus près cette affaire, le groupe 135 nous a fourni un glossaire
bien utile qui explique bien chaque concept.

Contraintes d’extension « à la Looping »

Pièce jointe 632461

Contraintes d’unicité

Pièce jointe 632462

Par curiosité ou à titre de pensum, vous pouvez consulter le code SQL produit par Looping, mais il y a du trigger dans l’air ! :D

Contraintes d’extension

CREATE TABLE INDIVIDU(
   IndividuId INT,
   IndividuNom VARCHAR(32) NOT NULL,
   CONSTRAINT INDIVIDU_PK PRIMARY KEY(IndividuId),
   CONSTRAINT INDIVIDU_AK UNIQUE(IndividuNom)
);

CREATE TABLE RELATION(
   RelationId INT,
   RelationNom VARCHAR(24) NOT NULL,
   CONSTRAINT RELATION_PK PRIMARY KEY(RelationId),
   CONSTRAINT RELATION_AK UNIQUE(RelationNom)
);

CREATE TABLE PATTE(
   PatteId INT,
   PattteNom VARCHAR(32) NOT NULL,
   CardMin INT NOT NULL,
   CardMax INT NOT NULL,
   IndividuId INT NOT NULL,
   CONSTRAINT PATTE_PK PRIMARY KEY(PatteId),
   CONSTRAINT PATTE_INDIVIDU_FK FOREIGN KEY(IndividuId) REFERENCES INDIVIDU(IndividuId)
);

CREATE TABLE CONTRAINTE_EXTENSION(
   ContrainteId INT,
   ContrainteNom VARCHAR(48) NOT NULL,
   Type_Contrainte VARCHAR(2),
   RelationId INT,
   CONSTRAINT CONTRAINTE_EXTENSION_PK PRIMARY KEY(ContrainteId),
   CONSTRAINT CONTRAINTE_EXTENSION_AK UNIQUE(ContrainteNom),
   CONSTRAINT CONTRAINTE_EXTENSION_RELATION_FK FOREIGN KEY(RelationId) REFERENCES RELATION(RelationId)
);

CREATE TABLE de(
   RelationId INT,
   PatteId INT,
   CONSTRAINT de_PK PRIMARY KEY(RelationId, PatteId),
   CONSTRAINT de_RELATION_FK FOREIGN KEY(RelationId) REFERENCES RELATION(RelationId),
   CONSTRAINT de_PATTE_FK FOREIGN KEY(PatteId) REFERENCES PATTE(PatteId)
);

CREATE TABLE Pivot_p_Extension(
   PatteId INT,
   ContrainteId INT,
   CONSTRAINT Pivot_p_Extension_PK PRIMARY KEY(PatteId, ContrainteId),
   CONSTRAINT Pivot_p_Extension_PATTE_FK FOREIGN KEY(PatteId) REFERENCES PATTE(PatteId),
   CONSTRAINT Pivot_p_Extension_CONTRAINTE_EXTENSION_FK FOREIGN KEY(ContrainteId) REFERENCES CONTRAINTE_EXTENSION(ContrainteId)
);

CREATE TABLE Pivot_Extension(
   IndividuId INT,
   ContrainteId INT,
   CONSTRAINT Pivot_Extension_PK PRIMARY KEY(IndividuId, ContrainteId),
   CONSTRAINT Pivot_Extension_INDIVIDU_FK FOREIGN KEY(IndividuId) REFERENCES INDIVIDU(IndividuId),
   CONSTRAINT Pivot_Extension_CONTRAINTE_EXTENSION_FK FOREIGN KEY(ContrainteId) REFERENCES CONTRAINTE_EXTENSION(ContrainteId)
);

CREATE TABLE Portee_p_Extension(
   PatteId INT,
   ContrainteId INT,
   CONSTRAINT Portee_p_Extension_PK PRIMARY KEY(PatteId, ContrainteId),
   CONSTRAINT Portee_p_Extension_PATTE_FK FOREIGN KEY(PatteId) REFERENCES PATTE(PatteId),
   CONSTRAINT Portee_p_Extension_CONTRAINTE_EXTENSION_FK FOREIGN KEY(ContrainteId) REFERENCES CONTRAINTE_EXTENSION(ContrainteId)
);

CREATE TABLE Portee_r_extension(
   RelationId INT,
   ContrainteId INT,
   CONSTRAINT Portee_r_extension_PK PRIMARY KEY(RelationId, ContrainteId),
   CONSTRAINT Portee_r_extension_RELATION_FK FOREIGN KEY(RelationId) REFERENCES RELATION(RelationId),
   CONSTRAINT Portee_r_extension_CONTRAINTE_EXTENSION_FK FOREIGN KEY(ContrainteId) REFERENCES CONTRAINTE_EXTENSION(ContrainteId)
);

   CONSTRAINT Portee_p_Extension_PK PRIMARY KEY(PatteId, ContrainteId),
   CONSTRAINT Portee_p_Extension_PATTE_FK FOREIGN KEY(PatteId) REFERENCES PATTE(PatteId),
   CONSTRAINT Portee_p_Extension_CONTRAINTE_EXTENSION_FK FOREIGN KEY(ContrainteId) REFERENCES CONTRAINTE_EXTENSION(ContrainteId)
);

CREATE TABLE Portee_r_extension(
   RelationId INT,
   ContrainteId INT,
   CONSTRAINT Portee_r_extension_PK PRIMARY KEY(RelationId, ContrainteId),
   CONSTRAINT Portee_r_extension_RELATION_FK FOREIGN KEY(RelationId) REFERENCES RELATION(RelationId),
   CONSTRAINT Portee_r_extension_CONTRAINTE_EXTENSION_FK FOREIGN KEY(ContrainteId) REFERENCES CONTRAINTE_EXTENSION(ContrainteId)
); 

Contraintes d’unicité

 CREATE TABLE INDIVIDU(
   IndividuId INT,
   IndividuNom VARCHAR(32) NOT NULL,
   CONSTRAINT INDIVIDU_PK PRIMARY KEY(IndividuId),
   CONSTRAINT INDIVIDU_AK UNIQUE(IndividuNom)
);

CREATE TABLE RELATION(
   RelationId INT,
   RelationNom VARCHAR(24) NOT NULL,
   Definitive SMALLINT NOT NULL,
   CONSTRAINT RELATION_PK PRIMARY KEY(RelationId),
   CONSTRAINT RELATION_AK UNIQUE(RelationNom)
);

CREATE TABLE PATTE(
   PatteId INT,
   PattteNom VARCHAR(32) NOT NULL,
   CardMin INT NOT NULL,
   CardMax INT NOT NULL,
   Verouiilage SMALLINT NOT NULL,
   IndividuId INT NOT NULL,
   CONSTRAINT PATTE_PK PRIMARY KEY(PatteId),
   CONSTRAINT PATTE_INDIVIDU_FK FOREIGN KEY(IndividuId) REFERENCES INDIVIDU(IndividuId)
);

CREATE TABLE CONTRAINTE_UNICITE(
   ContrainteId INT,
   ContrainteNom VARCHAR(48) NOT NULL,
   IndividuId INT NOT NULL,
   CONSTRAINT CONTRAINTE_UNICITE_PK PRIMARY KEY(ContrainteId),
   CONSTRAINT CONTRAINTE_UNICITE_AK UNIQUE(ContrainteNom),
   CONSTRAINT CONTRAINTE_UNICITE_INDIVIDU_FK FOREIGN KEY(IndividuId) REFERENCES INDIVIDU(IndividuId)
);

CREATE TABLE de(
   RelationId INT,
   PatteId INT,
   CONSTRAINT de_PK PRIMARY KEY(RelationId, PatteId),
   CONSTRAINT de_RELATION_FK FOREIGN KEY(RelationId) REFERENCES RELATION(RelationId),
   CONSTRAINT de_PATTE_FK FOREIGN KEY(PatteId) REFERENCES PATTE(PatteId)
);

CREATE TABLE Cible_via_Patte(
   PatteId INT,
   ContrainteId INT,
   CONSTRAINT Cible_via_Patte_PK PRIMARY KEY(PatteId, ContrainteId),
   CONSTRAINT Cible_via_Patte_PATTE_FK FOREIGN KEY(PatteId) REFERENCES PATTE(PatteId),
   CONSTRAINT Cible_via_Patte_CONTRAINTE_UNICITE_FK FOREIGN KEY(ContrainteId) REFERENCES CONTRAINTE_UNICITE(ContrainteId)
);

CREATE TABLE Source_1_Unicite(
   IndividuId INT,
   ContrainteId INT,
   CONSTRAINT Source_1_Unicite_PK PRIMARY KEY(IndividuId, ContrainteId),
   CONSTRAINT Source_1_Unicite_INDIVIDU_FK FOREIGN KEY(IndividuId) REFERENCES INDIVIDU(IndividuId),
   CONSTRAINT Source_1_Unicite_CONTRAINTE_UNICITE_FK FOREIGN KEY(ContrainteId) REFERENCES CONTRAINTE_UNICITE(ContrainteId)
);

CREATE TABLE Pivot_Unicite(
   IndividuId INT,
   ContrainteId INT,
   CONSTRAINT Pivot_Unicite_PK PRIMARY KEY(IndividuId, ContrainteId),
   CONSTRAINT Pivot_Unicite_INDIVIDU_FK FOREIGN KEY(IndividuId) REFERENCES INDIVIDU(IndividuId),
   CONSTRAINT Pivot_Unicite_CONTRAINTE_UNICITE_FK FOREIGN KEY(ContrainteId) REFERENCES CONTRAINTE_UNICITE(ContrainteId)
);

CREATE TABLE Source_p_Unicite_1(
   PatteId INT,
   ContrainteId INT,
   CONSTRAINT Source_p_Unicite_1_PK PRIMARY KEY(PatteId, ContrainteId),
   CONSTRAINT Source_p_Unicite_1_PATTE_FK FOREIGN KEY(PatteId) REFERENCES PATTE(PatteId),
   CONSTRAINT Source_p_Unicite_1_CONTRAINTE_UNICITE_FK FOREIGN KEY(ContrainteId) REFERENCES CONTRAINTE_UNICITE(ContrainteId)
);

CREATE TABLE Pivot_p_Unicite(
   PatteId INT,
   ContrainteId INT,
   CONSTRAINT Pivot_p_Unicite_PK PRIMARY KEY(PatteId, ContrainteId),
   CONSTRAINT Pivot_p_Unicite_PATTE_FK FOREIGN KEY(PatteId) REFERENCES PATTE(PatteId),
   CONSTRAINT Pivot_p_Unicite_CONTRAINTE_UNICITE_FK FOREIGN KEY(ContrainteId) REFERENCES CONTRAINTE_UNICITE(ContrainteId)
);

CREATE TABLE Portee_Unicite(
   PatteId INT,
   ContrainteId INT,
   CONSTRAINT Portee_Unicite_PK PRIMARY KEY(PatteId, ContrainteId),
   CONSTRAINT Portee_Unicite_PATTE_FK FOREIGN KEY(PatteId) REFERENCES PATTE(PatteId),
   CONSTRAINT Portee_Unicite_CONTRAINTE_UNICITE_FK FOREIGN KEY(ContrainteId) REFERENCES CONTRAINTE_UNICITE(ContrainteId)
); 

Hello Paprick,

Ce crétin des Alpes qu’est DB2 (V13) ne connaît toujours pas le type BOOLEAN (il n’est pas le seul...)

Looping le sait et pallie en remplaçant par SMALLINT : d'accord.
Si donc ma table comporte une colonne de ce type, à moi de déclarer une contrainte me permettant de simuler le type BOOLEAN, par exemple :

CREATE TABLE T
(
   ... 
    C    SMALLINT    NOT NULL
   ...
) ; 
   
ALTER TABLE T
   ADD CONSTRAINT macontrainte CHECK (C IN (0,1)) ; 

Question : Looping peut-il générer l’ALTER TABLE ? :whistle:

Salut François,

Looping a bien sûr la solution ! (En aurais-tu douté ? :mouarf:)
Et même 2 solultions :

• la 1ère, la plus simple, consiste juste à rajouter ton CHECK dans la zone "Complément" située dans la fenêtre de la rubrique.
• la 2ème, si tu tiens absolument à faire un ALTER, consiste à utiliser l'outil "Règle" et d'inscrire ton ALTER TABLE dans la zone SQL prévue à cet effet.

Cette possibilité de complément peut bien sûr être utilisée pour des tas de contraintes.
Voilà, j'espère que cela te conviendra :zoubi: !

Merci Paprick,

Grâce te soit rendue :hola:

Honte à moi ! Je n’ai plus qu’à me couvrir la tête de cendres...
En continuant à fouiller dans mes archives, je me suis rendu compte que j’avais effectivement utilisé cette contrainte il y a près de 30 ans !

Donc j’essaierai de ne plus oublier qu’on peut simplement coder — comme le précise la norme SQL-92 — :

CREATE TABLE T
(
   ... 
    C    SMALLINT    NOT NULL, CHECK (C IN (0,1))
   ...
) ; 

 

Ne plus oublier... :weird: Car comme l’ont écrit Goethe, Winston Churchill, George Santayana, Thomas Mann, et bien d'autres :

« Celui qui a oublié son passé est condamné à le revivre ».

Ave Paprick,

A propos d’urbanisation et tout ça.

Dans le post #1 où sont énumérées les nouvelles fonctionnalités de la version 4.0 de Looping, je lis :  

Citation:

---

Envoyé par Paprick

Urbanisation des grands modèles : définition de vues partielles
- Liens entre modèles et sous-modèles

---

Mais comment c’est qu’on fait ? :(

Par exemple, le MCD global ci-dessous est trop chargé et va finir par devenir illisible ; je voudrais donc faire 3 vues : une vue DISCUSSIONS, une vue ARTICLES et une vue BILLETS. Il est évident que code SQL résultant ne doit pas être celui des vues, mais celui du MCD global.

MCD global :

Pièce jointe 633907

Vue DISCUSSIONS

Pièce jointe 633908

Vue ARTICLES

Pièce jointe 633909

Vue BILLETS

Pièce jointe 633911



N.B. Pour simplifier la discussion, j’ai procédé à une sorte de mini-rétroconception du site DVP.

Salut François,

Je n'ai pas réussi à ouvrir tes pièces jointes, mais pas de problème pour t'expliquer le fonctionnement de cette urbalisation.
En fait, c'est très simple :
1 - Aller dans le choix "Urbanisation" du menu général et définir le nom des vues : DISCUSSIONS, ARTICLES et BILLETS.
2 - Ouvrir chaque classe d'entités et choisir la ou les vues qui la concerne à partir de l'icone en bas à gauche de la fenêtre.
3 - Cliquer sur la flèche en dessous du bouton "Vue" à droite de la barre d'outils et choisir la ou les vues à afficher.

En cliquant sur le bouton "Vue", on affiche alternativement les vues ou le modèle complet.

Voilà, essaie : ça devrait le faire 8-).

Bonjour,

À propos de l'affectation des classes aux vues, y a-t-il un moyen d'affecter plusieurs classes à une même vue en une seule étape plutôt que de passer dans chaque classe pour l'affecter ?
Un truc du genre : sélection multiple de classes, puis clic droit et affectation à une vue ?

Je n'ai pas trouvé comment faire (si c'est possible).

ced

Bonjour,

Citation:

---

Envoyé par ced

À propos de l'affectation des classes aux vues, y a-t-il un moyen d'affecter plusieurs classes à une même vue en une seule étape plutôt que de passer dans chaque classe pour l'affecter ?
Un truc du genre : sélection multiple de classes, puis clic droit et affectation à une vue ?
Je n'ai pas trouvé comment faire (si c'est possible).

---

Non, effectivement ce n'est pas prévu pour le moment... à réfléchir pour une future version... :koi:

Merci Paprick. Voilà, j’ai fait comme tu m’as dit.

Je suis étonné que les pièces jointes ne s’affichent pas chez toi, car pour ma part elles apparaissent bien à l’affichage de mon message. Je pense qu’il s’agit d’un bug dans la gestion des pj chez DVP, car ça n’est pas une première.
En tout cas je les recrée soigneusement en espérant que cette fois-ci tu y aura accès...
Tu noteras que dans les vues, je repositionne les objets, pour des raisons de présentation... Autrement dit, pour arriver à mes fins, j’en suis réduit à créer autant de fichiers .loo que de vues... :weird:

MCD global :

Pièce jointe 633941

Vue DISCUSSIONS

Pièce jointe 633942

Vue ARTICLES

Pièce jointe 633943

Vue BILLETS

Pièce jointe 633944

Bonjour,
Les pièces sont bien réapparues :) !
La gestion des vues ne prévoit effectivement pas que les objets changent de places... c'est une vue partielle (au sens littéral du terme) d'un même modèle.
Si tu produits plusieurs .loo, l'urbanisation de Looping n'a plus trop d'intérêt, surtout si le modèle évolue... :calim2:

Buenas noches,

Certes, je ne tiens pas à faire autant de fichiers .loo qu’il y a de vues, je préférerais simplement que le fait de bouger un objet dans une vue ne se propage pas sur le MCD global...:ange:

Bien sûr, je vois ça de la dunette, mais dans la soute cela représente sans doute pas mal de boulot...:pc:

Salve,

Je donne peut-être l’impression de causer de l’urbanisation sur un ton badin, mais ce sujet fut toujours un réel souci pour moi chez mes nombreux clients, c’est-à-dire dès la fin des année soixante-dix.

Dans un post datant de 2009 j’ai résumé l’importance que je donne à l’urbanisation, car les MCD des projets sur lesquels j’intervenais étaient toujours très copieux en entités-types :

Citation:

---

Envoyé par fsmrel

Si le MCD complet comporte par exemple mille entités-types, la direction du projet aura pris la précaution d’urbaniser l’univers du discours en domaines (référentiels) sous-domaines et sous-sous-domaines, comme je l’ai déjà plus ou moins évoqué. Ainsi, on aura décomposé le projet en référentiels  : Personnes, Contrats, Cotisations, Catalogue produits, Prospection de masse, Éditique, etc., peut-être une vingtaine, voire plus. Au niveau le plus fin, la représentation graphique doit tenir — de façon claire et lisible — sur un ensemble de pages au format (disons) A3, chaque page constituant une vue suffisante pour qu’un développeur n’ait pas à avoir sur son bureau un tombereau de diagrammes.

---

Ce qui me navre, c’est que sur les gros projets j’ai toujours été obligé de me résoudre à réaliser les vues manuellement. Ces vues me permettaient d’y voir plus clair et de ne discuter avec les développeurs que des points qui les concernaient. Le plus souvent mes clients utilisaient des AGL anglo-saxons fort onéreux, compliqués à mettre en oeuvre, bref, propres à faire perdre du temps plus qu’à en gagner. Ah ! si Looping avait vu le jour en ces temps reculés...

Pour en revenir aux vues proposées par Looping, pouvoir les rendre lisibles en bougeant les objets, coincés un peu partout « à la va comme j’te pousse » dans le MCD global, je pense que ce serait un plus qui m’aurait bien servi du temps où je me démenais chez mes chers clients...

Bonsoir,

Citation:

---

Envoyé par fsmrel

Pour en revenir aux vues proposées par Looping, pouvoir les rendre lisibles en bougeant les objets, coincés un peu partout « à la va comme j’te pousse » dans le MCD global, je pense que ce serait un plus qui m’aurait bien servi du temps où je me démenais chez mes chers clients...

---

Je comprends ta volonté d'ajuster la présentation des vues en fonction de leur configuration.
Une remarque similaire avait été faite pour pouvoir changer la présentation des diagrammes de classes UML ou des MLD indépendamment du MCD.
Contrairement à tous les autres logiciels du marché, il faut bien comprendre que Looping ne génère pas des modèles différents pour les vues, les MLD ou les diagrammes UML : c'est le même modèle affiché différemment, d'où l'instantanéité du passage de l'une à l'autre des représentations.
Les modifications faites sur une représentation sont donc immédiatement disponibles sur les autres, et gérer indépendamment ces représentations serait une contrainte insurmontable pour la cohérence globale du modèle.
Prenons l'exemple de la modification d'un élément lors d'une représentation du modèle par une vue : rajout de rubriques, d'une association, voire d'une nouvelle classes d'entités. Faudrait-il que cette nouvelle classe n'apparaisse pas dans le modèle global : bien sur que non ! Alors comment distinguer ce qui doit impacter le modèle global lors de la modification d'une vue ? Si on veut aller au bout du raisonnement, on se rend vite compte que, avec une seule source du modèle comme c'est le cas pour Looping, on doit maintenir une organisation stricte des différentes vues du modèle.
Alors, reste la solution des autres logiciels que Looping peut aussi mettre oeuvre : créer différends modèles en fonction des représentations souhaitées, et le nouvel outil "Sous-modèle" de Looping v4 peut aider pour cela... mais personnellement, je préfère me creuser la tête pour rendre toutes les représentations les plus agréables possible à lire, en organisant au mieux le modèle complet, tout en respectant sa cohérence globale.