A tout hasard (je m'attend à n'avoir aucune réponse   ), y'a t-il une personne qui aurai un UML sur l'algorithme A* générique ?
 
ou alors le code en java qui me mettrai sur la voie ?
 
J'ai fait pas mal de recherche sur google mais on ne parle quasi jamais de cette algo et encore moins du code source ou de l'uml.
 
Merci
 

 

 
t'as du t'y prendre comme un pied

C'est pas courant d'utiliser la notation UML pour décrire un algo !

 
Alors prouve le mois, ca m'arrangerai    
 
De savoir que A* est un algo de recherche le plus court chemin, qu'il utilise des données heuristiques etc... ca je le sait.  
 
Moi je parle d'une représentation UML de cette algo ou encore d'un code java qui me permette d'en déduire cet UML.
 
Alors j'ai peut etre cherché comme un pied mais dans ce cas la, montre moi ce que je n'ai pas trouvé...
 

 
effectivement. Mais ca fait parti d'un exo ou je doit donner une représentation UML de cet algo.

Coucou
 
A croire que tu as de la chance alors, puisque j'ai justement fait mon projet d'IUT sur un logiciel qui recherche le plus court chemin dans une ville... en java    
 
J'ai donc a la fois le code, et le shema UML du projet, ça devrait te convenir    
J'ai rien sous la main là (je suis chez ma copine), mais je te poste tout ça lundi
 
Par contre, l'algo c celui de recherche du plus court chemin, apres te dire si il s'agit du A*, je sais pas

un algo en UML ??? ca veut rien dire en fait ? c'est la representation UML d'une possible implementation de l'algo non ? y a ca aussi en UML, decrire un algo ?

 
Ben vi !
 
 Dans tes diagrammes d'objets/sequences/collaboration tu peux tres bien utiliser l'OCL de UML pour decrir qqs algorythmes qui regiront la vie et l'activite des tes objets/acteurs ou autres instances.

 
Tres interresasnt tout ca    
Merci de ton aide.    
 
J'espére que c'est un algo A* car il y a d'autres algo pour trouver le plus court chemin mais le A* apporte la notion de distance heuristique entre l'état courant et l'état final. Cette distance est une estimation toujour optimiste et permet de "choisir" sans parcourir tout l'arbre le chemin le plus cours.
 
Mon projet est un logiciel qui doit résourdre des casses tetes avec le moins de coup possible.
 
On défini des regles qui sont adapté a l'algo A* et le log résoud le casse tete...
 

c'est quoi comme schéma que tu utilises en UML pour écrire un algo ?

 
Je ne décrit pas l'algo avec l'uml.
 
En faite, mon exo est en 2 partie: 1-Ecrire un UML qui implémente cet algo et 2-Ecrire l'algo en Java et un test sur 2 casse tete (rush-hour et allumettes)
 
Je truc c'est de savoir si je prévoi une class "Noeud", une class Arbre ou Chemin, les méthodes qui les composes, si une interface est necessaire et si oui, a quoi elle ressemble...
Le type de donnée a utiliser (une collection, liste ...)
 
Plus tard je ferai le code mais pour le moment c'est l'UML qui m'interesse (J'ai le pseudo code mais ca m'aide pas des masse)

C'est juste un shéma de classe qu'on te demande ?
c'est pas bien complexe ...  
 
Et tu y gagnerais à réfléchir à ca par toi même ...

 
Ecrire un UML, ça veut rien dire. On dit "Ecrire un diagramme de classe" dans ce cas.
 

 
J'y ai réfléchi. j'y ai passé tt la journée d'hier mais les explication son si claire que j'ai des doutes.
 
Voila ma réflexion:
 

 
Voila, il me manque la moitier des méthodes et je n'ai pas d'idée...

 
Il manque surtout des relations. Mettre un attribut collection n'est pas une bonne idée car c'est une manière d'implémenter une relation, mais le modèle comporte lui une relation.

ah oui, inutile de préciser que ca fait tres peut de temps que je fais du java et des UML...  

c'est con : j'ai retrouvé les cours de maon profs d'IA (http://www.lifl.fr/~routier/enseig [...] essais/ia/. Y a l'aphabeta, le minmax mais pas l'A* ...

 
Oui effectivement, domage mais merci quand meme.

salut,
 
va voir ici, y a un exemple de code c++ :
http://www.experts-exchange.com/Pr [...] 29475.html
 
sinon, pour tes recherches dans google, je sais pas si tu sais mais il vaut mieux écrire "a star" que "a*"

salut,  
 
Désole pour le retard, je dois bien avouer que je t'avais oublié
 
