Discussion :

[aperikub]

Bonjour à tous,

après avoir longuement pataugé dans merise, j'ai a peine sorti la tête de l'eau que je me retrouve noyé dans uml sous le poids de concepts flous et de cours qui se contredisent l'un l'autre...

je suis supposée créer un projet personnel de base de données, j'ai choisi de créer une bd listant tout mon materiel de bricolage et les travaux que j'ai à faire (taches).
chaque tache nécessite du materiel.

une partie du materiel est "renouvelable" (les consommables: vis, forets,etc...), il est ajouté à une liste de course dès que sa quantité stockée tombe à zero, le materiel non renouvelable (outillage, materiel spécialisé etc...) n'est ajouté au stock que si une tache en a besoin, soit en l'achetant, soit en le fabriquant.

la fabrication de materiel vient s'ajouter à la liste de taches.

voila le fonctionnement global, le cours nous a fait créer le mcd de nos projets persos selon la methode merise dans un premier temps, puis nous a demandé de le modéliser avec uml.

après des jours d'incompréhension et d'arrachage de cheveux, le prof a fini par nous expliquer que la partie uml devait concerner le programme servant à administrer la base de données (a priori en php)

autant le diagramme de cas d'utilisations est parfait pour décrire le programme en question mais je bloque sur le diagramme de classe;

j'ai commencé à recréer mon mcd en lui ajoutant des fonctionnalités du programme d'administration (constructeurs, contraintes etc..) avant de me rendre compte qu'en procédant comme ça j'allais recréer une base de données au lieu d'administrer celle que j'ai créé via mon mcd.

donc ma question est: mais qu'est-ce que je suis censé f**tre de ce &!#?%* de diagramme de classes?
je suppose que le but est de générer un script php formulant les requêtes sql permettant de manipuler les tables mais je ne vois vraiment pas comment représenter ça sous forme de classes sans reprendre ce qui est déja couvert par mon mcd.

j'ai envoyé un mail à mon prof mais sa réponse que je n'aurais pas avant plusieurs jours ne répondra probablement pas à ma question et j'ai déja pas mal de retard.

voila mon mcd (je vais probablement enlever l'entité domaine et l'ajouter sous forme d'attribut à l'entité taches):


mon diagramme de cas d'utilisation:


et l'ébauche de diagramme de classe que j'ai laissé tomber:


merci beaucoup d'avance à ceux qui prendront la peine de lire mon pavé et me filer un coup de main!

[Paprick]

Bonjour,
J'avoue ne pas bien comprendre ce que l'on attend de vous...
Tout d'abord, concernant votre MCD, je n'ai pas analysé la justesse de sa conception, mais j'ai un doute sur les types "SOURCE_MATERIEL", "PRIORITE" et "NOM_DOMAINE" que vous avez utilisés... Ils correspondent à quoi dans votre SGBD ?
Concernant le diagramme de classe UML, il peut facilement être déduit en l'état du MCD en adaptant juste le formalisme : votre démarrage n'était pas si mal et il est normal que les rubriques de la future BD soient reprises.
Quant aux méthodes associées à chaque classe, c'est là que les choses ne sont pas claires du tout...

En attendant, voici ce que donne votre MCD en E/A et en UML avec uniquement la reprise des rubriques (traduction temps-réel proposée automatiquement par Looping) :

Bon courage !

[aperikub]

J'avoue ne pas bien comprendre ce que l'on attend de vous...

moi non plus!

j'ai un doute sur les types "SOURCE_MATERIEL", "PRIORITE" et "NOM_DOMAINE" que vous avez utilisés... Ils correspondent à quoi dans votre SGBD ?

-

