Discussion :

[TheCaribouX]

Bonjour!

J'espère être au bon endroit pour ma question...

Comme précisé dans plusieurs posts précédants, j'ai une certaine habitude de coder, mais pas forcement de faire du code propre ou documenté. Je suis en train d'essayer de changer mes habitudes mais j'aurais besoin d'un ptit coup de main niveau documentation.

Sauriez vous me dire quels sont les shémas, documents, etc. à fournir pour avoir une documentation sérieuse. J'entends par là pas uniquement de la doc générée (ca j'y ai déjà pensé ), mais au niveau shémas UML, ou autre. Toute proposition est la bienvenue!

[bruman]

Commence par lire un tuto ou une doc ou encore mieux un bouquin sur UML.
Dedans, il t'expliquerons comment faire chaque schéma et l'intéret de chacun. Après, tu pourras utiliser les schéma qui te sembleront les plus pertinents.

[TheCaribouX]

Mmmh, en soit les shémas UML je les ai déjà étudiés (y'a loooongtemps, ), ma question était plutot dans le genre "y'a t'il des shémas indispensables à une bonne documentation?" ou encore "en dehors de UML ou de la doc technique générée, y'a t'il d'autre outils/méthodes que je ne connaisse pas (vu mes connaissances, je doute pas qu il doit y en avoir...) pour mener à bien un projet dans son ensemble en terme de documentation?"

j'espère avoir été suffisemment compréhensible..

[hed62]

Va faire un tour coté Méthodes

et là aussi : Tutos Méthodes

[oca]

peut-être BPMN ?
A+

[TheCaribouX]

Je commence à me rendre rendre compte que l'UML est juste un moyen de "mettre sur papier" des concepts autrement que par du texte ennuyant et beaucoup moins ce que inconsciemment j'avais tendance à croire, une série de documents , genre ~méthode de conception~, à fournir pour bien documenter son programme.

Héhé je découvre une autre facon de travailler alors faut pas trop m'en vouloir si je parais un peu à l'ouest...

Merci pour vos réponses, je vais aller farfouiller du coté "requirements specification"

[oca]

Regarde aussi ce que l'on nomme la MDA (Model Driven Archtecture).
C'est un standard normalisé par l'OMG

Dans les outils sympa qui gèrent bien la conception par modèles et la documentation, il y a TopCased UML (dans cette outil, tu peux faire un schéma,
le documenter, generer du code ET de la doc, modifier certaine partie de la doc sans que tes modifs soient perdue à la prochaine génération... pas mal du tout...)

A+

[hed62]

UML est un langage, non une méthode effectivement.

On peus donc l'utiliser pour ce que l'on veut : documenter un programme, expliquer quelque chose à quelqu'un, mettre ses idées au clair, lm'employer au sein d'une méthode de conception/developpement d'application.

MDA est un cran au dessus encore de l'utilisation d'une méthode basée sur UML, car elle demande la définition de models et meta models, notion pas évidente à apréhender.

l'UML est juste un moyen de "mettre sur papier" des concepts autrement que par du texte ennuyant

Le gain est non seulement la lisibilité (et la motivation à lire), mais surtout la formalisation (même si UML n'est que semi-formel, le français est totalement ambigu et informel).

Si tu as des questions, n'hésite pas

[TheCaribouX]

Si tu as des questions, n'hésite pas

je vais quand meme essayer d'apprendre par moi-meme...le coté "forum qui développe ton projet a ta place" c'est pas de mon gout, et d'apres ce que j'ai pu observer, pas de celui du forum non plus ... mais y'a bien des chances que je revienne poster par ici

++

[oca]

tant qu'on y est... tu peux aussi jeter un oeil à l'approche DSL / DSM,
c'est aussi une affaire de langages et de modèles, mais basée sur les notions
de ton métier plutôt que sur des notions "générales"
A+

[TheCaribouX]

Juste par curiosité, je viens juste de me renseigner un peu sur DSL/DSM, BPMN, ou encore MDA, et l'impression que ca me laisse, c'est que la tendance actuelle est à générer le plus automatiquement possible le code à partir d'une syntaxe plus haut niveau faite de diagramme principalement.

Ayant jusqu'à présent "tout codé moi meme", cette tendance m'inquiete un peu.. ca voudrait dire qu'un ingénieur développement de nos jours devrait etre plus formé à faire des jolis diagrammes bien structurés et remaniables, plutot que savoir faire un "Hello world!" dans les principaux languages (rassurez moi.. j'me sens vieux-jeu la... )

[oca]

Je pense qu'il faut garder un oeil sur ces approches, sans pour autant jetter
ce que l'on a fait jusqu'à present.

Le risque avec les approches par génération automatique, c'est que si il survient un problème... (et il en survient... si si...) on est vide largué si on ne comprend pas le code qui est généré... Donc "Hello world" à encore de beaux jours devant lui.

Après il faut aussi voir si le jeu en vaut la chandelle, et toujours partir du besoin... Est-ce que j'ai besoin d'intégrer différent langages ? sur différentes plateformes ? est ce que je vais tout faire moi-même ou est-ce que mon entreprise est divisée en business analystes / programmeurs / graphistes et autres rôles...

Je ne crois pas qu'il y ai une réponse unique à la question "pour ou contre le MDA". Mais savoir ce que c'est, aide à savoir si on en veut ou non...

Pour le moment j'ai encore une approche très code comme toi.

[TheCaribouX]

Ouf

merci pour les infos!