Je sais qu'il s'agit de méthodologies de conception des objets, mais je n'en sais pas plus.
 
 
Quelqu'un saurait me renseigner ou me filer une bonne URL?

Une URL non, mais y'm semble bien que le gars qui a écrit thinking in Java (gratuit) a aussi un eBook (gratuit également) qui s'intitule Design Patterns in Java. Si m'sieur benou daigne se montrer, il te confirmera ça avec l'url ad hoc. Pour l'instant va faire un tour sur http://penserenjava.free.fr/. Voilà.

je n'ai pas trouvé précisément ce que je cherche mais c'est une adresse à retenir, merci

C'est à benou que je la dois.

www.BruceEckel.com pour le bouquin sur les desing pattern mais il n'est pas terminé.
 
Pour répondre à ta question, un design pattern correspond à ceci. DAns le développement d'application, on retombe toujours sur les memes problèmes. Ces problèmes peuvent etre résolus d'une manière élégante: ce sont les desing pattern. Par exemple, un desing pattern très connu est le modèle MVC (Modèle Vue Controlleur) qui est utilisé dans les architectures n-tiers mais également les GUI SWING par exemple.
 
UML n'a pas grand chose à avoir là dedans. Il y a une corrélation entre les deux mais je ne dirai pas qu'il y a de lien direct ...

Rational a des bonnes docs sur UML : http://www.rational.com/uml/ (en englais, of course )

Un ptit site sur les patterns les plus classiques
 
http://www.patterndepot.com/put/8/JavaPatterns.htm
 
A++

 
Non, non, c'est DéZing patterns : des escadrons pendant la WWII qui dézinguaient les ennemis ! Excuse-moi, c'était le côté solennel de ta présentation et la p'tite inversion qui donnait ce jeu de mot piteux. J'ai ri et j'ai posté... Ne vous en faites pas pour moi, je connais la sortie.