• source_materiel est une énumeration (achat, fabrication, stock). lorsque l'utilisateur ajoute un n-uplet à materiel, il précise d'ou va venir le matériel. (je pense la mettre par défaut à stock puis si le programme de gestion voit qu'il n'y a pas ce qu'il faut en stock, selon la valeur du booléen "renouvelable" soit il demandera à l'utilisateur de choisir entre achat et fabrication, soit il mettra la valeur à achat.
  
• priorité est une énumeration indiquant le niveau de priorité de la tache
  
• domaine correspond à la catégorie de travaux/materiel (plomberie, électricité etc), c'est un reliquat des précédentes versions de mon modèle, je vais probablement le supprimer
  
  

Concernant le diagramme de classe UML, il peut facilement être déduit en l'état du MCD en adaptant juste le formalisme

c'est justement le problème, ce que je dois décrire avec uml est uniquement le programme d'administration de la base de données (qui elle, est crée avec le script sql issu du mcd) donc je suppose que le diagramme de classes ne doit modéliser que le fonctionnement de ce programme. (c'est en tout cas ce que j'ai compris)

[escartefigue]

bonsoir Aperikub,

Pour que le modèle soit un peu plus réaliste, il faudrait tenir compte des notions suivantes :

MATERIEL
Un équipement et des consommables sont deux types de matériel bien distincts, il est intéressant de les distinguer en utilisant l'héritage.
Pour les consommables, il faut prévoir l'unité de mesure de la quantité : les peintures s'achètent au litre, les clous en sachets de 50 ou de 100, les vis en sachets de 12 ou 20, le fil électrique au mètre etc. Une quantité seule ne veut rien dire.


TRAVAIL ou PROJET
Une tâche doit s'inscrire dans le cadre d'un projet ou d'un travail, chaque travail comporte un certain nombre de tâches.
Par exemple, le travail "entretenir les volets de la maison" comporte les taches "déposer les huisseries", "poncer la vieille peinture", "dépoussiérer", "laquer", "décalaminer la huisserie", "repeindre la huisserie"...


TACHE
Chaque tâche peut requérir du matériel de type consommable et/ou équipement pour une certaine quantité (2 litres d'enduit, une visseuse-dévisseuse, un pinceau...)
Les tâches d'un même travail s'organisent selon une certaine séquence : il faut commencer par démonter les volets avant de les poncer.
D'où la nécessité d'une association réflexive sur la tâche pour piloter les prédécesseurs et successeurs.


Ce qui donne un MCD ressemblant à ceci :

Pièce jointe 584674

Ou le diagramme de classe :
Pièce jointe 584675

[aperikub]

bonsoir,

Pour que le modèle soit un peu plus réaliste, il faudrait tenir compte des notions suivantes :

MATERIEL
Un équipement et des consommables sont deux types de matériel bien distincts, il est intéressant de les distinguer en utilisant l'héritage.

c'est ce que j'avais fait, mais le prof m'a conseillé de simplifier en n'utilisant qu'une entité materiel.

je précis au passage que c'est une U.E de bases de donnée pour débutant visant à donner quelques notions aux étudiants, qui pourront suivre d'autres U.E plus poussées si ils le désirent (ce ne sera clairement pas mon cas!!)
les sujets sont survolés (une semaine sur uml et fini on n'en parle plus!)

le maitre mot est la simplicité, le timing est très très serré, je délaisse les autres cours car je passe 90% de mon temps de travail sur les BDD et je ne peux pas me permettre de m'éterniser d'avantage sur mon mcd, l'important pour l'instant est que je comprenne chaque chapitre, je peaufinerai le modèle plus tard.

Pour les consommables, il faut prévoir l'unité de mesure de la quantité : les peintures s'achètent au litre, les clous en sachets de 50 ou de 100, les vis en sachets de 12 ou 20, le fil électrique au mètre etc. Une quantité seule ne veut rien dire.

bien vu, je modifierai si j'ai le temps mais je pense rendre la variable quantité facultative ou alors fonctionner par "paquets" (je ne vais pas compter le nombre de vis nécessaires pour chaque taches d'autant que j'en perds, j'en casse etc..)

TRAVAIL ou PROJET
Une tâche doit s'inscrire dans le cadre d'un projet ou d'un travail, chaque travail comporte un certain nombre de tâches.
Par exemple, le travail "entretenir les volets de la maison" comporte les taches "déposer les huisseries", "poncer la vieille peinture", "dépoussiérer", "laquer", "décalaminer la huisserie", "repeindre la huisserie"...

c'est plus ou moins à ça que servait l'entité domaine mais je suis loin d’être aussi organisé et ma façon de travailler est plus proche de mcgyver que du compagnonnage donc simplicité: entretenir les volets = couper un morceau d'une vieille table de jardin, y mettre des charnières, et mettre ça à la place des anciens volets tombés en lambeaux!

ce que je cherche à comprendre la, c'est comment représenter sous forme de diagramme de classes un programme d'administration (le coté utilisateur) qui interagisse avec la bd créée a partir du mcd.

est-ce que je crée des classes comme celles que je créerais dans un programme java (le programme d'administration sera en php mais ne l'ayant pas encore vu, le java me parle plus) du genre une classe AjouterTache avec des attributs String pour le nom et la description, une méthode Input qui demande une valeur a l'utilisateur et une autre méthode qui envoi la requête sql ?

merci beaucoup d'avance et merci pour les modèles, je vais me pencher dessus mais la il faut vraiment que j'avance sur uml

[escartefigue]

je précis au passage que c'est une U.E de bases de donnée pour débutant visant à donner quelques notions aux étudiants, qui pourront suivre d'autres U.E plus poussées si ils le désirent (ce ne sera clairement pas mon cas!!)
les sujets sont survolés (une semaine sur uml et fini on n'en parle plus!)

OK pour ça, je donne des pistes d'améliorations mais il faut bien sûr faire avec les contraintes de plannning.
Cela étant, ça ne prend pas beaucoup plus de temps de faire un MCD cohérent qu'un autre qui l'est moins, surtout quand il ne reste plus qu'à copier/coller la solution trouvée sur "developpez.net"

ce que je cherche à comprendre la, c'est comment représenter sous forme de diagramme de classes un programme d'administration (le coté utilisateur) qui interagisse avec la bd créée a partir du mcd. l

Là par contre il y a confusion : la modélisation des données est quasiment sans rapport avec les traitements et donc les programmes...

[Paprick]

Bonsoir,
Soyons clairs : parler de diagramme de classes modélisant une base de données sans y intégrer les rubriques, n'a pas de sens.
Faire un MCD sous forme de modèle E/A, puis considérer ce même MCD sous forme de diagramme de classes UML en ne voulant traiter que les méthodes d'administration de la BD sans considérer les rubriques, relève de l'utopie, surtout si vous nous dites qu'il s'agit d'un cours de BD pour débutants !
Vous êtes dans quel cycle d'enseignement ? Demandez à votre prof de vous donner un petit exemple de ce qu'il attend

[aperikub]

@ escartefigue effectivement ça ne prends pas longtemps théoriquement mais dès que je commence à retoucher au modèle, je finis par y passer des heures mais les modèles que vous me donnez ne tombent pas non plus dans l'oreille d'un sourd (ou plutot les yeux d'un aveugle), quand je retoucherai au modèle je reviendrai vers cette discussion pour m'en inspirer.

@paprick l'énoncé du travail a faire est: "faites l'analyse de votre mini projet selon le modèle UML." il nous est également demandé de réaliser les jeux test.

lors de la dernière web conférence, il a précisé d'une part que c'était la partie programme utilisateur qu'il fallait modéliser avec uml et n'a mentionné que le diagramme de cas d'utilisation (sans pour autant nous dire de ne pas faire les autres diagrammes).

et d'autre part voyant que tout le monde était largué, il a précisé que c'était un cours d'initiation et que le principal était d'arriver à créer un système d'information fonctionnel (bd + programme utilisateur) donc vu ce que vous me dites tous les deux, je suppose qu'il n'attend de nous que le diagramme de cas d'utilisation.

pour ce qui est du cycle d'enseignement c'est une formation mi-universitaire mi-professionnelle du cnam (c'est mon premier semestre).

au final ce qui est le plus perturbant avec ce cours c'est qu'alors que nous ne sommes censés apprendre que les bases, on nous donne des cours vraiment complets (des centaines et des centaines de pages) sur UML, merise, mysql etc... et donc c'est à nous de nous débrouiller pour puiser les quelques notions que nous sommes censés apprendre dans la masse énorme d'information qui nous est fournie

[aperikub]

du coup j'aurais une autre question, (qui n'est pas totalement hors sujet par rapport au titre du post donc je la pose ici), je lisais le cours d'uml 2 de laurent audibert https://laurent-audibert.developpez....e-classes#L3-6

il décrit le passage du diagramme de classe à java, mais, si le diagramme de classes ne sert pas à créer la partie traitement(donc un programme) je ne comprends pas bien le but du programme java créé, on utilise java pour stocker les informations dans des classes java au lieu de les stocker dans une bd?

ou alors est-ce qu'on crée un programme java qui formulera les requetes pour créer les tables de la bd?

[CinePhil]

MA vision de ce que vous demande le prof...

1) Le MCD
Vous avez fait un MCD qui vaut ce qu'il vaut mais vous manquez de temps pour l'améliorer avec notre aide. Soit. Acceptons-le tel quel pour le moment.
Il aurait fallu commencer par l'écriture des règles de gestion des données, surtout quand on débute, mais bon...

Le MCD représente le "quoi" ; quelles entités-types de données allez-vous gérer ?
En l'occurrence, des outils, du matériel, des consommables, des tâches, des projets de travaux...
Côtébase de données, les entités-types deviendront des tables de la BDD et il pourra y avoir d'autres tables, que j'appelle des "tables associatives" qui matérialisent certaines associations entre les entités-types.

2) Le diagramme de cas d'utilisation
Il décrit "qui fait quoi". Il est donc un début de représentation du fonctionnement de la future application en montrant quel acteur peut entreprendre tel cas d'utilisation.

3) Le diagramme de classes
Il est, d'une part, l'équivalent du MCD dans le monde du langage UML et, comme l'a expliqué Prof. Paprick, on peut, grâce à son logiciel de modélisation Looping, passer du MCD au DC en un clic.
Mais si le MCD ne donne que les propriétés, le DC liste aussi les méthodes des classes, c'est à dire les fonctions du "comment".

4) La demande du prof
Il semble vous demander seulement de gérer les données mais pas de faire toute l'application.
Donc dans un premier temps, contentez vous de reprendre dans votre DC sous forme de classes les entités-types du MCD et ajoutez-y les méthodes nécessaires. Ne vous attardez pas trop sur les accesseurs (méthodes commençant par get ou set), ça pourrait prendre de la place inutilement dans votre diagramme et concentrez-vous plutôt sur les méthodes qui vont interagir avec la BDD, à partir de votre diagramme de cas d'utilisation.

