Win'design. Cependant il n'est pas gratuit. Dans le cadre de l'enseignement, nous avons un contrat avec la société. Il existe cependant des alternatives gratuites.
Très instructif, encore merci à vous ! J'ai un petit doute concernant cette classe "PersistanceCommande". Sanchant que c'est une classe qui contiendra principalement que des méthodes et pas de propriétés, elle n'a donc pas grand intérêt à être instanciable. Cela signifie-il que cette classe se traduirait par une "interface", impliquant une redéfinition et une implémentation des méthodes dans la classe "Commande" (côté programmation) ? Si tel est le cas, doit t-on dans l'analyse la mentionner comme étant une "interface" (comme ça l'a été pour la classe abstraite) ? Merci d'avance, pour votre aide !.
Merci pour votre message. Avant tout, cette classe ne peut pas être une interface car elle contient au moins des méthodes remplies. Le but n'est pas de demander de redéfinir des méthodes. On peut imaginer soit une classe abstraite avec des méthodes statiques, soit un singleton : c'est généralement cette seconde solution qui est choisie. Reste aussi à savoir où seront placées les informations de connexion (donc en propriété) : de la façon dont est fait ce diagramme, on peut imaginer que ce sera dans cette classe. Ceci n'est qu'un exemple.
@@E_mds J'y vois beaucoup plus clair, merci pour cette clarification ! Mais alors si je comprends bien, la représentation (symbole) qui exprime ce lien de dépendance, peut amener à une "double" interprétation pour une personne externe qui lis le diagramme sans en avoir le contexte ou un descriptif des classes ? Ce que je veux dire c'est que le lien représenté entre "Commande" et "PersistanceCommande" est également utilisé pour signifier qu'une classe implémente une interface. Dans ce cas là, comment une personne extérieure qui essayerait d'interpréter le diagramme peut-il etre persuadé qu'il ne s'agit pas d'une interface mais bien d'une classe abstraite ou un singleton ? (Ps : Désolé, je conçois que ma question peut semblé absurde).
@@vamosplaya2797 Il n'y a pas de question absurde. Normalement, lorsqu'on modélise une interface, il doit être clairement mentionné que c'est une interface, ce qui permet de la distinguer d'une classe normale. Il n'y a donc pas d’ambiguïté.
Extra, j'ai retrouvé tout les éléments dont j'avais besoin, Merci!
Super, il me manquait les significations des associations (fléchées ou non, avec losange plein ou vide, ...), c'est top ! Merci beaucoup :D
Très belle vidéo instructive . Merci
merci un excellent tutoriel
SVP, c'est quoi le software utilisé pour le design des différents diagrammes?
Merci
Win'design. Cependant il n'est pas gratuit. Dans le cadre de l'enseignement, nous avons un contrat avec la société. Il existe cependant des alternatives gratuites.
Très instructif, encore merci à vous ! J'ai un petit doute concernant cette classe "PersistanceCommande". Sanchant que c'est une classe qui contiendra principalement que des méthodes et pas de propriétés, elle n'a donc pas grand intérêt à être instanciable. Cela signifie-il que cette classe se traduirait par une "interface", impliquant une redéfinition et une implémentation des méthodes dans la classe "Commande" (côté programmation) ? Si tel est le cas, doit t-on dans l'analyse la mentionner comme étant une "interface" (comme ça l'a été pour la classe abstraite) ? Merci d'avance, pour votre aide !.
Merci pour votre message. Avant tout, cette classe ne peut pas être une interface car elle contient au moins des méthodes remplies. Le but n'est pas de demander de redéfinir des méthodes. On peut imaginer soit une classe abstraite avec des méthodes statiques, soit un singleton : c'est généralement cette seconde solution qui est choisie. Reste aussi à savoir où seront placées les informations de connexion (donc en propriété) : de la façon dont est fait ce diagramme, on peut imaginer que ce sera dans cette classe. Ceci n'est qu'un exemple.
@@E_mds J'y vois beaucoup plus clair, merci pour cette clarification ! Mais alors si je comprends bien, la représentation (symbole) qui exprime ce lien de dépendance, peut amener à une "double" interprétation pour une personne externe qui lis le diagramme sans en avoir le contexte ou un descriptif des classes ? Ce que je veux dire c'est que le lien représenté entre "Commande" et "PersistanceCommande" est également utilisé pour signifier qu'une classe implémente une interface. Dans ce cas là, comment une personne extérieure qui essayerait d'interpréter le diagramme peut-il etre persuadé qu'il ne s'agit pas d'une interface mais bien d'une classe abstraite ou un singleton ? (Ps : Désolé, je conçois que ma question peut semblé absurde).
@@vamosplaya2797 Il n'y a pas de question absurde.
Normalement, lorsqu'on modélise une interface, il doit être clairement mentionné que c'est une interface, ce qui permet de la distinguer d'une classe normale. Il n'y a donc pas d’ambiguïté.
Super cour, tout est bien expliquer.
Merci 😉👍
👍
Abonner mutualiste
belle video j'ai aimé, s'il vous plait comment faire pour avoir votre logiciel de modelisation win design gratuit! merci
Désolée, ce logiciel n'est pas gratuit. Il existe d'autres logiciels de modélisation gratuits : faites une petite recherche sur Internet.
Comment vous avez ajouter les méthodes sûr les les classes
Au même endroit que les propriétés, dans la partie basse.
Merci !
👍