Voici deja le diagramme des classes de mon appli (le metier, donc ce qui t'interesse :  

 
 
Par contre le code est chez moi (je suis au taf là), j'essaie de te poster ça demain soir (ce soir je suis chez ma copine ).
 
Bonne chance  

Merci pour votre aide.
 
Je vais pouvoir bosser la dessus pour mon projet.
 
Si ca interresse des gens, je le mettrai sur le forum.

1- les rôles dans les associations sont pas nommées
2- mélange anglais/français
3- utilise les aggregations/compositions
4- vérifie les cardinalités entre arc et sommet
5- des attributs correspondent en fait aux associations, ça fait doublon

   
 
Ultra constructif, ultra convivial, ultra llama

 
koi, on peu pa doner son navi ?

bin si bien sur, mais argumente un peu plus

 
Ce soar, la ge sui au taf.

c'est quoi ce SMS-Staïle ?

 
Bon, devant les hurlement de mes fans et de la foule en délire, j'explique mes différents points.
 
1- En UML, on peut (pour ne pas dire doit) nommer une relation et chacun de ses rôles (pour simplifier, un des coté de la flèche). Le buit est de caractériser à quoi sert la relation et quel est le rôle de chacun des deux cotés. Par exemple "un étudiant assiste à des cours". Ici étudiant et cours sont des classes, et "assiste à" est le rôle de l'étudiant vis à vis des cours. De plus, on pourrait avoir une seconde relation "Etudiant sêche des cours", ou sêche est le rôle de l'étudiant dans cette seconde relation qui met en jeux les mêmes classes. Ces deux relations peuvent exister dans le même modèle, si on ne les nomme pas, on ne pourra pas les différencier.
 
2- Les rêgles de nommages sont très souvent utilisé en entreprise afin d'homogénéiser les sources des différents développeur. Il y a pas mal de variantes (certainbement autant que de développeurs), mais il y a néanmoins quelques constantes. L'une d'entre elle est que l'on programme dans une seule langue. En effet, c'est très pénible pour la compréhension de passer en continue d'une langue à une une autre (et attention aux tours foireux dus aux faux-amis). D'ou le fait que l'on choisi une langue d'écriture et que l'on s'y tient. A noter que sun propose sur son site des règles de nommages pour java, et qui sont très utilisées par les développeurs :  
http://java.sun.com/docs/codeconv/ [...] C.doc.html
 
3- Aggregation/composition est une partie également du rôle pour montrer qu'un objet est composé d'autres objets. C'est les losanges que l'on voit parfois dans des diagrammes UML. Le losange vide signifie que les objets pointés par la relations appartiennent à l'objet, mais peuvent être éventuellement avoir une existance en dehors de lui. Par exemple des roues appartiennent à une voitures. Les roues font partie de la voiture, mais peuvent avoir une existance propre sans la voiture => losange blanc. Si les roues ne pouvaient pas avoir d'existance hors de la voiture et que la destruction d'une voiture entraine la destruction de ses roues : losange noir. Ici, je sens bien que sommet, arc et rue auraient difficilement une existance en dehors du Plan, d'ou le fait que je pense qu'il doit manquer une notion de ce genre.
 
4- La relation arc->sommet m'étonne car pour moi, un arc et composé de deux sommets. Je ne voit pas à quoi peut ressembler un arc avec 0 ou 1 sommet (sachant que rien n'empêche à un arc d'être lié de chaque coté aux sommets). De plus, si tes arcs sont orienté, tu perds cette information d'orientation, et il y aurait bien en fait deux relations entre Arc et Sommet. Une avec le rôle "début", et une avec le rôle "fin".
 
5- Une association est porteur d'information sur le fait qu'un objet est lié à un autre. On sait par cette relation qu'un plan contient des rues. Rajouter un attribut rue dans Plan duplique cette information pour aucun gain. D'ailleurs, les générateurs de codes dans les AGL vont te générer cet attribut en se basant sur la relation.
 
Bon, je continue encore un coup
 
6- Tu mets des accesseurs dans le modèle. Moi je trouve ça inutilement lourd. Ton modèle contient déjà les attributs, rajouter à chaque fois les différents accesseurs n'apporte aucune information pertinentes par rapport à ce qui est déjà dit par les attributs.
 
 

kadreg
 
 
(euh pour le point 5 tu t'es pas viandé? il a un attribut "vector" de Rue's, pas un attribut "rue" dans plan...)

 
Béah non. Si la relation aurait été 0..1 ou 1, ça aurait été rue, ici, la relation est n, donc c'est un vecteur de rues, mais ça ne change pas la question. Que fait cet attribut ici alors que la relation est déjà là ?

ha ok
mais il a fait pareil pour les autres machins alors
c'est vrai que ça fait double emploi, mais ça me parait plus lisible avec l'attribut que sans moi

 
C'est parceque ses rôles ne sont pas nommés

 
Il est fait avec quel logiciel ce diagramme ?

 
rose

c'est laid ()