Par exemple, vous avez une UC "retirer tâche". Cela implique le lancement par le programme applicatif d'une suppression d'une tâche dans la BDD. Donc il faut, dans la classe "Tache", une méthode "supprimerTache".
Cette méthode lancera une requête DELETE sur la BDD.

Je vous laisse réfléchir de même pour les autres UC de votre diagramme.

[aperikub]

merci cinePhil, le prof vient de me répondre, c'est à peu près ça, il attends de nous:

- le mcd pour modéliser la partie base de données.

- le diagramme de cas d'utilisations pour modéliser l'application (étant donné que c'est le seul diagramme concernant le traitement qu'il demande, les descriptions des use cases sont probablement nécessaires aussi)

- les jeux tests écrits en français

donc en effet il ne demande pas toute l'application pour l'instant, pour la simple et bonne raison que nous n'avons vu ni les requêtes sql, ni le langage php.

donc tous les autres diagrammes sont facultatifs, mais au final je me suis lancé dans des diagrammes de séquences pour décrire le fonctionnement du programme, et un diagramme de classe tel que je le décrivais plus bas (reprenant le classes que je trouverais dans un programme utilisateur en java) va m'être plutôt utile car le logiciel de modélisation que j'utilise simplifie beaucoup le passage du diagramme de classes au diagramme de séquences.

