Discussion :

[jc63]

Bonjour,

J'ai un problème pour modéliser mon application :
c'est en fait une application proposant des abonnements à des produits, à des entreprises ou des particuliers. Il peut s'agir d'abonnement à un produit ou à plusieurs produits (ca dépend de l'offre choisi). Une offre correspond à une durée, un nombre de produit, un type de produit + options, un montant. les offres ne sont forcément pas les mêmes pour les particuliers et pour les entreprises.
Ces abonnements sont bien sur renouvelables. Ils peuvent être renouvelés par une offre différente. A chaque renouvellement est associé un paiement.

Voila pour le contexte.
J'ai du mal à tout faire fonctionner ensemble. Je sais que mon modèle n'est pas bon mais il y a les grandes lignes.

Si vous avez des remarques, conseils, idées, je les accepterais bien volontier.

Merci d'avance
Julien C.


ps: j'ai mis mon diagramme fait sous Violet UML Editor. par contre comme non autorisé sur le forum j'ai modifié l'extension : dg1.class.java -> dg1.class.violet (c'est au cas ou quelqu'un veuille me proposer quelque chose / aussi rapide que de faire de la prose et plus compréhensible)

[hed62]

Je ne vois pas trop ce qu'est le "Droit"..

Le paiement et le renouvellement ne sont pas des classes a priori, mais des méthodes de certaines classes (vite fait, je dirais souscription).

Pour etre plus précis, tu peux ajouter les attributs principaux dans tes classes.

Dans ton diagramme , tu auras du aml à distinguer Personne et employé. Tu devrais plutôt faire une interface / classe mère Personne, et Particulier et Employé en heriteraient.

Si l'offre conditionne les produits, alors la liason Souscription -> Produit doit etre déportée vers Offre -> Produit (idem pour le multiple / simple)

Tu devrais préciser qu'un produit est d'un certain Type.

Pour ton renouvellement je te propose d'ajouter une DateDeSouscription et une Duree à Souscription. Tu peux ainsi détecter la fin de la souscription, déclencher le use case "Renouveler Souscription" et demander le paiement de la nouvelle Offre.

Je ne vois pas les options ici...

Si les Options impactent le coût de la souscription, renseigne toi sur le design pattern "Decorateur" qui te permettra de mieux gérer tes options (et d'ailleurs, même si cela n'affecte pas le coût final, "Décorateur" peut rester interressant).

Fait bien attention à ne pas mélanger Diagramme de classes et use case (je pense à renouvellement et paiement)

[jc63]

Droit est en fait un rôle : particulier, directeur, employé

Le paiement et le renouvellement ne sont pas des classes a priori, mais des méthodes de certaines classes (vite fait, je dirais souscription).

Pour etre plus précis, tu peux ajouter les attributs principaux dans tes classes.

en fait, je dois pouvoir avoir un historique des renouvellements et des paiements. c'est pour ça que j'en avais fait des classes. mais comment les lier ???

Dans ton diagramme , tu auras du aml à distinguer Personne et employé. Tu devrais plutôt faire une interface / classe mère Personne, et Particulier et Employé en heriteraient.

C'est vrai. c'est par souci de faignantise que j'ai fait ça. je vais utiliser hibernate pour l'implémentation et quand il y a de l'héritage il y a un peu plus de problèmes (d'aprés ma maigre expérience) ;-). mais ui tu as tout à fait raison.

Si l'offre conditionne les produits, alors la liason Souscription -> Produit doit etre déportée vers Offre -> Produit (idem pour le multiple / simple)

Je pensais plus faire ça à l'éxecution du programme. je ne propose que les bons types de produits, suivant l'offre sélectionnée ? non ?

Tu devrais préciser qu'un produit est d'un certain Type.

en fait ma classe produit est une classe abstraite qui contiendra des sous types.

