Discussion :

[niocco]

Bonjour,
Il y a une question qui me revient souvent quand je m'essaye a concevoir des classes. j'aurais du mal a l'exprimer avec des mots donc je préfère faire une démonstration par l'exemple :

Imaginons que je veuille développer une application qui permette de faire un MCD façon Power-Designer ou autre, peu importe car le probleme porte sur la modélisation des éléments graphiques.
Dans ce genre de logiciel, je sais que mon programme devra savoir afficher a l'écran des petites boites de couleurs ( les entités / associations etc )
Je déduis donc que je vais avoir besoin de classes qui seront toutes déssinables et qui de ce fait possèderont ce genre de propriétés ( entre autres ) : x, y, largeur, hauteur, couleur. Mettons que je nomme cette classe : TPaintable ( en delphi-like ).
Je pourrais dériver a loisir cette classe pour obtenir des rectangles des cercles des traits etc....

A l'étape suivante, je voudrais créer une classe TEntité qui hérite de TPaintable ET qui seront pour porteuses d'informations propres au MCD (identifiant, propriétés, cardinalités etc).
C'est ce dernier aspect qui me pose probleme.

En effet jusque ici ma classe ne contenait que des champs qui ont trait a sa représentation graphique. Maintenant je devrais y ajouter des champs qui sont du domaine du MCD. Du coup ça me gène beaucoup de mélanger ces deux niveaux dans une même classe : qui ressemblerais a ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
type TEntité = class
{
x, y, width, height : integer;
nomEntite: string;
propriétés: array of TPropriétés.
}

Questions :
1 - Ai-je raison d'être géné ?
2 - Comment appréhender cette distinction et sous quelle forme l'implémenter ?
jusque là on m'a toujours dit "va voir dans les design pattern, il y a tout ce qu'il faut". j'y ai été, mais n'étant pas familier de la chose, je dois dire que je ne comprends pas comment l'appliquer. Pouvez-vous me dire comment vous le feriez dans le cas de ce projet de modelisation MCD ?

[CinePhil]

Tu parles de classes qui sont plutôt du domaine de la programmation objet et donc de la modélisation à l'aide du langage UML.

Dans un diagramme de classes UML, tu pourrais faire ceci :
point 2-----------* segment 3..*---------------* polygone

Traduit en MCD, ça donnerait ceci :
point -0,n----delimiter----2,2- segment -0,n----constituer----3,n- polygone

Et les tables pourraient être celles-ci :
point (pt_id, pt_x, pt_y...)
segment (seg_id, seg_id_extremite_1, seg_id_extremite_2...)
polygone (plg_id, plg_nom...)
plg_constituer_seg (pcs_id_polygone, pcs_id_segment)

[niocco]

Salut Cinephil

Je me suis mal exprimé : je ne cherche pas a modéliser mon programme en MCD, mais plutôt a définir des classes en vue de la création d'un logiciel qui dessine des MCD ( un PowerAMC like si tu veux ).

en plus je ne sais pas lire UML.

[CinePhil]

C'est pour le fun que tu veux faire ça ?
Parce qu'il existe déjà pas mal de logiciels de modélisation dont certains sont gratuits, entre autre le canadien Open Modelsphere et le petit dernier d'un contributeur du forum : jMerise.

[niocco]

Non ce n'est pas pour le fun, là ou je travail, on a pas java et pas le droit de l'installer. On fait beaucoup de MCD et on a pas d'outil (mais le ridicule ne tue pas). Donc j'ai un vrai besoin de ce genre d'outil (marre de le faire sous word)

En plus ma question est plus large : elle repose sur un problème de design que je rencontre souvent (séparation graphisme/métier) et que je re-rencontre lorsque je commence a regarder la faisabilité de ce logiciel.

J'ai testé OPenmodelSphere, JMerise, AnalyseSI, toujours le même souci c'est du java.

[CinePhil]

Le lien que j'ai donné vers la discussion concernant jMerise contient un message de fsmrel qui donne un méta-modèle des contraintes d'un MCD et quelques liens qui vous seront sans doute utiles.