[bruno_pages]

Attention à la direction de vos extends, A et B étant deux UCs :

• Si B est obligatoirement fait lorsque A est activé alors : A ---<<include>>---> B
• Si B est éventuellement fait lorsque A est activé alors : A <---<<extend>>--- B

Par exemple vous voulez certainement dire qu'utiliser du matériel peut aboutir à la modification du stock, mais vous dites l'inverse

Par exemple, vous avez une UC "retirer tâche". Cela implique le lancement par le programme applicatif d'une suppression d'une tâche dans la BDD. Donc il faut, dans la classe "Tache", une méthode "supprimerTache".

Je déconseille fortement de mettre le nom de la classe dans le nom des ses attributs/opérations, cela ne sert à rien à part alourdir le nommage, donc "supprimer"

Il est fort probable que vous ayez un gestionnaire de tâche, qui se charge de leur création, lancement, destruction, recherche, ...

[aperikub]

Attention à la direction de vos extends, A et B étant deux UCs :

• Si B est obligatoirement fait lorsque A est activé alors : A ---<<include>>---> B
• Si B est éventuellement fait lorsque A est activé alors : A <---<<extend>>--- B

Par exemple vous voulez certainement dire qu'utiliser du matériel peut aboutir à la modification du stock, mais vous dites l'inverse

utiliser du matériel aboutit obligatoirement à modifier le stock, ce que je voulais dire c'est que modifier_stock pouvait etre du à utiliser_materiel, reserver_materiel, ou ajouter_materiel.

ce diagramme va probablement beaucoup changer, je suis en train de me pencher sur le code du programme utilisateur et je vois beaucoup de choses auxquelles je n'avais pas pensé (retours en arrière, erreurs et beaucoup d'autres)

[bruno_pages]

utiliser du matériel aboutit obligatoirement à modifier le stock, ce que je voulais dire c'est que modifier_stock pouvait etre du à utiliser_materiel, reserver_materiel, ou ajouter_materiel.

dans ce cas les trois extends doivent être des includes

ce diagramme va probablement beaucoup changer, je suis en train de me pencher sur le code du programme utilisateur et je vois beaucoup de choses auxquelles je n'avais pas pensé (retours en arrière, erreurs et beaucoup d'autres)

attention, votre diagramme est déjà très (trop ?) complexe, les UCs disent ce qu'il faut faire mais en aucun cas comment, leur décomposition ne dépend pas de l'implémentation, de plus seul doit apparaitre ce qui a une vraie plus value

[aperikub]

donc les trois extends deviennent des include mais on est d'accord, le sens ne change pas? (sinon ça voudrait dire que les modifier le stock implique à chaque fois utiliser_materiel, reserver_materiel, et ajouter_materiel c'est bien ça?)

[bruno_pages]

donc les trois extends deviennent des include mais on est d'accord, le sens ne change pas? (sinon ça voudrait dire que les modifier le stock implique à chaque fois utiliser_materiel, reserver_materiel, et ajouter_materiel c'est bien ça?)

oui le sens est le bon pour des includes