Discussion :

[hed62]

Début du fil : http://www.developpez.net/forums/sho...d.php?t=437115

J'ai récemment relu le (bon) livre design pattern la tête la première et j'ai retrouvé un design pattern interressant dans ton cas : Interprète.

En voici le résumé par l'exemple :

Grammaire très simple :
expression := <commande> | <sequence>
sequence := <commande> | <commande> <sequence>
commande := droite | gauche

c.f automate à pile en copie

[cotmar]

Bonsoir,

J'ai été un peut long à répondre aujourd'hui, mais j'ai ét éen réunion pour faire un point cd'ancemenbt sur mon mémoire.. ENfin, voici enfin le diagramme de classe tel que je l'obtient à partir de l'mportation depuis mon projet Java.

Pas trops évident, car j'avais pas compris qu'il fallait faire un glisser-déplacer des classes sur le fond blanc. :p

Pièce jointe 21658

Sinon, pour le diagramme d'états-transitions, je le mettrais un peut plus tard dans une version scindée en 2 ou peut-être en trois (à suivre les prochains épisodes dans le précédent topic ).

Comme toujours je suis preneur (et même friand de toutes les remarques).

Je dois effectivement avoir ce livre dans ma bibliothèque. On me l'avais déjà conseillé, mais je n'ai pas encore eu le temps de le lire. Décidément les grands esprits se rencontrent.

A bientôt.

Marco.

[cotmar]

Petite question anexe : est-ce qu'il peut y avoir "interraction" entre Bouml et le code Java ?

Je m'explique : j'ai récupéré lesclasses pour mon diagramme dans Bouml à partir de mon projet et j'aimperais savoir (suite à une discution avec un collègue au boulot) si il peut y avoir modification du projet dans l'autre sesn (mon projet est sous Eclipse) ? Et (en pensans à la fonction "refoactor) peut-il y avoir un impact négatif sur le jeux (pertes de références des propriétés, méthodes...) modifiées ?

Par avance merci.

Marco.

[hed62]

Pour la perte, il faut contacter bruno_pages. Mais je ne penses pas.

En tous cas, une fois ton projet "reversé" (beau franglisme ça..) tu peux modifier le "body" des méthodes, faire du renommage, etc... pour ensuite regénérer l'intégralité de la chose, et cela fonctionenra toujours dans ton environnement de Dev. toutefois, si tu modifie le body sous eclipse, bouml ne le verra qu'après un RoundTrip Body (un reverse que sur les body des methodes)

Mais à la limite, tu peux coder sous BOUML plutôt qu'Eclipse maintenant (bon ok l'éditeur est un chouilla moins top )

[cotmar]

Bonjour,

Merci pour ta réponse hed62.
Sinon, qu'est-ce que tu penses du diagramme d'un manière générale ?

Par avance merci.

Marco.

[hed62]