Vraiment, j'ai pas pu me retenir. J'ai lu desing, j'ai entendu dézingue, ou des zingues au choix, et mon imagination délirante trop longtemps réprimée s'est enflammée, m'a arraché le clavier des mains et a tapé un connerie. Note, c'est la première fois que je reprends qqn sur l'orthographe, mais c'est la faute au jeu de mots (j'adore ces conneries). D'ailleurs, d'après un article soumis sur ce forum par... Attendez, je cherche... Putain, dur à trouv. Ca y c'est cycojesus. Donc d'après cet article, les bons hackers adorent les jeux de mots. Je sais y a aucun rapport. Mais aujourd'hui, c'est pas mon jour.

désolé mais j'ai pas beaucoup de temps en ce moment.
 
en plus j'ai pas lu le bouquin de bruce sur les design patterns. donc je peux pas te donner beaucoup plus d'info la dessus

un bon résumé !
 
UML c'est une méthode servant à concevoir des applications objets. Le principe c'est que tu pars d'une description de l'application (les use-case), ca te permet d'identifier les acteurs et les processus à mettre en place ainsi que leurs intéractions. Tu élabores ensuite les différents scénarios pour chacun des processus, ce qui te permet d'identifier les fonctionnalitées auxquelles doivent répondre tes objets.
Tu peux ainsi définir les diagramme de classes (architecture objet de l'application), etc ... etc ... etc ...
 
l'UML c'est une modélisation graphique de tout ce que je viens de raconter, bref, à la  place de l'écrire, tu fait des dessins avec des bonhommes, des carrés, des ronds et pleins de flèche.
 
Le but c'est que ces "dessins" soient compréhensible à la fois par la communauté des développeurs et des chefs de projet (et même des clients). Ainsi la modélisation peut servir de cahier des charges pour une application.
 
voila pour l'UML en gros ...
 
En tout cas, tout développeur objet devrait être capacble de faire des diagramme de classe. Si y a un seul truc de bien dans l'UML, c'est ca !

UML c'est une méthode servant à concevoir des applications objets.
 
UML n'est pas une méthode, c'est juste une notation.
 
Le principe c'est que tu pars d'une description de l'application (les use-case), ca te permet d'identifier les acteurs et les processus à mettre en place ainsi que leurs intéractions. Tu élabores ensuite les différents scénarios pour chacun des processus, ce qui te permet d'identifier les fonctionnalitées auxquelles doivent répondre tes objets.
Tu peux ainsi définir les diagramme de classes (architecture objet de l'application), etc ... etc ... etc ...
 
Ca c'est un processus de développement basé sur UML, mais on peut en faire d'autre. J'explique souvent qu'UML est une grande boite à outil, de laquelle on va sortir le diagramme qui exprime le mieux ce que l'on compte modéliser.
 
l'UML c'est une modélisation graphique de tout ce que je viens de raconter, bref, à la  place de l'écrire, tu fait des dessins avec des bonhommes, des carrés, des ronds et pleins de flèche.
 
Et des cubes, moi j'aime bien les cubes
 
En tout cas, tout développeur objet devrait être capacble de faire des diagramme de classe. Si y a un seul truc de bien dans l'UML, c'est ca !
 
Ca dépend ce que tu veux exprimer. Je bosse dans l'UML, et j'ai trouver à utiliser tous les diagrammes, mais certains sont dans des cas vraiment particuliers.

UML n'est pas une méthode, c'est juste une notation.
 
ou c'est une notation, tout comme les MCD et MLD en sont une avec merise. Je considère pour ma part que c'est une méthode : ca permet de partir d'un problème à une solution en suivant des étapes clairement définies : une méthode, koi Mais bon tu as raison : "officielement" ce n'est qu'une notation, maintenant quand tu vois rose ...
 
Ca c'est un processus de développement basé sur UML, mais on peut en faire d'autre. J'explique souvent qu'UML est une grande boite à outil, de laquelle on va sortir le diagramme qui exprime le mieux ce que l'on compte modéliser.
 
c'était pour résumé. Je sais bien qu'on peut s'en servir pour d'autre chose, mais concrétement, les gens s'en servent pour quoi ? développer des aplis objets, et souvent d'après le processus que j'ai décrit, nan ?
 
Et des cubes, moi j'aime bien les cubes
 
moi, mon préferé c'est le bonhomme !!! actor rulez !
 
Ca dépend ce que tu veux exprimer. Je bosse dans l'UML, et j'ai trouver à utiliser tous les diagrammes, mais certains sont dans des cas vraiment particuliers.
 
ouais mais les diagrammes de classes c'est vachement pratique !!
contrairement à d'autres schémas que je trouve super lourd à utiliser (diagramme de séquence, par exemple)

les Diagrammes de séquence, je les trouve très pratique mais un peu chiant à faire quand on est pas totalement sûr de savoir ce qu'on va faire, ça te force à bien concevoir ton appli avant de passer au codage bourrin.
Le diagramme de classes (ou d'architecture) c'est la base, c'est tout simplement essentiel.

les diqgramme de séquence je trouve que c'est trop lourd à dessiner ... et pas du tout adapté pour décrire des scénarion un peu complexe.
du coup, on s'en sert que pour décrire de base et ca sert quasiment à rien ...
 
C'est mon point de vue, hein !!!

Je considère pour ma part que c'est une méthode : ca permet de partir d'un problème à une solution en suivant des étapes clairement définies : une méthode, koi
 
 Ou ça des étapes ? Ce n'est pas parcequ'une boite à outil contient un marteau qu'il faut donner des coups de marteau dès que l'on a quelque chose à monter.
 
Mais bon tu as raison : "officielement" ce n'est qu'une notation, maintenant quand tu vois rose ...
 
Oui, je vois bien rose
 
Mais rose est principalement adapté au processus défini par rational, le RUP, basé sur UML. Mais rien n'empèche de faire en suivant d'autres processus. IBM a pas mal bossé sur des processus en interne et s'en sont éloignés. Dans le secteur des communications d'est encore pire, puisque les gens ont adaptté des méthodes non-objet à UML.  
 
 
 
c'était pour résumé. Je sais bien qu'on peut s'en servir pour d'autre chose, mais concrétement, les gens s'en servent pour quoi ? développer des aplis objets, et souvent d'après le processus que j'ai décrit, nan ?
 
Il y a deux cas. Le premier est le petit coup d'UML pour un projet objet typé gestion ou, généralement on va suivre un RUP allégé, donc effectivement, on retombe sur le processus que tu présente. Mais il y a beaucoup de projets (bon, evidement, comme c'est là que je met mon nez, je vois qu'eux) qui utilisent UML avec n'importe quoi comme méthode. Petit exemple, sachant que RM-ODP n'a pas grand chose d'objet : http://www.lip6.fr/reports/lip6.1999.024.html
 
 
 
contrairement à d'autres schémas que je trouve super lourd à utiliser (diagramme de séquence, par exemple)
 
Celui là, tout le monde le trouve lourd (et encore, le métamodèle est encore pire que ce que l'on voit), d'autant plus que l'équivalent dans les spécifications d'automates sont beaucoup plus réussi. Le plus gros manque étant de référencer un diagramme de séquyence dans un diagramme plus complexe.

[jfdsdjhfuetppo]--Message édité par kadreg--[/jfdsdjhfuetppo]

t'as l'air de bien maîtriser le sujet, et je n'en n'ai pas fait énormément, donc je m'incline
 
mais j'aimerai bien voir ce que donne l'utilisation d'UML dans un autre domaine que la prog objet !

 
Hum, là je suis à la maison, donc j'ai pas d'AGL sous la main pour dessiner. La seule chose que j'ai c'est ça :  
 
http://kadreg.free.fr/perso/activity-monopoly.png
 
La modélisation d'un processus de devoir à faire à l'école grâce à un diagramme d'activitées. La modélisation des processus de développement est une des grosses voies de recherche d'UML à l'heure actuelle.
 
Sinon un truc qui m'avait choqué une fois chez un opérateur télécom. Ils commencent par modéliser les données d'application dans un diagramme static avec les attributs. Ensuite, ils créent un second diagramme de classe avec des opérations qui vont agir sur les attributs, les classes n'étant que des espaces de nommages pour fonctions permettant de les regrouper par type de traitement (ce qui n'est pas complètement faux en UML, les classes sont des espaces de nommages), et pour lier les deux, ils ont des liens de dépendances entre les classes support d'attribut et les classes support de fonctions.
 
Cette façon de modéliser dérive d'une méthode pas objet du tout ou l'on part des données statiques et l'on y rajoute des traitements. En C, c'est structures, puis fonctions. En UML, on a une paire de classes.

 
 
ils s'en est raconté des trucs ici en 24h
 
Merci à tous pour vos infos, je mourrai moins con