Forum Programmation.autre Modélisation

Posté par  .
Étiquettes : aucune
0
27
déc.
2004
Bonjour, voilà j'apprends à coder tout seul, parce que j'aime ça, et je pense m'en sortir plutôt pas mal en C, php et bash.
Mais j'ai de grosses lacunes en ce qui concerne la modélisation. Je me rends bien compte que le fait de coder à l'arrache comme je le fait me faire perdre beaucoup de temps. Voila, ça c'était pour le background :)
En ce moment je suis en train de faire un jeu d'élevage en php/Mysql, juste par plaisir, et je me demande si l'UML est mon copain dans ce cas. Qu'en pensez vous ?
Quelqu'un pourrait t'il me conseiller sur un langage de modélisation pour un langage qui n'est pas orienté objet comme le C ?
J'avoue que je ne sait pas par où commencer, ça me retarde dans mon apprentissage. Quelqu'un pourrais me montrer moi des tutos ou des cours qui sont bien faits ?
J'ai souvent STFW à ce sujet, mais je me retrouve noyé de docs et je ne peux pas faire le tri rapidement alors je me permet de demander.

Voilà, a vot' bon coeur M'sieurs Dames :)
  • # Langages de modelisation

    Posté par  . Évalué à 2.

    Y'a plein de langages pour la modélisation qui correspondent à autant de besoin différents. En france merise a eu pas mal de succes et il est plutot simple à appréhender. Doit y avoir des tutos qui trainent sur google. Plus récemment y'a UML qui marche bien. UML est un langage tres complet. Et contrairement à merise ca n'est pas une methode mais bel et bien un langage. Pour débuter avec UML, tu peux commencer à chercher ce qu'est un diagramme de classe et ce qu'est un diagramme de séquence. Ce sont deux types de schémas bien utiles pour identifier les différents composants clés de ton application.
    • [^] # Re: Langages de modelisation

      Posté par  . Évalué à 1.

      Merci de ta réponse.
      Je vais jeter un rapide coup d'oeil à Merise, mais si je peux tout faire avec UML, autant me focaliser sur ça, même si c'est plus dur à appréhender. Est ce une bonne démarche, sachant que je ne suis pas pressé, selon toi ?
      J'irai me procurer le bouquin d'O'REILLY sur le sujet au plus tôt pour faire ça un peu sérieusement.
      Par contre, UML est il adapté si je cherche à créer une appli en C à ton avis ?
      Je croyais qu'il était uniquement adapté aux langages orientés objet, mais après tout, peut être que l'idée "qui peut le plus peut le moins" fonctionne dans ce cas.
      • [^] # Re: Langages de modelisation

        Posté par  . Évalué à 2.

        Dans UML y'a pas mal de diagrammes : c'est pas plus dur appréhender que merise, c'est juste plus complet. Par exemple y'a les diagrammes de déploiement : exemple typique de truc que je n'ai jamais utilisé parce que ca ne correspond pas du tout à mes besoins.
        Pour le fait de faire du C à partir de schemas UML, moi ca ne me choque pas. UML est fortement orienté objet mais ca n'empeche pas que les phases de modelisation permettent de rendre les choses plus claires. Par exemple le diagramme de séquence qui spécifie les interactions entre les différents acteurs du système est pour moi tres utile pour eclaircir les choses indépendament du langage choisi pour l'implémentation.
        Le diagramme de classe va t'etre un peu moins utile meme si il peut toujours servir pour constuire des structures de données pas trop mal fichues.
        C'est parce que tu ne pourra pas utiliser tout UML que ce que tu utilisera ne te sera pas utile.
  • # papier + crayon

    Posté par  (site web personnel) . Évalué à 4.

    J'ai pas encore trouvé mieux (d'un autre côté j'ai jamais codé de gros programmes non plus).

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: papier + crayon

      Posté par  . Évalué à 1.

      Tu utilises du papier et un crayon, mais que fait tu avec ? tu écris les grandes idées de ton prog ? tu utilises quoi comme syntaxe ? un truc que tu as inventé ?
      Ca m'interesse de savoir.
      Je me trompe peut être, mais il me semble que je peux trés bien écrire une appli en UML sur papier, non ?
      • [^] # Re: papier + crayon

        Posté par  (site web personnel) . Évalué à 2.

        Je fais des diagrammes d'objets pour avoir une idée des structures de données et des fonctions/méthodes dont j'aurai besoin et/ou du pseudo code pour me faire une idée du "workflow" général du programme avant de commencer. Pour la syntaxe exact, le diagramme c'est un truc dans le genre des graphs UML qu'on peut faire avec DIA (je connais pas grand chose d'UML en fait) et pour le pseudo code, du C et du français.

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: papier + crayon

        Posté par  (site web personnel) . Évalué à 1.

        >Je me trompe peut être, mais il me semble que je peux trés bien écrire une appli en UML sur papier, non ?

        Non tu ne te trompe pas :)

        Cependant, c'est mon avis personnel, UML me semble necessaire et efficace pour des projets impliquant plusieurs personnes. Pour un projet où tu est le seul developpeur, un papier , un crayon et de la reflexion sont tes meilleurs amis. Les schémas, même hideux, sont par exemples de très bon support à la conception.
        • [^] # Re: papier + crayon

          Posté par  . Évalué à 4.

          J'ajouterais que pour beaucoup de projets libres, si on avait ce genre de schéma en plus des sources (même un scan du brouillon papier), ca permettrait de s'impliquer plus rapidement dans le projet (j'ai deja tente de me mettre a 2 ou trois projets qui avaient l'air intéressants, mais j'ai ete vite découragé par le manque de doc en pluis du code).
          • [^] # Re: papier + crayon

            Posté par  (site web personnel) . Évalué à 1.

            Tout à fait mais pour la plupart des programmeurs la doc est la chose la plus chiante à faire (même si elle est à 100% necessaire ... )

            Et en plus c'est relativement pour plein d'autre domaine autre que l'informatique ...

            C'est malheureux mais c'est comme ça :) (je suis le premier à rechigner à faire de la doc)
            • [^] # Re: papier + crayon

              Posté par  . Évalué à 2.

              C'est dommage ... D'autant plus que souvent la doc existe (sous forme papier+crayon), et que en 10 mn il serait possible d'obtenir quelque chose d'utilisable pour que quelqu'un puisse s'intégrer facilement au projet, quitte à ce que quelqu'un la mette ensuite au propre ...

              De toute facon, tot ou tard le temps passe a faire la doc est gagné: moins de temps a expliquer les grandes lignes du projet a un développeur qui voudrait s'y mettre, moins de temps pour ce nouveau développeur pour comprendre le fonctionnement du logiciel ... donc tant qu'a faire, autant prendre quelques minutes supplémentaires qui seront vites rentabilisées.
          • [^] # Re: papier + crayon

            Posté par  (site web personnel) . Évalué à 2.

            C'est très vrai. Il y a un "Ask Slashdot" qui est passé il y a 2 jours qui parle de ce problème (et apparement c'est pas spécifique au libre) avec quelques solutions de secours: http://ask.slashdot.org/article.pl?sid=04/12/26/2114234(...)

            pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: papier + crayon

          Posté par  . Évalué à 0.

          <ma_vie>
          Je vois tout à fait ce que tu veux dire, mais, va savoir pourquoi, à chaque fois que je mets sur papier les idées de mon prog, je fini toujours par écrire directement du code à peine simplifié.
          Et finalement je n'arrive pas à prendre assez de recul. Ce qui fait que au cours de l'écriture je me dis: "Ah tiens, ça je vais plutot le faire autrement."
          Du coup me voilà en train de reprendre un bout de code, et de fil en aiguille, je ré-ecrit beaucoup de code. En fait je pense mon programme en codant, ce qui est absurde, je m'en rends bien compte maintenant.
          Ce qui me manque en fait ce sont les bases.
          tout ceci est obscur pour moi, sans doute parce que je n'ai suivit aucun cours, ni ne me suis réellement documenté sur le sujet.
          En tout cas merci, mine de rien j'y vois un peu plus clair maintenant.
          </ma_vie>
          • [^] # Re: papier + crayon

            Posté par  (site web personnel) . Évalué à 1.

            je sais que s'est dur mais un peu de reflexion avant de partir tête baissée est souvent très profitable :)

            Qqs autres conseils en vrac (attention je ne suis qu'à moitié développeur dans la vie de tous les jours donc tu en prends ce que tu veux)

            - N'essaye pas de gagner du temps sur des astuces de programmation (j'entends les vielles ruses sioux), pense aux algorythmes derrieres qui doivent être le plus simple et le plus carré possible. ça t'aidera et ça aidera ceux qui veulent te relire. Ce genre d'optimisation sont en générales inutiles (à part pour des parties précises d'un OS) et génératrices de bug

            - Evite le copier / coller : ça à l'air con , évident, MAIS la factoristion de ton code est une chose TRES importante. ça te permet d'être plus lisible, de faire évoluer ton code beaucoup plus simplement. (Par expérience quand tu programme un jeu 2D : les 4 directions doivent être souvent traités de la même manière)
          • [^] # Re: papier + crayon

            Posté par  . Évalué à 2.

            Je vois tout à fait ce que tu veux dire, mais, va savoir pourquoi, à chaque fois que je mets sur papier les idées de mon prog, je fini toujours par écrire directement du code à peine simplifié

            Au minimum, un projet libre devrait contenir un schema structurel de l'appli, et référencer les modules qui correspondent a chaque element de ce schema.

            Et finalement je n'arrive pas à prendre assez de recul. Ce qui fait que au cours de l'écriture je me dis: "Ah tiens, ça je vais plutot le faire autrement."
            Du coup me voilà en train de reprendre un bout de code, et de fil en aiguille, je ré-ecrit beaucoup de code. En fait je pense mon programme en codant, ce qui est absurde, je m'en rends bien compte maintenant.

            Tu développe depuis longtemps? Ca en général c'est ce qui se passe pour ceux qui "débutent" en développement. Avec l'expérience ca va mieux (je me marre parfois lorsque je relis des bouts decode" que j'ai écrits durant mes études).

            tout ceci est obscur pour moi, sans doute parce que je n'ai suivit aucun cours, ni ne me suis réellement documenté sur le sujet.

            Il ne faut pas se décourager, ca vient avec la pratique.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.