Je suis en train de réfléchir sur un utilitaire de dédoublonnage.
Les entrées/sorties sont très simples, et je n'en ai pas grand chose à faire des cas d'utilisation. Mais pour étudier le traitement lui-même, j'aurais aimé le modéliser correctement (histoire d'apprendre, quand même :lol: )
Et là, en UML, je ne vois pas du tout comment faire, j'ai l'impression d'enfoncer les portes ouvertes. Je n'obtiens que quelques schémas qui représentent des choses évidentes, et quand je veux descendre un peu dans l'algo, je ne sais plus comment les représenter. Pourtant au final ce sera programmé objet.
Du coup j'en reviens toujours à mes vieux gribouillages.
Je n'ai pas (mais alors pas) d'atomes crochus avec UML en général. Alors pour un algorithme...
C'est si je ne m'abuse, les diagrammes d'activités qui peuvent donner une représentation de l'algorithme
Ben lorsqu'on en est à la phase de rechercher comment aborder le problème, le gribouillage sur un papier est bien le meilleur des outils. Orienté objet ou pas. Quand tu es vraiment à la phase de conception de l'algorithme, en principe tu ne penses pas objet. L'algorithme c'est l'algorithme. Si tu l'implémentes en C, il ne risque pas d'y avoir beaucoup d'objet. Savoir si on utilisera l'objet pour implémenter ne vient qu'après et en fonction de considérations qui ne sont pas nécessairement en rapport avec l'algorithme. Enfin selon moi.
Il s'agir de faire quoi exactement ? Ca a un rapport avec ton autre post sur le langage naturel ?
Merci :)
Oui ça a aussi rapport avec cet autre post, il s'agit de reconnaissance d'adresses postales, pour des rapprochements et dédoublonnages/déduplications, ou de portions de ces adresses afin de les corriger.
Dans ma tête tout est un peu emmêlé, entre les algos, les différentes phases (surtout qu'il y a forcément des retours en arrière dans certains cas)
.
Enfin ça commence à se préciser, mais j'imagine qu'un outil ou une méthode adéquats pourraient me rendre plus efficaces. D'autant qu'il est difficile d'assumer un gros temps r&d pour une si petite boite, avec un cycle de vie des autres dossiers d'environ 24 à 48 heures.
Et je suis très dispersé de nature, et désordonné :lol:
Je ne sais pas en quoi tu vas coder, mais il y a des langages avec parfois des bouts d'algorithmes, ou même des algorithmes entiers tout prêts. (Non non je ne me contredis pas avec mon post précédent)
Là je pense à C++. En jouant habilement avec les conteneurs map et multimap de la librairie standard en ce qui concerne les doublons et en utilisant une stack pour les retours en arrière, si ça se trouve tu as déjà 80% du boulot qui est mâché. Ce que je veux dire c'est qu'en considérant les algos de la librairie standard, tu as peut être un puzzle dont il te suffit d'assembler les morceux pour avoir ce que tu veux au final. C'est que c'est vachement puissant la librairie standard du C++.
Hum.. oui je sais, C++ n'est plus à la mode. Parait qu'on en a plus besoin depuis qu'il existe Java... Arff :lol: :twisted:
J'utilise Python pour mettre au point. Mais le C++ sera un candidat de choix pour la version finale (du moins la partie moteur).
Je vois que tu es quelqu'un de bon goût :)
Et avec ta démarche, je ne suis pas sûr que le passage par UML s'impose. En tout cas, à ta place, je n'y penserais même pas.
A la rigueur avec un langage tout objet, mais pas avec des langages multi-paradigme comme le sont C++ et Python :)