Diagramme UML : Héritage nécessaire ?

[ThibaudJER]

Bonjour à vous tous,

Je tiens tout d'abord à vous remercier pour votre sens d'entraide sur ce forum, ça me fait vraiment plaisir

Mon application ajoute des records basé sur les erreurs (mais pas tous les erreurs vont conduire à l'ajout des record, seulement les MainError).

Chaque session a beaucoup d'erreurs, ensuite, un service interne à mon application va étudier ces erreurs pour savoir lesquels sont MainError (erreurs importantes qui vont conduire à ajouter un record) et lesquelles sont les erreurs ordinaires (erreurs pas importantes, ou les erreurs qui découlent ou reliées aux MainError)

Diagramme UML :


J'ai besoin de votre aide/conseil/suggestion concernant la spécification, pensez vous que c'est la meilleure approche? ai-je besoin de l'héritage? (peut etre Error et MainError comme classes différentes pourra faciliter les choses?)

- Chaque MainError a une liste d'erreurs qui lui sont reliés

- Une MainError ne peut pas faire partie d'une liste d'erreurs d'une autre MainError

- Une erreur peut être reliée à beaucoup de MainError

- Un record est associé à une MainError unique, et bien évidemment à plusieurs erreurs (puisque chaque MainError a une liste d'erreurs)

- Je travaille sur une application en JAVA avec JPA

Merci beaucoup de votre aide

Bonne soirée
-----

[Bluedeep]

J'ai besoin de votre aide/conseil/suggestion concernant la spécification, pensez vous que c'est la meilleure approche?

Je trouve un peu bizarre le fait de faire porter par MainError une liste de Record. puisque tu dis au dessus que'une MainError => un Record.
Idem pour la liste de Sessions : a priori, ce sont les Sessions qui instancient les MainError ? Donc comment une MainError pourrait elle avoir une liste de Sessions ? Les Sessions se passent entre elles des instances de MainError ? A priori ce n'aurait pas grand sens.

ai-je besoin de l'héritage? (peut etre Error et MainError comme classes différentes pourra faciliter les choses?)

On en voit pas trop l'interêt ici.

[ThibaudJER]

Bonjour,

Merci beaucoup pour votre réponse, c'est exactement comme vous dites, ce sont les Sessions qui instancient les MainError, mais je met une liste de Sessions dans MainError c'est juste par ce que je travaille en JPA et que je suis obligé de faire les annotations ManyToMany ect.. (puisque deux sessions différentes peuvent générer la meme MainError, et donc une MainError peut avoir des sessions différentes). Mais en tout cas, c'est bien las sessions qui instancient les MainError et c'est bien principalement avec List<MainError> que je vais travailler.

Si je n'ai pas été très clair, je vous expliquerai avec vous plus détails sans aucun problème,
Merci beaucoup

[Bluedeep]

mais je met une liste de Sessions dans MainError c'est juste par ce que je travaille en JPA

Je ne connais pas JPA. C'est quoi ?' un ORM ?

Si c'est le cas, c'est bien le premier ORM incapable de traiter une relation 1..n.

Mais dans tous les cas, il n'est pas vraiment acceptable de piloter le design des classes en fonction des insuffisances (réelles ou supposées) de tel ou tel composant.

Ceci dit, si c'est vrai, ton exemple illustre bien le caractére discutable des approches "model first" vers la DB.

[A voir en vidéo sur Futura]

[Arzhur]

Bonjour,

- Chaque MainError a une liste d'erreurs qui lui sont reliés
- Une erreur peut être reliée à beaucoup de MainError

En gros Error et MainError sont lié a une list d'erreur....Je verrais plus une classe Error avec une liste d'Error et un attribut de "sévérité" pour distinguer les Main des autres..

- Une MainError ne peut pas faire partie d'une liste d'erreurs d'une autre MainError

T'es pas obligé de le contraindre par ton modèle, cette restriction , tu peux la gérer via ton service qui va remplir les liste d'Error


tout les id , ce sont les clés dans la base ou c'est autre chose encore ?

- Un record est associé à une MainError unique, et bien évidemment à plusieurs erreurs (puisque chaque MainError a une liste d'erreurs)

Est-ce que tu as besoin à partir d'une Error, (Main ou pas) de "remonter" à la Session ?

[ThibaudJER]

En gros Error et MainError sont lié a une list d'erreur....Je verrais plus une classe Error avec une liste d'Error et un attribut de "sévérité" pour distinguer les Main des autres..

J'avais justement beaucoup pensé à cette solution, mais je vois quelques inconvénients : Le premier c'est que, vu que j'ai beaucoup d'Error et beaucoup moins de MainError, à chaque Error, j'aurais associé une liste vide. Deuxième inconvénient plus important, c'est que en conservant que la classe Error et en faisant un boolean isMain, j'aurais une association ManyToMany (*-*) entre Error et Record, et je perd la précieuse information qui dit que chaque Record a une seule MainError.

tout les id , ce sont les clés dans la base ou c'est autre chose encore ?

ça c'est tout une question que je me pencherai dessus plus tard, ça va influencer uniquement la performance de la base de donnée, mais pour l'instant, une Erreur aura deux ID, celui généré par la base (un Long), et l'ID de l'erreur en question (String), mais c'est pas mon problème principal pour l'instant

Est-ce que tu as besoin à partir d'une Error, (Main ou pas) de "remonter" à la Session ?

Je suis parti avec des liens bidirectionnels pour que je laisse cette possibilité plus tard, mais c'est absolument pas du tout le coeur ni le but de mon application pour l'instant.

T'es pas obligé de le contraindre par ton modèle, cette restriction , tu peux la gérer via ton service qui va remplir les liste d'Error

Tout à fait d'accord

Mais dans tous les cas, il n'est pas vraiment acceptable de piloter le design des classes en fonction des insuffisances (réelles ou supposées) de tel ou tel composant.

Je suis absolument d'accord, c'est pas un vrai diagramme UML, j'aurais du enlever ces listes avant de poster ce diagramme.


Je vous remercie pour votre aide, ça me fait vraiment plaisir
Bonne journée

[Arzhur]

Le premier c'est que, vu que j'ai beaucoup d'Error et beaucoup moins de MainError, à chaque Error, j'aurais associé une liste vide.

C'est pas ce que j'appelle un problème ça...ou alors t'as une contrainte de conso mémoire difficilement tenable ? C'est combien beaucoup d'erreur ? A noter que t'es pas obligé de charger toute la base de donnée dans ton appli.

j'aurais une association ManyToMany (*-*) entre Error et Record, et je perd la précieuse information qui dit que chaque Record a une seule MainError.

Je comprends pas pourquoi , vu ta description c'est du OneToOne que tu dois faire (ou alors j'ai zappé un truc).

[Bluedeep]

J'avais justement beaucoup pensé à cette solution, mais je vois quelques inconvénients : Le premier c'est que, vu que j'ai beaucoup d'Error et beaucoup moins de MainError,

Fonctionnellement une MainError est elle associée ou pas une liste de 1 à n Error ?
Dit autrement : est ce que une MainError peut être levée sans qu'il y eu d'occurence d'erreur "pas main" avant ? Et la liste d'error est elle fonctionnellement liée à la main error ?

Sans vouloir être vexant, tu me donnes un peu l'impression de "forcer" la modélisation en perdant de vue l'aspect fonctionnel.

[ThibaudJER]

C'est pas ce que j'appelle un problème ça...ou alors t'as une contrainte de conso mémoire difficilement tenable ?

Non aucune contrainte de mémoire, oui je suis tout à fait d'accord qu'il faut donc pas considérer ça comme un problème

Je comprends pas pourquoi , vu ta description c'est du OneToOne que tu dois faire (ou alors j'ai zappé un truc).

Pour l'instant (avec ma modélisation du début), Un record n'a qu'une seule MainError (et puisque une MainError contient une liste d'Error, donc un record peut avoir beaucoup d'Error). et dans l'autre sens, une MainError peut avoir beaucoup de record ( Dans mon application, c'est la MainError qui instancie le record, et une MainError peut donc instancier deux record différents).
Donc la cardinalité actuelle entre Record *-1 MainError, va se transformer en Record * - * Error (si j'enelve la classe MainError)

Fonctionnellement une MainError est elle associée ou pas une liste de 1 à n Error ?
Dit autrement : est ce que une MainError peut être levée sans qu'il y eu d'occurence d'erreur "pas main" avant ? Et la liste d'error est elle fonctionnellement liée à la main error ?

Oui une MainError peut etre levée sans qu'il y eu d’occurrences d'Error avant, et chaque Error "pas main" est forcément liée à une MainError (En gros, la MainError est la source du problème, et les Error viennent après en conséquence et sont du à cette MainError, je veux dire, si la MainError est corrigé ou n'arrive plus, les autres Error n'auront pas de raison d'exister)

Je suis conscient que je suis peut-être pas très clair, et que vous faites beaucoup d'efforts pour que vous comprenez mon probème et je vous en suis très reconnaissant pour ça.
Bonne journée

[Arzhur]

Chaque session a beaucoup d'erreurs, ensuite, un service interne à mon application va étudier ces erreurs pour savoir lesquels sont MainError (erreurs importantes qui vont conduire à ajouter un record) et lesquelles sont les erreurs ordinaires (erreurs pas importantes, ou les erreurs qui découlent ou reliées aux MainError)

chaque Error "pas main" est forcément liée à une MainError

Je trouve que les 2 phrases se contredisent :

dans la première on a des Erreur "pas importante" et des Erreur "qui decoulent ou reliées" a une MainError
dans la seconde on a toutes les Erreur "pas Main" sont reliées à une MainError....où sont passées les "pas importantes" ?

Donc la cardinalité actuelle entre Record *-1 MainError, va se transformer en Record * - * Error (si j'enelve la classe MainError)

D'un point de vue "conceptuelle" oui, je te l'accorde...Mais pas dans la base de données ni dans le modèle puisque tu gardes une Error "intermédiaire" : celle qui sera flaggé isMain. Tu peux garder une relation Record *-1 Error ( en fait t'auras : Record *-1 Error 1- * Error).




Si je résume le fonctionnement de ton appli, est-ce que ca donne ca ? :

Session a plusieurs "Error", un service est appelé pour dire qui est MainError et les Error qui se rattachent à une MainError.
Puis un service parcourt les MainError qui vont chacune créer n Record.

Derrière tout ça, pour une Session donnée, l'utilisateur visualise les Record pour "corriger" (ou je sais pas trop quoi) les MainError (et donc les Error qui lui sont rattachées ).

[ThibaudJER]

dans la première on a des Erreur "pas importante" et des Erreur "qui decoulent ou reliées" a une MainError

Je me suis surement mal exprimé, mais "pas imporante" et "qui découlent ou reliées" c'est la meme chose! Une erreur "pas importante" est surement reliée ou en découle d'une "MainError".

Si je résume le fonctionnement de ton appli, est-ce que ca donne ca ? :

Session a plusieurs "Error", un service est appelé pour dire qui est MainError et les Error qui se rattachent à une MainError.
Puis un service parcourt les MainError qui vont chacune créer n Record.

Derrière tout ça, pour une Session donnée, l'utilisateur visualise les Record pour "corriger" (ou je sais pas trop quoi) les MainError (et donc les Error qui lui sont rattachées ).

Là je pense que vous avez absolument tout compris et que vous avez expliqué le fonctionnement de mon application beaucoup mieux que je l'ai fait moi (Je vous remercie vraiment et Bluedeep aussi pour votre entraide et le temps que vous passez à la compréhension de mon problème).
Donc vous pensez toujours que la meilleure solution serait de faire uniquement une classe Error avec un boolean isMain ?
(En tout cas pour l'instant, je pense que l'idée de l'héritage est un peu stupide surtout que y'a une seule classe qui hérite, ça va plus me compliquer les choses que m'aider, donc pour l'instant j'ai totalement séparé Error et MainError en faisant une cardinalité *-* entre les deux au lieu de l'héritage).

[Arzhur]

Donc vous pensez toujours que la meilleure solution serait de faire uniquement une classe Error avec un boolean isMain ?

Je pense, j'ai l'impression que ça facilitera le passage Error->MainError : pas besoin de supprimer l'Error puis de créer la MainError.

pour l'instant j'ai totalement séparé Error et MainError en faisant une cardinalité *-* entre les deux au lieu de l'héritage).

Ok donc tu gardes 2 classes différentes ? C'est une solution. Dans ce cas je me demande si ça vaut pas le coup d'avoir une classe "PreError" (c'est qu'un exemple de nom hein, j'ai pas d'autres idées sur le moment) : qui modéliserait une erreur non définit en tant que MainError ou Error. En gros le service mange une liste de PreError et crée ton arborescence de MainError et Error.

EDIT : en fait j'aime bien la solution avec 3 classes, je la trouve plus jolie et plus facilement transposable sur un BDD

[ThibaudJER]

Ok donc tu gardes 2 classes différentes

Pour l'instant oui, sans héritage. ça me parait une solution acceptable mais je pense pas que ce soit la meilleure!

Dans ce cas je me demande si ça vaut pas le coup d'avoir une classe "PreError" (c'est qu'un exemple de nom hein, j'ai pas d'autres idées sur le moment) : qui modéliserait une erreur non définit en tant que MainError ou Error. En gros le service mange une liste de PreError et crée ton arborescence de MainError et Error.

Très intéressant, mais comme vous ferez ça avec seulement 3 classes? Par ce qu'avec votre idée, je vois bien une classe mère Error (abstraite) , et 3 classes qui en héritent : PreError,MainError,RelatedErro r avec MainError*-*RelatedError. ça me parait une piste très intéressante à étudier et ça justifierai l'utilisation de l'héritage. Mais que serait vraiment l'utilité de PreError à part que cela soit "plus propre" ?

MERCI beaucoup

[Arzhur]

je vois bien une classe mère Error (abstraite)

On peut dire que t'y tiens a ton heritage....a voir s'il y a des attribut en commun, ca peut servir a factoriser du code.

Mais que serait vraiment l'utilité de PreError à part que cela soit "plus propre" ?

Si t'en as pas l'utilité, enlève le. De mon point de vue c'est plus cohérent : la "gravité" des erreurs est modélisé avec le type de l'objet. C'est ton Service qui dit si c'est une Main ou Pas....sauf que avant d'être Main ou pas, qu'est-ce que c'est (d'ou le pré-erreur) ?

C'est à toi de choisir ce qui te semble le plus compréhensible/simple/évolutif compte tenu de la spec' de ton application.

[Bluedeep]

On peut dire que t'y tiens a ton heritage....a voir s'il y a des attribut en commun, ca peut servir a factoriser du code..

Sauf que l'héritage n'est jamais censé servir à factoriser du code.

[Arzhur]

Sauf que l'héritage n'est jamais censé servir à factoriser du code.

C'est un peu gratos comme affirmation...et je suis pas d'accord.

Si t'as n classes dans ton appli qui ont a chaque fois x attributs/méthode commun c'est peut-être que t'es passé a côté "d'un concept" que t'as pas su modéliser dans ton modèle.

Et ça vaut souvent le coup de faire une classe mère pour éviter la duplication code.

[ThibaudJER]

Merci beaucoup pour vos réponses, je me permets de vous poser une autre petite question :

Dans le cas ou je fais 3 différentes classes (PreError, Error et MainError) que ce soit avec héritage ou non. Session serait reliée à laquelle ? Elle serait reliée à MainError? (C'est plus intéressant pour de voir pour une session donnée quelles sont ses MainErrors que quelles sont ses Error, de plus si j'ai accès aux MainError d'une session donnée, je peux parcourir leurs listes et avoir donc la liste de toutes les Errors relatives à cette session).

Merci beaucoup

[Arzhur]

bonjour

Session serait reliée à laquelle ?

A quoi sert ta classe Session ?


Comme l'a fait remarqué Bluedeep : on dirait que t'imposes un modèle puis ensuite tu vois ce que tu vas faire avec après. C'est l'inverse qu'il faut faire : d'abord tu détermines ce que tu veux faire puis ensuite tu fais un modèle.