A voir également:
- Uml
- Dia uml - Télécharger - Dessin & Illustration
- Visual paradigm for uml download - Télécharger - Gestion de données
- Merise et/ou UML ? - Forum Programmation
- Question uml et modelisation - Forum Programmation
- Examen uml corrigé - Forum Programmation
2 réponses
Bonsoir,
Je dirais qu'un digramme est nécessaire chaque fois qu'il devient trop compliqué d'expliquer quelque chose en un simple paragraphe. (J'irais même jusqu'à dire : chaque fois qu'un paragraphe peut résumer un paragraphe)
Il y a un bon rappel des diagrammes UML sur wikipédia.
Si l'on considère le diagramme des cas (/use case) qui est bien souvent le premier à faire, on peut déjà se demander son utilité : Pour cela la réponse tient dans l'énoncer du projet.
On se demandera et c'est à ta propre appréciation ou imposé par le sujet, si un dictionnaire électronique peut être utilisé par plusieurs types d'utilisateurs. Il y a-t-il un administrateur qui peut ajouter des mots, modifier des définitions etc. Doit-on y faire figurer une entité "serveur" qui serait interrogé à distance par le dictionnaire pour obtenir ses définitions ? Le simple utilisateur doit-il s'identifier ? Que peut faire un utilisateur identifié et que peut faire un utilisateur non-identifé ? Peut-on lister les mots commençant par 'a', faire des recherches par expressions régulières, exporter des définitions/des "pages", accepter/banir des utilisateurs. Un dictionnaire peut être très complexe. On peut voir très loin tout comme on peut voir un utilisateur unique qui ne peut que donner un mot pour en obtenir sa définition. Aussi simple soit le schéma, rien n'empêche de le faire figurer dans un rapport ou un cahier des charges. Il permettra d'insister sur les points importants (dans ce cas ci, les fonctionnalités offertes) et est plus facile à consulter que le(s) paragraphe(s) d'explication se reportant au diagramme lorsque l'on veut se remémorer rapidement les choses.
A l'inverse du diagramme des cas, un diagramme des paquetages où ne figurerait qu'un seul paquetage principal ne sert à rien.
Pour un dictionnaire électronique je ferais:
- Les cas d'utilisations, même si il parait pauvre.
- Un diagramme de séquence si il y assez d'éléments pour ça.
- Des diagrammes d'état-transition si des scénarios nécessitent une explication particulière.
- Un diagramme de paquetage ?
- Un diagramme de classes pour chaque paquetage.
Surtout ne pas oublier que chaque diagramme doit donner lieu a des explications détaillées. On ne gagne pas de temps en mettant un dessin plutôt qu'un gros paragraphe car il faudra toujours expliquer le schéma.
Quelque soit le projet, le mieux selon moi pour savoir quels schémas doivent figurer est de les passer en revu et de voir pour chaque schéma si il a un intérêt. Dès lors qu'un paragraphe est nécessaire pour expliquer un point du projet, un schéma peut venir l'appuyer. Après, simplement s'en remettre à son bon sens, si le projet ne demande qu'un client unique et un serveur, pas de schéma pour faire deux postes et un trait les reliant. On le fera par contre si on veut présenter les différentes façon de relier les deux postes. (cable éthernet / wifi / courant porteur / satellite / cartes postales...)
Voili voilou,
Je te souhaite une bonne réussite de dictionnaire !
M.
Et au besoin, à bientôt ;-)
Je dirais qu'un digramme est nécessaire chaque fois qu'il devient trop compliqué d'expliquer quelque chose en un simple paragraphe. (J'irais même jusqu'à dire : chaque fois qu'un paragraphe peut résumer un paragraphe)
Il y a un bon rappel des diagrammes UML sur wikipédia.
Si l'on considère le diagramme des cas (/use case) qui est bien souvent le premier à faire, on peut déjà se demander son utilité : Pour cela la réponse tient dans l'énoncer du projet.
On se demandera et c'est à ta propre appréciation ou imposé par le sujet, si un dictionnaire électronique peut être utilisé par plusieurs types d'utilisateurs. Il y a-t-il un administrateur qui peut ajouter des mots, modifier des définitions etc. Doit-on y faire figurer une entité "serveur" qui serait interrogé à distance par le dictionnaire pour obtenir ses définitions ? Le simple utilisateur doit-il s'identifier ? Que peut faire un utilisateur identifié et que peut faire un utilisateur non-identifé ? Peut-on lister les mots commençant par 'a', faire des recherches par expressions régulières, exporter des définitions/des "pages", accepter/banir des utilisateurs. Un dictionnaire peut être très complexe. On peut voir très loin tout comme on peut voir un utilisateur unique qui ne peut que donner un mot pour en obtenir sa définition. Aussi simple soit le schéma, rien n'empêche de le faire figurer dans un rapport ou un cahier des charges. Il permettra d'insister sur les points importants (dans ce cas ci, les fonctionnalités offertes) et est plus facile à consulter que le(s) paragraphe(s) d'explication se reportant au diagramme lorsque l'on veut se remémorer rapidement les choses.
A l'inverse du diagramme des cas, un diagramme des paquetages où ne figurerait qu'un seul paquetage principal ne sert à rien.
Pour un dictionnaire électronique je ferais:
- Les cas d'utilisations, même si il parait pauvre.
- Un diagramme de séquence si il y assez d'éléments pour ça.
- Des diagrammes d'état-transition si des scénarios nécessitent une explication particulière.
- Un diagramme de paquetage ?
- Un diagramme de classes pour chaque paquetage.
Surtout ne pas oublier que chaque diagramme doit donner lieu a des explications détaillées. On ne gagne pas de temps en mettant un dessin plutôt qu'un gros paragraphe car il faudra toujours expliquer le schéma.
Quelque soit le projet, le mieux selon moi pour savoir quels schémas doivent figurer est de les passer en revu et de voir pour chaque schéma si il a un intérêt. Dès lors qu'un paragraphe est nécessaire pour expliquer un point du projet, un schéma peut venir l'appuyer. Après, simplement s'en remettre à son bon sens, si le projet ne demande qu'un client unique et un serveur, pas de schéma pour faire deux postes et un trait les reliant. On le fera par contre si on veut présenter les différentes façon de relier les deux postes. (cable éthernet / wifi / courant porteur / satellite / cartes postales...)
Voili voilou,
Je te souhaite une bonne réussite de dictionnaire !
M.
Et au besoin, à bientôt ;-)
Re-bonjour :)
Pour le choix du langage pour faire le projet je pense qu'il vaut mieux prendre celui "proposé"(/imposé) par le professeur. Surtout si c'est elle qui va donner une note, elle n'apprécierait pas de ne pas avoir été écoutée. Les professeurs n'aiment pas se sentir inutiles.
L'UML est une façon de décrire le programme ou des sous-parties du programme sans prendre compte du langage utilisé par la suite. Que ça soit VB ou Java n'a pas vraiment d'importance, on cherche juste à définir ses fonctionnalités ou sa structure. (bienque dans la pratique le choix du langage est toujours fait avant le diagramme de classes)
Si c'est votre (Pardon, je vous ai tutoyé au post précédent ^^ As you wish) première approche avec UML LE schéma indispensable est le diagramme de classes, il serait bien de faire aussi les cas d'utilisations. (qui permet de bien poser dès le départ les actions réalisables avec le programme)
Les tutoriels UML sur developpez.com sont assez bien faits. La page donne un peu plus haut des logiciels (tous gratuits je pense) pour faire des diagrammes UML. Dans le cas du Java, il existe de très bon logiciels pour faciliter le développement et débugguer qui offrent aussi la possibilité de créer ses diagrammes UML. (parfois avec un plugin UML) Les deux plus connus sont je pense NetBeans et Eclipse. Une fois le diagramme de classe réalisé, il est alors possible de générer les fichiers qui serviront de base à la programmation. (déclaration des classes et des méthodes qu'il n'y a plus qu'à remplir) Personnellement je faisais l'UML et le code séparément, j'étais peut-être tout simplement mauvais. :D
Pour le Java, si vous avez fait du C ou du C++ vous ne serez pas perdue car la syntaxe est la même, le langage en lui-même n'est pas si compliqué sinon. Les difficultés majeures sont de trouver comment faire telle ou telle chose par manque de connaissance de ce qui existe. Il y a énormément de classes pour faciliter le travail, encore faut-il savoir qu'elles sont là. La deuxième difficulté n'est pas vraiment Java lui même mais simplement la programmation orientée objet. (Que l'on découvre en général en faisant du Java) Mais je pense que le VB est un peu objet aussi.
Comme pour l'UML, il y a des cours Java sur le site developpez.com.
Une excellente source d'information est la Javadoc. Elle décrit toutes les classes de base. Elle est bien souvent fournie aussi avec le SDK Java. On s'y réfère tellement que l'avoir sur son ordinateur est presque obligatoire.
Du point de vu logiciel et fonctionnement général, le Java est un langage qui est compilé en une sorte de langage assembleur appelé le Byte code. (fichiers .class) Ce langage peut ensuite être lu pour être exécuté par la machine virtuelle java qui sert d'interpréteur. La machine virtuelle est le JRE (Java Runtime Environment) et l'outil de développement est le JDK (Java Development Kit). (téléchargeable sur le site officiel de Sun Microsystems.
Voilà voilà, surtout n'hésitez pas à passer sur le forum en cas de souci ou pour demander un avis sur un UML. On vous dira par exemple qu'une HashMap du paquetage java.util peut être une grande aide pour faire un dictionnaire ;-)
A bientôt,
M.
EDIT. : Programmation objet, héritage.. Besoin d'un coup de pouce ?
Pour le choix du langage pour faire le projet je pense qu'il vaut mieux prendre celui "proposé"(/imposé) par le professeur. Surtout si c'est elle qui va donner une note, elle n'apprécierait pas de ne pas avoir été écoutée. Les professeurs n'aiment pas se sentir inutiles.
L'UML est une façon de décrire le programme ou des sous-parties du programme sans prendre compte du langage utilisé par la suite. Que ça soit VB ou Java n'a pas vraiment d'importance, on cherche juste à définir ses fonctionnalités ou sa structure. (bienque dans la pratique le choix du langage est toujours fait avant le diagramme de classes)
Si c'est votre (Pardon, je vous ai tutoyé au post précédent ^^ As you wish) première approche avec UML LE schéma indispensable est le diagramme de classes, il serait bien de faire aussi les cas d'utilisations. (qui permet de bien poser dès le départ les actions réalisables avec le programme)
Les tutoriels UML sur developpez.com sont assez bien faits. La page donne un peu plus haut des logiciels (tous gratuits je pense) pour faire des diagrammes UML. Dans le cas du Java, il existe de très bon logiciels pour faciliter le développement et débugguer qui offrent aussi la possibilité de créer ses diagrammes UML. (parfois avec un plugin UML) Les deux plus connus sont je pense NetBeans et Eclipse. Une fois le diagramme de classe réalisé, il est alors possible de générer les fichiers qui serviront de base à la programmation. (déclaration des classes et des méthodes qu'il n'y a plus qu'à remplir) Personnellement je faisais l'UML et le code séparément, j'étais peut-être tout simplement mauvais. :D
Pour le Java, si vous avez fait du C ou du C++ vous ne serez pas perdue car la syntaxe est la même, le langage en lui-même n'est pas si compliqué sinon. Les difficultés majeures sont de trouver comment faire telle ou telle chose par manque de connaissance de ce qui existe. Il y a énormément de classes pour faciliter le travail, encore faut-il savoir qu'elles sont là. La deuxième difficulté n'est pas vraiment Java lui même mais simplement la programmation orientée objet. (Que l'on découvre en général en faisant du Java) Mais je pense que le VB est un peu objet aussi.
Comme pour l'UML, il y a des cours Java sur le site developpez.com.
Une excellente source d'information est la Javadoc. Elle décrit toutes les classes de base. Elle est bien souvent fournie aussi avec le SDK Java. On s'y réfère tellement que l'avoir sur son ordinateur est presque obligatoire.
Du point de vu logiciel et fonctionnement général, le Java est un langage qui est compilé en une sorte de langage assembleur appelé le Byte code. (fichiers .class) Ce langage peut ensuite être lu pour être exécuté par la machine virtuelle java qui sert d'interpréteur. La machine virtuelle est le JRE (Java Runtime Environment) et l'outil de développement est le JDK (Java Development Kit). (téléchargeable sur le site officiel de Sun Microsystems.
Voilà voilà, surtout n'hésitez pas à passer sur le forum en cas de souci ou pour demander un avis sur un UML. On vous dira par exemple qu'une HashMap du paquetage java.util peut être une grande aide pour faire un dictionnaire ;-)
A bientôt,
M.
EDIT. : Programmation objet, héritage.. Besoin d'un coup de pouce ?
mais j'ai un autre question a propos de sujet
moi je propose a faire le projet par l'utilisation de vb et bd
mais par contre le professeur de formation elle ma conseiller d'utiliser uml et java
donc quest que vous proposez
et est ce qu'il est vraie que le java est tres difficile a comprendre parapport au vb?
realy im so afraid about it so what do u think
mai avant de dire aurevoire vous pouvez me donnez quelque site des exercices de java tres claire
aussi pour l'uml!!
et maintenant a tout a l'heure:)