Pour commencer plus simplement, dans un MCD, il y a :
- des entités ;
- des attributs dans ces entités ;
- des associations entre les entités munies de cardinalités.

Il faudra donc des classes pour tout ça et sans modéliser ces classes, que ce soit à l'aide d'un MCD Merise ou d'un diagramme de classes UML, tu va dans le mur à mon avis. On ne se lance pas dans la programmation sans conception !

Pour répondre, peut-être, à une partie de ta problématique posée ici, remarque qu'une entité constituée de ses attributs reste la même, qu'elle soit située en haut à gauche ou au centre de la fenêtre, qu'elle soit rouge, violette ou jaune !

Allez, je tente un début de MCD schématisant ce qu'est un MCD...

entite -1,n----composer----(1,1)- attribut -1,1----typer----0,n- type

entite -0,n----associer----0,n- entite

[niocco]

Est ce utile de préciser que je suis analyste ? (donc non, je ne vais pas coder sans analyse, c'est d'ailleurs ce que je fais : j'essaye d'abord d'écrire sur papier mes futures classes pour lever les inconnues fonctionnelles et technique)

Par contre je ne compte pas stocker ça dans une bdd donc je vais éviter de faire un MCD. Je suis plutot au niveau diagramme de classe.

En ce qui concerne ta troisieme remarque, je suis tout a fait d'accord avec toi, l'entité ne change pas intrinsequement si elle change de couleur de position etc... et quel que soit le nombre de propriété qu'elle porte.

ce qui est géré par un class de type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
type TEntité = class
{
x, y, width, height : integer;
nomEntite: string;
propriétés: array of TPropriétés.
}

mais je n'aime pas le design de cette classe je pense qu'il existe un meilleur moyen de la designer.

[CinePhil]

Il y a quelques messages...

en plus je ne sais pas lire UML.

Et dans le dernier :

Je suis plutot au niveau diagramme de classe.

Le diagramme de classe se dessine à l'aide du langage UML !

Bon je crois surtout que tu n'es pas dans le bon forum puisque celui-ci est consacré aux schéma relationnels MCD, MLD... mais pas UML et encore moins la définition de classes pour de la programmation objet.

Bref, je ne peux pas t'aider davantage.

[niocco]

oui c'est vrai dsl

[niehu]

Bonjour,

Tu peux essayer de découpler la partie affichage de ta classe, de la partie modèle. Ainsi la partie qui sait dessiner un rectangle à une certaine position, n'a pas besoin de savoir que le rectangle possède x liaisons avec d'autres rectangles.
Tu as alors deux arbres d'héritage, l'un qui représente les "déssinables" et l'autre les composants de ton modèle. Ton modèle devient alors indépendant de sa représentation et chaque élément du modèle dispose d'une référence vers l'élément affichable qui le représente.
Il me semble que ce n'est pas très loin de MVC et du design pattern Bridge.

[niocco]

Salut niehu, et merci pour ta réponse

C'est en effet dans ce sens que je voudrais aller. Dans ce que tu propose, on sépare bien la partie gestion de l'affichage de la partie gestion des données ( propriété, associations etc... )

Par contre, tu parle d'un "double héritage". Est ce a dire que la classe de plus haut niveau devra hériter de plusieurs classes ? Si c'est le cas, je ne pourrais donc pas le faire en delphi.

Par ailleurs, j'ai toujours du mal a opérer correctement une telle séparation : en effet, il y a toujours un moment ou le graphisme a besoin de connaître le fonctionnel. Par exemple, les dimensions d'un carré qui représente une entité se calculent en fonction du nombre de propriétés qu'elles contient ! donc certaines données doivent être partagées quand même, et c'est la ou je n'arrive jamais a faire quelque chose de propre. Si j'avais un exemple se serait top^^

[Hephaistos007]

Ce que tu cherches à faire est le modèle de classe...du modèle entité-association. Cela s'appelle un méta-modèle.

Voici un exemple de ce que tu cherches :


A ceci près que tu dois rajouter à tes différents classes des attributs qui te permettront de gérer leur affichage à l'écran, du type abscisse/ordonnée,largeur/hauteur/couleur de fond/etc...