Les relations sont assez imprécises : tu devrais spécifier quand cela est possible si ce sont des agrégation, des compositions (ou rien si ce n'est ni l'un ni l'autre)

Ajoute également les cardinalités (même si c'est pour mettre * partout) , en sachant que ce n'est pas parceque une relation ne navigue que dans un sens qu'on ne met qu'une cardinalité : tu peux mettre les cardinalités à chaque extrémité.

Sépare les relations : certaines se superposent et donc cela nuit à la lisibilité

Attention aussi à tes boucles, cela me semble obscur... Notamment TypeSection qui porte un type qui est un TypeSection qui porte un type qui ...... à l'infini ?

Idem au niveau de TypeDonnée, tu fais apparemment la liste des valeurs possibles, cela me semble étrange comme notation.

[cotmar]

Salut,

Alors pour donner quelques indications supplémantaires concernant ce diagramme de classes, voici les régles de gestion telles que je les ai décrites dans mon mémoire (mais celà aussi est sans doute insuffisant) :

- Un fichier STEP est obligatoirement constitué d’une HEADER SECTION et d’un ensemble de DATA SECTION (au moins une),
- Chaque section appartient à un type (HEADER ou DATA),
- Chaque section contient un ensemble d’entités qui sont de type HEADER ou DATA,
- Chaque entité comporte une ou plusieurs entête selon qu'elle est de type (typeEntête) SIMPLE ou COMPLEXE,
- Une entête comporte un ensemble d’attributs, comportant une valeur et correspondant à un type de données qui peuvent être des types prédéfinis (énumération, binaire, dollar, instance, entier, chaîne ou réel), des types composites (le type liste est un type récursif) ou encore de types définis par l’utilisateur,

Tu pourrais me donner quelques indications sur la notion de compositions et d'agrégations s'il te plait ?

A bientôt et merci.

Marco.

[hed62]

Bien sur :

- simple relation = le moins précis, te dis juste qu'il y a relation entre deux classes. Exemple : A-----B
(Attention, cela peut également signifier relation bidirectionnelle dans un diagramme terminé)

- relation directionnelle : un peu plus précis, donne le sens de navigation. Exemple : A--->B . A voit B mais pas l'inverse

- Agrégation : A 'contient' un/des (selon cardinalité) B. Représentée par un losange blanc. Exemple : A<>----*->B = A contient plusieurs B. On peut naviguer de A vers B mais pas l'inverse.

- Composition : idem agrégation, mais avec losange plein. La nuance se trouve au niveau de la ligne de vie. Exemple : A<*>------1-> B = A est composé de un B unique, qui doit être détruit si A 'meurt'.

Si tu as d'autres questions

[cotmar]

Salut,

Alors voici la version modifiée de mon diagramme de classes.

Pièce jointe 21859

J'avoue que je ne suis pas très sûr de moi en ce qui concerne le cardinalité et les types de relations, par contre je suis toujours preneur de toute suggestion.

Ce schéma correspond également aux règles de gestion données plus haut.

A bientôt.

Marco.

[hed62]

Attention niveau cardinalités:

A-1-----*-> B

signifie que A est lié à autant de B qu'on veut B et que B est lié à un A.

Dans le cas des Types, tu met du 1-1, soit qu'une Section ne possède qu'un Type (normal) et qu'un Type n'es lié qu'à une seule section (pas normal) je mettrai plutot

Section --*------------1--> Type

Je suis d'accord avec les relations/agrégations.

Tu n'as pas réagis en ce qui concerne les boucles :

La relation TypeEntete---------------(type)--> TypeEntete me semble vraiment étrange. idem pour les autres (SIMPLE, COMPLEXE, etc...)

Ok avec le 2..* tout en haut : il y a au moins deux sections.

Attention au GetEntites() de Section qui doit renvoyer une collection d'Entites (valable plusieurs fois dans le diagramme)

C'est à peu près tout pour le moment. bonne soirée!

[cotmar]

Merci hed62,

Je corrige les cardinalités tout de suite.

Sinon, j'ai un petit souci avec les relations réflexives en fait. Est-ce que je ne pourrais pas simplement les enlever ?

Je t'avoue que au départ j'ai généré le schéma depuis mon code Java et je ne comprends pas trops comment il les obtient. C'est la raison pour laquelle je n'ai pas réagit.

Voici une nouvelle mouture :
Pièce jointe 21907

A bientôt et merci.

Marco.

[bruno_pages]

Sinon, j'ai un petit souci avec les relations réflexives en fait. Est-ce que je ne pourrais pas simplement les enlever ?

un diagramme de classe n'a pas à être forcément complet, surtout si être complet veut dire illisible
tu peux donc retirer les relations 'peu importantes', en mettant peut être une note l'indiquant

Je t'avoue que au départ j'ai généré le schéma depuis mon code Java et je ne comprends pas trops comment il les obtient.

je suppose que 'il' est le reverse ?
si la classe C a un attribut de type C, alors le reverse crée une relation réflexive, en quoi est-ce surprenant ?

Voici une nouvelle mouture :

on ne peut rien lire, la mouture est vraiment trop fine ...

[hed62]

on ne peut rien lire, la mouture est vraiment trop fine ...

En effet, les fois précédente, je pouvais déchiffrer, mais là... niet !

Pour en revenir sur ces relations réflexives, il me semble que dans la classe Type_Section tu as ajouté trois attributs pour donner les trois types possibles, non ?

Code :

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

1
2
3
4
5
6
 
Type_Section
{
  Type_Section HEADER;
  Type_Section DATA;
}

Ou quelque chose de ressemblant, non ?

Si c'est cela, il me semble qu'il y avait plus judicieux (une enum, ou autre...)

[cotmar]

Bonjour,

Donc re-voici le diagramme de classe (plus lisible enfin j'espère :p ).

Pièce jointe 21944

A bientôt.

Marco.

[cotmar]

Salut,

Pour le type oui c'est ça. Comment se traduit le enum en UML ?

A bientôt.

Marco.

[bruno_pages]

Bonsoir,

Comment se traduit le enum en UML ?

avec une classe stéréotypée enum

[cotmar]

Bonjour,

C'est une petit affaire qui progresse bien il me semble merci.

Alors j'ai modifié le diagramme selon vos indications.
Il y a juste une chose que je ne sais pas trops comment représenter : les SCOPE et les EXPORT LIST ?

Voici donc la nouvelle mouture (j'ai agrandi le tamis pour qu'elle soit moins "fine" ) :


J'ai supprimé les relations réflexives en ce qui concerne les types et ajouté les attributs selon les remarques précédentes.

A plus tard et bon apétit.

Marco.

[hed62]

Il ne manque juste que les stéréotypes <<enum>> sur certains TypeXX.

Par contre, pourrais tu essayer de représenter ton DC en essayant de coller au pattern Interprète ? Cela devrait rendre la chose plus lisible et la (future) implémentation plus claire.

[cotmar]

Bonjour,

A ce stade, je pense qu'il me faut expliquer un peut plus le contenu de mon fichier STEP pour que ça soit plus clair.

En fait je ne sais pas si c'est de ceux-là dont tu veux parller, mais j'ai égtalement un souci avec les "typesDonnes - typePerso - typeComposite" :

-> typeDonnees : représente les types de données simple (int, enum, reél, instance...),
-> typeComposite : (représente des données du genre d'un "tableau" comme on en trouve dans des langages de programmation usuels) : ce type peut-être récursif et peut inclure tous les autres types de données (y compris des typeComposite donc),
-> typePerso : est un type de donnée créé par l'utilisateur par composition de tous les autres types de données

Remarque : le typeDonnees "instance" représente le référencement à l'intérieur d'une entité d'une autre instance d'entité.
Exemple :

Code :

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

1
2
3
4
#10=POINT(10,5,6);
#30=POINT(5,4,3);
#20=LIGNE(#10,#30);

Ici : les instance sont #10, #20 et #30 et les entités de DATA sont POINTet LIGNE (les entités de HEADER n'ont pas de numéro d'instance).

Qu'est ce que vous me suggégeriez là dessus ?

Sinon, vous ,ne m'aveez pas répondu sur la représentation des SCOPE et EXPORT LIST dans mon diagramme de classe ?
Un exemple d'utilisation du SCOPE :

Code :

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

1
2
3
4
5
#50=&SCOPE
#40=POINT(8,9,7);
#90=VECTEUR(#40,10);
ENDSCOPE

Pour les sections (et la structure du fichier en général) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
ISO-10303-21;              --Début du fichier
HEADER-SECTION;          --Début de Header Section
FILE_NAME(...);             --Entité de Header Section
FILE_DESCRIPTION(...);
FILE_SCHEMA(...);
ENDSECTION;                --Fin de Header Section

DATA SECTION;             --Début de Data Section
#10=POINT(10,5,6);
#30=POINT(5,4,3);
#20=LIGNE(#10,#30);
#50=&SCOPE                 --Début de SCOPE
#40=POINT(8,9,7);
#90=VECTEUR(#40,10);
ENDSCOPE                    --Fin de SCOPE
ENDSECTION;                --Fin de Data Section
END-ISO-10303-21;       --Fin de Fichier

Dans la HEADER SECTION les entités sont : FILE_SECTION, FILE_DESCRIPTION et FILE_SCHEMA (ces trois là sont obligatoires, mais il peut y en avoir d'autres).

Sinon, j'ai modifie mon diagramme afin de faire coller les diagrammes d'état et le diagramme de classes comme vous me l'avez fait remarquer :


J'allais aussi oublier : une entité COMPLEXE est composée de plusieur entités SIMPLEs :

Code :

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

1
2
3
#10=POINT(1,2,3); --Entité SIMPLE
#20=(POINT(1,2,3)POINT(2,3,4)); --Entité COMPLEXE

Un type de données composée (nommé "list" dans la norme) :

Code :

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

1
2
#60=ED_STC((51,"liste de valeurs",("toto",(1,2,3),.TRUE.)),10);

-> ED_STC est une entité qui contitient une liste, elle-même contenant une liste et cette dernière contenant également une liste.

J'espère ne pas trops vous submerger d'information et que ça sera plus clair de cette manière.

A bientôt.

Marco.

[hed62]

Qu'est ce que vous me suggégeriez là dessus ?

Je ne comprend pas vraiment ton problème... donc, je ne suggère rien ! J'ai bien compris l'objectif des trois types mais je ne vois pas ce qui te gêne dans cela.

Sinon, vous ,ne m'aveez pas répondu sur la représentation des SCOPE et EXPORT LIST dans mon diagramme de classe ?

En effet, je n'ai pas la réponse... Parceque j'ai du mal à voir ce que sont scope et ExportList. Je les traite donc comme des token simple sans relation ni impact en soi.

#50=&SCOPE
#40=POINT(8,9,7);
#90=VECTEUR(#40,10);
ENDSCOPE

Malgré l'exemple, je ne saisi pas la différence fonctionnelle avec :

#40=POINT(8,9,7);
#90=VECTEUR(#40,10);

J'allais aussi oublier : une entité COMPLEXE est composée de plusieur entités SIMPLEs :

Soit, ce qui implique la réalisation d'un sous analyseur rien que pour parser ces entités.