Pour ton renouvellement je te propose d'ajouter une DateDeSouscription et une Duree à Souscription. Tu peux ainsi détecter la fin de la souscription, déclencher le use case "Renouveler Souscription" et demander le paiement de la nouvelle Offre.

ok. je pourrai peut-être justement lié souscription à une classe "renouvellement" qui contiendrait les dates en question + une association avec une classe paiement + une association à la classe "offre" qui ne serait plus du coup liée à "souscription".

Je ne vois pas les options ici...

Ma pauvre tête ne les voit pas non plus et c'estencore moins comment les mêtre dans le diagramme ;-)

Si les Options impactent le coût de la souscription, renseigne toi sur le design pattern "Decorateur" qui te permettra de mieux gérer tes options (et d'ailleurs, même si cela n'affecte pas le coût final, "Décorateur" peut rester interressant).

Je m'en vais voir ça

Fait bien attention à ne pas mélanger Diagramme de classes et use case (je pense à renouvellement et paiement)

C'est vrai. tout me semble un peu obscur. et plus j'y pense plus je me plonge virtuellement dans la programmation et moins je pense conceptuel.

En tout cas merci pour tes conseils.
Julien C.

[hed62]

Droit est en fait un rôle : particulier, directeur, employé

Je préfère une classe mère personne, sous typée, idem pour les offres. Tu peux alors ajouter une association entre les types d' offres et les sous types de personnes.

en fait, je dois pouvoir avoir un historique des renouvellements et des paiements. c'est pour ça que j'en avais fait des classes. mais comment les lier ???

Rien ne t'oblige à avoir un Modèle de BD identique à ton Diag de classes. Tu peux garder ton diagramme et en base ajouter deux tables d'historisation que tu remplis au fur et à mesure des évènement => diag de classe + clair, et historisation quend même.

C'est vrai. c'est par souci de faignantise que j'ai fait ça.

Bouh pas bien !

Si l'offre conditionne les produits, alors la liason Souscription -> Produit doit etre déportée vers Offre -> Produit (idem pour le multiple / simple)

Je pensais plus faire ça à l'éxecution du programme. je ne propose que les bons types de produits, suivant l'offre sélectionnée ? non ?

Tu ajoute un argument à ma suggestion : à l'execution, tu souhaite avoir la liaison Offre -> Produit, mais tu ne modélise qu'une relation Souscription -> Produit... C à dire que si tu n'a aucune souscription, tu n'as aucun produit ?

en fait ma classe produit est une classe abstraite qui contiendra des sous types.

Alors précise le et ajoute un ou deux sous type pour l'exemple.

ok. je pourrai peut-être justement lié souscription à une classe "renouvellement" qui contiendrait les dates en question + une association avec une classe paiement + une association à la classe "offre" qui ne serait plus du coup liée à "souscription".

Pas obligé si tu accepte d'avoir MPD <> Diag classes

Ma pauvre tête ne les voit pas non plus et c'estencore moins comment les mêtre dans le diagramme ;-)

J'ajouterai simplement une Classe Option liée à Offre (options possible) et liée à Souscription (Options souscrites). Le tout en suivant 'Décorateur"

Je m'en vais voir ça

Bien !

C'est vrai. tout me semble un peu obscur. et plus j'y pense plus je me plonge virtuellement dans la programmation et moins je pense conceptuel.

Pas bien !

Dégage toi de toute idée d'implémentation. Ne pense pas trop à la BD. Exprime juste la logique de ton appli. As-tu commencé par les use case ? Si non, ne touche plus ton diag et fais les. Reviens sur le diag class après.

En tout cas merci pour tes conseils.
Julien C.

De rien !

[jc63]

je n'ai bien sur pas commencé par les use case - ben en fait si mais dans ma tête... je vais les faire.

sinon petit point que je n'ai pas précisé. le produit est créé par la personne : par exemple une annonce, une pub, ...

bon je vais essayer de remettre tout à plat en utilisant tes conseils...

merci.

[hed62]

N'hésite pas à renvoyer tes diagramme sur ce même post !