Discussion :

[Trompette83]

Bonjour,

Lors des cours UML que j'ai suivi, nous avons modelisé une application dans laquelle on trouvait des clients (customers), fournisseurs (suppliers), ...
Ce model a été validé par le prof.

Aujourd'hui, je reprend ce model (voir fichier joint Classes.png) pour une application de gestion d'entreprise (ce n'est pas un exercice).
J'ai généré le data model (voir le fichier tables.png) avec mon outil.

1) Pouvez vous me donner votre avis général.

2) Je pense que la classe Individual_Customer ne sert à rien vu qu'elle ne contient pas de donnée. La classe Customer ne doit-elle pas etre directement reliée à Natural_Person et Corporate_Body? Votre avis?

3) Comment exprimer en UML la contrainte: Un client (customer) doit être un client_physique (individual_customer) OU EXCLUSIF une entreprise (corporate_customer)?

4) La classe agence (Bank_Branch) qui est reliée par une aggregation à Bank se retouve ensuite etre une table isolée. Suivant les cours UML, et si j'ai bien compris, l'aggregation est un association avec une sémentique plus forte. A quoi sert cette sémentique si la conversion en table est plus faible qu'une association simple? Votre avis?

5) Lorsque je crée ce model, j'ai l'impression de réinventer la roue. En effet, la majorité des programmes de gestion d'entreprise possèdent une base de données avec une structure identique. De même, un calendrier, la gestion de dates, des adresses sont des structures à peu près identiques pout tous. N'existe-il pas des models disponibles standards réutilisables avec ou sans modification? Si oui ou?
La réutilisabilité est bien un objectif des concepts actuel!?

Merci

[ego]

1) Pouvez vous me donner votre avis général.

Les méthodes "CRUD" ne servent à rien (create, delete,..); Il faut loger tout ça dans des classes dites DAO dédiées (Data Access Object)

2) Je pense que la classe Individual_Customer ne sert à rien vu qu'elle ne contient pas de donnée. La classe Customer ne doit-elle pas etre directement reliée à Natural_Person et Corporate_Body? Votre avis?

Le modèle semble en gros ok mais il manque surtout les attributs. La notion de "client individuel" et "client entreprise" sont généralement importantes et distinguées; donc je garderai les classes mais je les complèterais.
Si je comprend bien le modèle, je ne ferais pas de lien entre Natural_Person et Customer, idem pour Corporate_Body.

3) Comment exprimer en UML la contrainte: Un client (customer) doit être un client_physique (individual_customer) OU EXCLUSIF une entreprise (corporate_customer)?

Ben tu l'as dit avec l'héritage, non ? Si tu parle de complétude de ton sous-typage, tu peux mettre la contrainte "complete" entre les 2 relations de spécialisation (les flèches entre Customer et ses 2 sous-classes).

4) La classe agence (Bank_Branch) qui est reliée par une aggregation à Bank se retouve ensuite etre une table isolée. Suivant les cours UML, et si j'ai bien compris, l'aggregation est un association avec une sémentique plus forte. A quoi sert cette sémentique si la conversion en table est plus faible qu'une association simple? Votre avis?

Le mapping classe - table se moque des notions d'agrégation ou composition; ce qui compte c'est la multiplicité. Donc ok pour la table "Bank_Branch". Par contre, tu peux tout à fait définir un contrainte côté base de données en disant que la foreign key côté Bank_Branch, qui pointe vers la table Bank ne doit pas être null. Tu auras ainsi ton agrégation.

5) Lorsque je crée ce model, j'ai l'impression de réinventer la roue. En effet, la majorité des programmes de gestion d'entreprise possèdent une base de données avec une structure identique. De même, un calendrier, la gestion de dates, des adresses sont des structures à peu près identiques pout tous. N'existe-il pas des models disponibles standards réutilisables avec ou sans modification? Si oui ou?
La réutilisabilité est bien un objectif des concepts actuel!?

?? connais pas. Regardes peut être du côté des ERP open source (Compiere ?)

Détails : Cours et tutoriels pour apprendre UML dont le génial : Cours complet pour apprendre UML 2.0, une série de tutoriels par Laurent Audibert