Documentation française sur MDA

Posté par (page perso) . Modéré par Fabien Penso.
Tags :
0
30
juil.
2002
Technologie
Pour tout ceux qui modélisent avant de coder et qui travaillent sur les architectures middlewares à base de composants voici un rapport en français sur la nouvelle norme de l'OMG, j'ai nommé MDA (Model Driven Architecture).

Ce rapport a l'avantage de parcourir un peu tous les aspects de la norme, d'être rapide à lire et surtout d'être en français.

Comme on peut le voir depuis quelques mois, plusieurs projets libres s'intéressent très fortement à MDA (dont ArgoUML et dotGNU), et on peut parier que d'ici quelques temps, MDA sera aussi important qu'UML dans le processus de développement d'architectures objets.

Aller plus loin

  • # La modélisation c'est bien beau...

    Posté par . Évalué à 10.

    Mais encore faut t'il savoir l'utiliser. Combien j'ai pu voir de projets ou l'on passait du temps à faire de belles modélisations UML (ou Merise) pour finalement oublier completement le projet derrière et avoir un truc inutilisable à la fin.

    Y'a trop de gens qui finissent par faire de la modélisation pour faire de la modélisation comme on fait de l'art pour l'art.

    L'avantage du développement en bazar (à l'opposé du développement en cathédrale) c'est qu'il impose implicitement de modeliser ce qu'il faut, pas question de passer un an a modéliser un gros projet (ca s'est vu) pour ne rien avoir au bout.

    Mais bon, on verra comment la chose est acceuillie en entreprise, mais si c'est pour refaire les mêmes conneries qu'on peut voir avec merise et UML, bof...
    • [^] # Re: La modélisation c'est bien beau...

      Posté par . Évalué à -5.

      Si tu as dans la tête un modèle de développement Waterfall ( http://www.objectmentor.com/resources/articles/IIDI.pdf(...) ), tu peu apprendre l'horticulture tout de suite et quitter l'informatique.
      Il a été éliminé au début des années 80.

      Faudrait voire à pas dire que des conneries sur le MDA.

      Tiens, j'ai vu un truc marrant l'autre fois : un programme 3 fois plus court (et 100 fois plus rapide mais c'est une autre histoire) en fonctionnel qu'en objet.
      La feinte ?
      Le coeur du projet est un double dispaching géant donc on gagne rien avec le principe de substitution de Liskov (hiérarchie courte).
      A noter dans nos petites têtes.
      • [^] # Re: La modélisation c'est bien beau...

        Posté par (page perso) . Évalué à 10.

        Pourquoi tu imagines que aza parles du cycle de vie waterfall (comment planifier) et non pas de modèle (comment représenter). Plutôt que de mal imaginer ce qu'il veut dire, laisse le parler.

        Comme tu sembles aimer les gens un peu agressif, pour te faire plaisir je te dirais j'ai un peu du mal à imaginer comment tu peux te prétendre être crédibles sur des méthodes quand tu compares des choux et des carottes ?

        Ensuite, si tu penses qu'il dit des conneries développes, mais ne l'agresses pas parce qu'ils osent emettre des doutes sur l'intérêt des méthodes que tu présentes, défends les.

        Et enfin si ton exemple il est beau au lieu de dire qu'il existe un programme bien écrit présente le nous (lien vers le source). Et le principe de substitution de Listkov c'est sûrement bien, mais essaies de te mettre au niveau de la plupart des gens qui te lisent et qui ne savent pas forcément ce que c'est...


        En tout cas pour moi si les méthodes sont géniales mais imbitables, ou que ceux qui les défendent ne veulent pas faire un effort pour se mettre au niveau des autres, elles n'ont aucun intérêt parce que personne n'y aura accès sauf des prétendus spécialistes...qui nous casserons les couilles quand il s'agira de faire les programmes.

        Je pense que l'UML est intéressant mais quand c'est adapté, alors j'aimerais connaître ton opinion sur le type de développement pour lequel le gain de la modélisation est supérieur au surcoût de développement rapide fait avec une conception médiocre (est ce que l'on doit remodéliser cat en UML), le type de projet auquel c'est adapté (noyau, outil à la Dacode, spamassassin, site web)?
        • [^] # précision "one best way" VS TIMTOWTDI

          Posté par (page perso) . Évalué à 10.

          :%s/UML/MDA/g sur la précédente.

          Ensuite MDA c'est fun, ils constatent que la multiplication des normes n'a pas aidé à résoudre le problème de préennité des architecture (UNIX/C ont quand même leurs 30 balais bien tapés :). Alors, ils proposent une nouvelle norme (lol).

          Et si les normes à la "One Best Way" (il n'a qu'une manière de faire) étaient le problème? Les normes nouvelles ISO conduisent à la réingénieurie systématique des processus et des normes parce qu'ils se font croûter leur Chiffre d'Affaire par des trucs plus évolutifs comme les RFCs. Une nouvelle norme figée (car elle ne propose pas dans sa description son moyen d'évoluer) va-t-elle réussir?

          Enfin, comme d'habitude, on veut refaire le monde et on refuse de voir l'évidence : la création logiciel est avant tout une affaire d'hommes et de femmes qui en tirent du plaisir. Pourquoi sinon les gens fairaient du logiciel Libre?

          En tout cas j'espère qu'il y aura un jour un Libre Software Modelisation HOWTO dans l'esprit de
          http://www.tldp.org/HOWTO/Software-Proj-Mgmt-HOWTO/(...)
          (gestion de projet).
          Car non seulement cet doc est pertinente, mais en plus on peut la faire évoluer.
        • [^] # Re: La modélisation c'est bien beau...

          Posté par (page perso) . Évalué à 10.

          L'intéret de la modélisation dépend du projet.

          Si tu es tout seul sur un projet, tu n'es bien spur pas obligé. Mais dès que de mombreuses personnes travaillent ensemble, cela devient nécessaire.

          Tu parles des logiciels libres. Renseigne toi bien auprès des Gourous du libre, et tu verras qu'eux aussi utilisent de tels méthodes (Linus et RMS y compris). Certes, ils n'utilisent pas UML car ils ne font pas d'objet, mais ils ne pissent pas du code sans réfléchir. Lis "Tribune Libre" si tu veux comprendre leur point de vue.

          UML permet justement de réfléchir sur un modèle, en parlant le même langage. Quand tu décris ton logiciel en francais, de manière textuelle, on peut dire que tu modélises. UML permet de voir ca de manière graphique, ce qui est plus efficace.

          En plus, les outils de génération de code sont de plus en plus efficaces, et une très grosse partie du code est générée (ce procédé s'améliore d'année en année).

          Enfin, niveau efficacité et simplicité, après un peu d'habitude, je peux te certifier que tu vas plus vite à développer un soft en le modélisant par UML plutot qu'en codant direct (encore une fois, si tu veux modéliser cat, l'intéret est très relatif).

          si tu veux une doc en fr, http://uml.free.fr(...)

          Pour mda, l'avantage est de modéliser tes classes, pusi t'appuie sur un bouton, et ca te génère tes classes toutes prêtes pour J2EE, Corba, ...
          Y'a pas que ca, mais au moins, c'est du concret.
          • [^] # Re: La modélisation c'est bien beau...

            Posté par . Évalué à 10.

            >Renseigne toi bien auprès des Gourous du libre, et >tu verras qu'eux aussi utilisent de tels méthodes (Linus et RMS y compris).

            Je n'ai jamais dit qu'il ne fallait pas modéliser. J'ai dit que trop de gens n'arrivent pas à trouver la juste proportion de modélisation et te partent dans des délires qui font de très beaux schémas mais qui finissent par éclater le planning parceque le code ne suit pas derrière.

            > En plus, les outils de génération de code sont de plus en plus efficaces, et une très grosse partie du code est générée (ce procédé s'améliore d'année en année).

            J'ai jamais trop eu confiance en ces machins. Quand je faisais du merise à ne plus savoir qu'en faire on m'avait collé sous windev (j'ai pas choisi) avec son module de génération de code suite au MCD que tu lui donnais.

            Le résultat c'etait que tu avais un nid à bug. Les fonctions générées ne fonctionnaient jamais toutes, il fallait repasser à chaque fois derrière l'interface de l'application parceque tout etait mis n'importe comment....

            Bref, ca m'a laissé un sale souvenir. Peut être que les outils de génération de code sont mieux fichus aujourd'hui, mais pour ma part je préfère utiliser un composant déja écrit (et débbuggé) plutot que faire générer une classe par un truc dans lequel je n'ai pas confiance.

            Mais bon, je ne demande qu'a avoir tort.
            • [^] # Re: La modélisation c'est bien beau...

              Posté par . Évalué à 3.

              J'ai dit que trop de gens n'arrivent pas à trouver la juste proportion de modélisation et te partent dans des délires qui font de très beaux schémas mais qui finissent par éclater le planning parceque le code ne suit pas derrière.

              c'est l'antipattern March to the death (désolé pour le anglisismes, j'hésite à traduire le vocubulaire des patterns), c'est très documenté (c2.com ?).

              Pour les outils, actuellement le top c'est le round-trip et c'est pas top, justement. Peut-être qu'avec Eclipse ça va devenir mieux. Peut-être pas.
          • [^] # Re: La modélisation c'est bien beau...

            Posté par (page perso) . Évalué à 4.

            >L'intéret de la modélisation dépend du projet.
            certes.

            >Si tu es tout seul sur un projet, tu n'es bien >sur pas obligé. Mais dès que de mombreuses >personnes travaillent ensemble, cela devient >nécessaire.

            Seul ou pas, des qu'un projet a une certaine ampleur, il est nécessaire de modéliser.

            Dans tous les cas, il ne s'agit bien entendu pas de 'coder sans réfléchir'.

            Le problème est donc dans la methode à utiliser (nommage, discussion et schemas essentiellement ).

            Le plus important est de trouber les mots et les schemas qui permettront de faire en sorte que chacun des collaborateurs comprendra la conception globale et les implementations.

            Comme le disait jul un peu plus haut :
            ' la création logicielle est avant tout une affaire d'hommes et de femmes qui en tirent du plaisir. Pourquoi sinon les gens fairaient du logiciel Libre?'

            Chaque ( bon ) chef de projet s'adapte donc à
            ses developpeurs et au projet, pour trouver un langage dédié au projet qui permettra une bonne
            evolution de ce projet.

            "You have enemies? Good. That means you've stood up for something in your life." Winston Churchill

      • [^] # H2O+alcooloïde anisé (pastaga, non ?)

        Posté par . Évalué à 1.

        Hé, le double dispatching, c'est quoi le principe de substitution de liskov von karajan ?
        • [^] # Re: H2O+alcooloïde anisé (pastaga, non ?)

          Posté par . Évalué à -7.

          http://www.google.fr/search?hl=fr&ie=UTF-8&oe=UTF-8&q=l(...)

          T'as dû chercher loin pour pas trouver !

          C'est la principe de sous-typage par héritage.
          Il dit : une instance de la classe fille est une instance de la classe mère, ça implique systématiquement une inclusion ensembliste (t'as gagné de droit de trouver tout seul pourquoi, si tu trouve pas, cherche vers la notion de contrat).


          http://c2.com/cgi/wiki?DoubleDispatch(...)
          c'est clair, pas de commentaire.

          la complexité en nombre métodes est de nombre de visiteurs*nombre de visités.
          Les techniques objets n'apportent rien par rapport aux types sommes des langages fonctionnels dans ce cas là et les pattern-matching sont plus courts à écrire.
    • [^] # probablement

      Posté par . Évalué à 10.

      Oui, c'est en ne faisant pas de modelisation qu'on arrive a des trucs codes n'importe comment.

      "- Mais pourquoi cette fonctionalite elle est codee avec un mechant hack a peine comprehensible par l'auteur ?
      - Ben au debut on y avait pas pense, alors quand on l'a ajoute c'etait pas trop prevu pour"

      "- Mais ces deux {classes/fonctions} elles font pas un peu la meme chose ?
      - Euh, tu crois ? Je sais pas, celle-la elle est la depuis le debut et je sais plus si elle est utilisee. L'autre j'en avait besoin pour corriger ca, c'est sur"

      Aller... Rappelons non que d'apres Eric S. Raymond le modele "bazaar" est tres bien quand on a tout plein de developpeurs, mais il dit clairement que la productivite est reduite de facon considerable (bien que largement compensee par le nombre de developpeurs).
      • [^] # Re: probablement

        Posté par . Évalué à 10.

        Je le répète : je n'ai pas dit qu'il ne fallait pas faire de modélisation mais qu'elle était souvent très mal faite.

        Ce qui arrive trop souvent c'est qu'on te pond un cahier des charges long comme le bras parceque le client a des visions grandioses et veut un logiciel génial tout en ne sachant pas exactement ce qu'il veut en fait.

        Tu prends donc des analystes et tu les enfermes dans une pièce pour qu'ils te pondent la modélisation qui va bien. Ils y passent donc du temps, se chamaillent, trouvent que le schéma est pas si joli, recommencent, enculent les mouches pour savoir des trucs dont on se fout royalement, font des réunions, des réunions, et encore des réunions (très important les réunions). Au final tu viens d'éclater le planning imparti à la modélisation et le logiciel n'existe même pas.

        Tu mets donc tes développeurs au boulot et la tu te rends compte que l'expert C++ qu'une SSII t'as refilé est un mec qui a vient d'avoir sa maitrise de chimie, qu'il a eu un mois de formation dans sa SSII comme seule experience de l'informatique, qu'il peine à pondre un printf, alors tu penses bien que tes machins UML pour lui c'est des blagues de carambars.

        Bref une fois que tu as réussi à faire coder tout ca, tu te retrouves avec un truc qui a explosé les délais, qui ne correspond pas a ce que veux le client (qui a changé d'avis 50 fois depuis le début du projet) qui couvre 10% des fonctions dont on aurait vraiment besoin et que personne ne veut et ne peut utiliser.

        Bref, passer trop de temps sur la modélisation, c'est un moyen excellent de rater un projet.

        Ca ne veut pas dire qu'il ne faut pas faire de modélisation, attention, mais juste qu'il ne faut pas trop sacraliser la chose.
        • [^] # Re: probablement

          Posté par . Évalué à -5.

          C'est du vécu ?

          Même le truc du type avec sa maitrîse de chimie ?
          • [^] # Re: probablement

            Posté par . Évalué à 6.

            En fait j'ai jamais eu tout ca dans le même projet mais j'ai vu ca séparement.

            - Le coup des mecs qui passent un temps fous à modéliser un projet avec UML et qui au bout du compte ont un tas de papier énorme que personne ne va relire (et aucune ligne de code écrite), ca j'ai vu.

            - Le coup du client qui ne sait pas ce qu'il veut (et qui parfois demande qu'on lui dise à sa place ce qu'il veut) ca c'est quasiment tout le temps

            - Le coup du type avec la maitrise de chimie c'est également très véridique. Il y'a un nombre de chimiste et de physicien très important dans les SSII, suite à l'age d'or d'il y'a deux ans. Ils vont se réduire un peu jusqu'a ce que le secteur reparte, je pense.
        • [^] # Re: probablement

          Posté par . Évalué à 1.

          l'expert C++ [...] peine à pondre un printf,[...]

          On m'a toujours dit d'utiliser cout, pas printf en C++. On m'aurait menti?

          Ceci, c'est vrai que dans ce cas là, il doit pas être bon :)
        • [^] # Re: probablement

          Posté par . Évalué à -2.

          l'expert C++ [...] peine à pondre un printf,[...]

          On m'a toujours dit d'utiliser cout, pas printf en C++. On m'aurait menti?

          Ceci dit, c'est vrai que dans ce cas là, il doit pas être bon :)
      • [^] # Re: probablement

        Posté par . Évalué à 2.

        Je crois qu'il dit que la productivité de TOUT projet n'augmente pas de 100% de sa force de travail quand on rajoute un développeur au dessus d'une certaine taille mais que les couts eux augmentent de euh 100% d'un salaire. Bazaar ou pas.
        Je crois me souvenir qu'il dit quand même que le modéle open source est favorisé dans ce domaine puisque les développeurs qui se rajoutent à un projet n'ont à fournir aucun effort d'intégration à la hiérarchie d'une entreprise.
        http://www.tuxedo.org/~esr/writings/cathedral-bazaar/magic-cauldron(...)
        Il dit clairement par contre dans le bazaar que le débuggage d'un logiciel ouvert est immunisé à ce probléme.
        • [^] # Re: probablement

          Posté par . Évalué à 2.

          open source est favorisé parce que les développeurs n'ont à fournir aucun effort d'intégration à la hiérarchie d'une entreprise.
          Bof, c'est facile de s'intégrer et les conflits de personne existent aussi en OpenSource (lit kernel-traffic tu verra).
          • [^] # Re: probablement

            Posté par . Évalué à 5.

            Il ne parle pas de s'intégrer à un nouvel environnement ou à de nouvelles têtes, il ne parle pas de conflits entre personnes (personnellement, je les trouve trés productifs au contraire quand les 2 camps défendent quelquechose de sensé comme les 2 vm), non il parle de rapport entre le cout de l'ajout d'un nouveau développeur et son rendement a force de se heurter à ca: (et on parle pas de pme/pmi ici)
            Another important effect is to lower overhead and increase efficiency through specialization. Developers don't experience the pressures that routinely compromise conventional closed projects and turn them into tar-pits -- no lists of pointless and distracting check-list features from Marketing, no management mandates to use inappropriate and outdated languages or development environments, no requirement to re-invent wheels in a new and incompatible way in the name of product differentiation or intellectual-property protection, and (most importantly) no deadlines.
    • [^] # Merci d'oser le dire =|<))

      Posté par (page perso) . Évalué à 10.

      100 % d'accord.

      L'important dans un projet est de communiquer et que chacun comprenne les points de vues et
      propositions de conception et d'implémentation des autres membres du projet.

      C'est là toute l'utilité d'un chef de projet qui sache écouter, comprendre, réfléchir et reformuler, puis modéliser en s'assurant de faisabilité du modele, et de la bonne comprehension du modèle par chacun ( quelle que
      soient les regles de modelisation, officielles ou 'faites maison'.

      Ce genre de conception assujettie a des règles strictes ressemble hélas trop souvent a de la poudre aux yeux, généralement jetée par des responsables plus ou moins incompétents qui occupent ainsi leur temps, le projet partant alors sauvagement en c#¶{[^^e.

      "You have enemies? Good. That means you've stood up for something in your life." Winston Churchill

    • [^] # Re: La modélisation c'est bien beau...

      Posté par . Évalué à 10.

      >Mais encore faut t'il savoir l'utiliser. Combien j'ai pu voir de projets ou l'on passait du temps à faire de belles modélisations UML (ou Merise) pour finalement oublier completement le projet derrière et avoir un truc inutilisable à la fin.

      Et la définition de Merise? Tout au moins celle qui circulait à ses heures glorieuses? Je pense qu'il est temps de la rappeler :
      Merise N.f. Méthode éprouvée pour Retarder Indéfiniment la Sortie des études.
      Dans un autre commentaire, Aza cite Windev et je me rappelle très bien être obligé de dénoncer "la dictature de l'incompétence" pour empêcher son utilisation dans un département soi-disant de recherche-développement où on rencontre plus de docteurs es science (et de docteurs ingénieurs) que de personne qui savent la différence entre Java et JavaScript ou qui comprennent deux lignes de C++ (avec std::distance par exemple).

      --
      La démonstration hydrodynamique http://littlejohn.75.free.fr/(...)
      • [^] # Re: La modélisation c'est bien beau...

        Posté par (page perso) . Évalué à 5.

        En tout cas en regardant certains projets LL je ne trouve pas toujours que notre code soit propre, et que la conception soit évidente.

        Néanmoins, nous avons un avantage stratégique : les méthodes sont faites pour que les gens se comprennent, mais quand on vous sort de la double substitution de Listeropovitch par anti Death Pattern of Dark Vadorus, on s'y paume un peu.

        Or il me semble que la force de notre communauté est dans le fait de discuter : OK il y a des flamewars qui pompent l'énergie nécessaire à illuminer Paris pendant une nuit, mais effectivement les contributeurs essaient de se faire comprendre pour essayer de rallier le maximum de personnes à leur point de vue.

        Les méthodes pour que tout le monde se comprennent c'est bien, mais quand cela devient hermétique, cela ne sert plus à rien.

        Pas de méthode de conception c'est mal, mais quand les gens efforcent de faire comprendre leur point de vue sur la conception c'est plutôt le principal, même si ils n'utilisent pas les designs patterns en double rétro induction réccurente qui pourtant sont de la grosse balle.
  • # Quelques remarques

    Posté par . Évalué à 2.

    Dans la version HTML au moins, il y a plein de graphiques qui ne passent pas bien, en particulier les modèles UML.

    le Java est de très loin le langage le plus prometteur dans ce milieu (le C# n'étant que dérivé de Java).

    Personnellement je suis d'accord, mais les types de Microsoft prendraient ça pour un troll :) (mais on s'en fout).
    • [^] # Re: Quelques remarques

      Posté par (page perso) . Évalué à 10.

      Les graphiques passent mal, mais cela vient du latex2html. convert met de gros pater lors de la conversion en png.

      La version postscript devrait être la plus belle (mais la plus grosse).

      Personnellement je suis d'accord, mais les types de Microsoft prendraient ça pour un troll :) (mais on s'en fout).

      Lors d'une conférence d'un évangéliste .Net de Microsoft, j'ai discuté avec lui de ce sujet. Il était tout à fait d'accord avec ce propos. Ils ont copiés Java, et alors ? Autant copié là où c'est bien (no troll, svp). Java a bien repompé sur Smalltalk et C++.
      C'est juste qu'il ne faut pas que Microsoft dise qu'ils ont fait un langage révolutionnaire : ils ont juste pris Java, et ils l'ont modifié.
      Le nier serait stupide car trop visible.
      • [^] # Re: Quelques remarques

        Posté par . Évalué à 3.

        A propos de java :
        pourquoi cette bande de #@! ont pas mis les invariants dedans !

        Tout ça pour foutre un timide assert dans la dernière version.

        Va falloir haxoriser un truc dans les commentaires pour avoir un langage moderne ?

        -1 ça va mieux en insultant quelqu'un.
        • [^] # Invariant

          Posté par (page perso) . Évalué à 5.

          Personnellement, j'utilise JUnit (et un peu JTest) pour mon projet. Et on utilise les pré/post conditions, les invariants, ...
          Elles se mettent dans le javadoc :
          @pre
          @post
          @inv

          Pour le assert, il est plus puissant qu'il n'en a l'air. Ce n'est pas juste un remplacant à un if() throw ...
          Y'a un bon résumé sur www.javaworld.com sur ce sujet.

          L'intéret d'utiliser ca ? Et bien ma partie est une partie crucialle : environ une 50e de développeur vont utiliser ma couche, et mon projet sera repris par quelqu'un d'autre. Donc, mon code ne doit pas avoir de bug (on peut rêver :) ), et on doit éviter au max les régressions (une correction de bug qui entraine 20 autres bugs).


          Par contre, c'est vrai que c'est balise de pre/post/inv ne font pas partie de la norme Java. On peut dire que le assert est un premier pas, et que le nombre de personnes intéressé par du code à ce point robuste est assez limité.
  • # UML n'est pas une methode

    Posté par . Évalué à 10.

    UML est un langage standard de modélisation graphique. Il permet d'appréhender visuellement la complexité d'un logiciel en terme de composants, d'architecture et de liens entre les éléments de conception. C'est un simple outil de conception, un langage que "tous le monde" comprend (devellopeur, chef de projet, client) et qui permet de se mettre d'accord. UML ne spécifie pas comment faire la conception en tant que telle.

    Beaucoup de personnes pensent qu'utiliser UML, c'est comme utiliser un traitement de texte. C'est pas parce qu'on sait taper sur un clavier qu'on devient écrivain en utilisant un traitement de texte. Il est clair qu'il faut, avant toute chose, avoir des compétences, de l'expérience et avoir passé beaucoup de temps sur des lignes de code pour utilisé UML dans ses projets.

    Il faut d'abord, AMHA, maîtriser la conception logiciel sur un simple bout de papier avant de la formaliser avec UML.
    • [^] # Re: UML n'est pas une methode

      Posté par (page perso) . Évalué à 10.

      Très juste. Faire une bonne conception ne s'apprend pas dans les bouquins ;-)

      Sinon concernant le PDF, y'a tellement de fautes d'orthographe qu'on se demande si c'est du français... Je crois que c'est la mode chez les djeunz de faire des docs cousus de fautes.
      • [^] # Re: UML n'est pas une methode

        Posté par (page perso) . Évalué à -10.

        D'ailleurs en parlant de mode : "... docs cousues de ..."

        "docs" : c'est le diminutif de "documentations" féminin pluriel :P
        • [^] # Re: UML n'est pas une methode

          Posté par (page perso) . Évalué à -3.

          Autre version :
          "docs" : c'est le diminutif de "documents" masculin pluriel. :-)
          Et l'on a bien "... docs cousus de ..."
          • [^] # Re: UML n'est pas une methode

            Posté par (page perso) . Évalué à -4.

            Dans les deux cas, il me semble qu'il ne faut pas de "s" à "doc".

            [-1 because là, on commence à enc..er les mouches]
            • [^] # Re: UML n'est pas une methode

              Posté par . Évalué à -3.

              yep, doc n'etant que l'abreviation de documents ou documentations, il ne prend pas de pluriel.

              Depending on the time of day, the French go either way.

              • [^] # Re: UML n'est pas une methode

                Posté par . Évalué à -4.

                Alors il faudrait pas non plus mettre de s aux abréviations suivantes ?

                ciné(ma){tographe)
                stylo{graphe}
                télé{viseur}
                compilo{gcc}
                admin{istrateur systeme} ...et pourtant...

                je vois pas le problème à mettre un pluriel à une abréviation qui prend peu à peu le statut de mot à part entière...

                [je ne devrais peut-être pas nourrir l'éternel débat sur les règles pointilleuses de la langue française... hop -1]
                • [^] # Re: UML n'est pas une methode

                  Posté par . Évalué à -2.

                  Et moi je vois pas de pblm a utiliser le mot Hacker pour designer un pirate, puisque c'est utilise par presque tt le monde ...

                  Depending on the time of day, the French go either way.

            • [^] # Re: UML n'est pas une methode

              Posté par (page perso) . Évalué à -1.

              Mais non, vous avez rien compris.

              doc est l abbreviation de docteurs.

              la preuve, on parle de recoudre. c est bien le boulot d un docteur ( je sais de quoi je parle, j ai vu urgence).

              Tiens, voici la preuve que specifier en francais provoque des ambiguites, et que UML peut permettre d en lever une bonne partie ( ou comment retomber sur ses pattes en une lecon)
      • [^] # Re: UML n'est pas une methode

        Posté par . Évalué à 0.

        Très juste. Faire une bonne conception ne s'apprend pas dans les bouquins

        On naît avec ?
        C'est un appel à la haxorisation ?

        Je vois pas comment tu veux d'informer et te former sans lire.
        C'est pas avec les profs qu'on trouve dans les centres de formation que l'informatique sortira la tête du cul.
        Quand à répéter pendant 10 ans les mêmes conneries de conception sous prétexte que le terrain y'a que ça de vrai ... J'ai un doute.

        Pour résumer : pas d'accord.
        • [^] # Re: UML n'est pas une methode

          Posté par . Évalué à 10.

          Je vois pas comment tu veux d'informer et te former sans lire.

          Il n'a pas dit qu'il n'était pas nécessaire de lire, mais que ce n'était pas suffisant, nuance !

          C'est pas avec les profs qu'on trouve dans les centres de formation que l'informatique sortira la tête du cul.

          Sachant qu'en général ce sont ces mêmes profs qui ont écrit les bouquins, effectivement, on ne va pas avancer. Donc tu propose quoi ?

          Quand à répéter pendant 10 ans les mêmes conneries de conception sous prétexte que le terrain y'a que ça de vrai ... J'ai un doute.

          Le fait est que c'est en forgeant qu'on devient forgeron. Pas seulement en informatique, mais dans tous les domaines. Quand tu étais à l'école, on te donnait des cours de maths, puis des exercices à faire. On te faisait pratiquer. Et bien c'est pareil partout. Les livres, la théorie, c'est bien, mais si on se contente d'apprendre par coeur des théorie on devient comme les profs que tu mentionnes. Des gens qui savent tout sur tout, mais qui sont incapables de faire quoi que ce soit.
          • [^] # Re: UML n'est pas une methode

            Posté par . Évalué à 9.

            Le fait est que c'est en forgeant qu'on devient forgeron.
            Faux, en forgeant on devient chomeur, paske bon des taf de forgerons, y'en a pas des masses.

            Depending on the time of day, the French go either way.

            • [^] # Re: UML n'est pas une methode

              Posté par (page perso) . Évalué à -3.

              heu....

              je suis d'accord
              • [^] # Re: UML n'est pas une methode

                Posté par . Évalué à -5.

                Moi aussi, mais peut etre que ca compte pas...

                Depending on the time of day, the French go either way.

                • [^] # Re: UML n'est pas une methode

                  Posté par (page perso) . Évalué à -3.

                  sisi
                  faut le dire
                  • [^] # Re: UML n'est pas une methode

                    Posté par . Évalué à -3.

                    tu crois ?

                    Depending on the time of day, the French go either way.

                    • [^] # Re: UML n'est pas une methode

                      Posté par (page perso) . Évalué à -5.

                      il me semble que nous sommes ici pour nous exprimer... aussi audacieuse que soient vos idées, n'hesitez jamais à les exprimer...

                      toutefois je vous invite à respecter l'usage du vouvoiement (quelque soit la maniere dont ce mot s'ecrive) qui convient au respect des lecteurs qui prennent sur leur temps pour essayer de comprendre vos audacieuses reflexions

                      non parce qu'on à pas administré les neuneux ensemble hein...
                      • [^] # Re: UML n'est pas une methode

                        Posté par . Évalué à -1.

                        il me semble que nous sommes ici pour nous exprimer... aussi audacieuse que soient vos idées, n'hesitez jamais à les exprimer...
                        Effectivement vous avez raison, mais toutes les idees sont elles bonnes ennoncer ? Si le publique n'es pas pret, n'est ca pas d'une certaine maniere l'agresser, en le confrontant a des conceptes qui lui echappent, n'est ce pas un peu perdre son temps?

                        toutefois je vous invite à respecter l'usage du vouvoiement (quelque soit la maniere dont ce mot s'ecrive) qui convient au respect des lecteurs qui prennent sur leur temps pour essayer de comprendre vos audacieuses reflexions
                        Vous avez de nouveau raison, la justesse de vos propos me laisse reveur, et me fait entrevoir certains sommets de la reflexion humaine, et je me prends a rever d'y acceder moi meme, mais pas avant longtemps, helas, n'etant pas aussi belle esprit que vous.

                        non parce qu'on à pas administré les neuneux ensemble hein...
                        Oui mais nous frequentons LinuxFR, ce qui reviens au meme.

                        Depending on the time of day, the French go either way.

                        • [^] # Re: UML n'est pas une methode

                          Posté par (page perso) . Évalué à 3.

                          Si le publique n'es pas pret, n'est ca pas d'une
                          certaine maniere l'agresser, en le confrontant a des
                          conceptes qui lui echappent, n'est ce pas un peu
                          perdre son temps?

                          C'est le destin des grands penseurs d'etre imcompris
                          ou raillé de leur vivant, la certitude d'etre élevé au
                          rang de genie apres notre mort nous aide à supporter
                          cela

                          me laisse reveur, et me fait entrevoir certains
                          sommets de la reflexion humaine

                          Ne vous inquietez, c'est l'effet que font
                          générallement mes contributions sur ce site.

                          Oui mais nous frequentons LinuxFR, ce qui reviens
                          au meme.

                          Certe, mais comme vous le disiez plus haut, "toutes
                          les idees sont elles bonnes ennoncer ?"
                          celle là risque de vous couter quelques precieux XP
                          (mais ??? avec ou sans S)
        • [^] # Re: UML n'est pas une methode

          Posté par . Évalué à 6.

          C'est pas avec les profs qu'on trouve dans les centres de formation que l'informatique sortira la tête du cul.
          On t'as mis une mauvaise note récemment ?
          • [^] # Re: UML n'est pas une methode

            Posté par . Évalué à -2.

            17.5 en objet, tu prends ça comme tu veux.

            Mais faire un cours d'objet sans parler de sémantique, patterns, modélisation, analyse c'est nul.
            • [^] # Re: UML n'est pas une methode

              Posté par . Évalué à -1.

              Dans la mesure où tu dénigres les enseignants et le contenu de leurs enseignements, il me semble malvenu de te vanter d'avoir eu une bonne note, celle-ci ne pouvant refléter quelque niveau que ce soit (bon ou mauvais).
              • [^] # Re: UML n'est pas une methode

                Posté par . Évalué à -3.

                je suis toujours à la recherche d'une trace de vantardise dans mon post, peux-tu m'éclairer ?

                Il se demandait si j'était aigris par une mauvaise note, la réponse est non.

                Pour pousser mon propos, voici un mail envoyé au responsable de l'année passée :
                http://nraynaud.com.free.fr/lemarch.txt(...)
                J'en suis pas complètement satisfait (je parle du mail, le reste va de soi) mais j'en ai déjà fait (et discuté) la critique (essentiellement sur le manque de pédagogie de mon propos) sur la tribune, je le referais pas ici. Donc pas la peine de le critiquer.

                -1 réponse à un post qui n'en mérite pas.
            • [^] # Re: UML n'est pas une methode

              Posté par . Évalué à -1.

              te plains pas. j'ai eu des cours de C++ sans un mot sur les templates.
    • [^] # Re: UML n'est pas une methode

      Posté par (page perso) . Évalué à 9.

      Exacte. UML est juste une syntaxe (visuelle).

      Mais autour d'UML, il y généralement le même genre de processus de mise au point (use case, sénario, diag de classes, diag déploiement, ...). Bien sur, cela change suivan le projet, la boite, ou le concepteur, mais on retrouve les mêmes grandes lignes. Certes UML ne spécifie pas comment l'utiliser (et heureusement, car ce n'est pas son rôle), mais si j'ai parler d'UML en tant que méthode, c'est que j'ai un amalgame entre sa syntaxe et son utilisation.

      En gros, c'est comme dire que C++ est un langage objet. Bcp de personnes font en fait du C+ (du C à syntaxe C++) mais on ne prend en comppte que la "bonne" utilisation du langage.

      En tout cas, je suis à 100% d'accord avec toi.

      PS : pour les fautes d'orthographe dans mon rapport, j'ai essayé de faire gaffe mais à priori, j'en ai oublié pas mal :( N'hésitez pas à me les signaler par mail, ce document n'est pas figé et il peut (doit) évoluer (des erreurs plus graves peuvent également s'être glissés car la norme MDA évolue encore). An tous ka, jeux pherè plue gaphe la proche haine foie.
    • [^] # Re: UML n'est pas une methode

      Posté par (page perso) . Évalué à 0.

      Exact, UML est un outil.

      Utiliser un ordinateur ne fait pas de moi un informaticien. Et réciproquement utiliser du papier et un crayon pour la conception ne fait pas de moi un non-informaticien.

      Avec de la provocation je dirais que je n'ais pas besoin d'un marteau pour enfoncer un clou. Pas plus que l'on a besoin d'outil de conception pour concevoir un programme. Mais la comparaison n'est pas pertinente, car dans le domaine de la conception il y a plus d'un cheminement qui mènent au même résultat : il y a plusieurs démonstrations possible pour un théorème, mais ce qui est important ce n'est pas d'avoir des outils pour concevoir (les théorèmes) mais d'avoir une manière d'évaluer leur validité.
      Exemple : si un projet logiciel libre :

      1. fonctionne
      2. a une base de contributeurs motivés

      c'est un début de preuve de la validité de la conception en ce qui me concerne :)
    • [^] # Re: UML n'est pas une methode

      Posté par . Évalué à 9.

      Oui, contrairement a Merise UML n'est pas une methode.

      J'ajouterai aussi que UML est une unification de ce qui se faisait avant donc dire "UML c'est de la merde" ou "UML c'est genial" n'a pas grand sens.

      Par contre, on peut faire de l'UML sur un simple bout de papier, ca n'empeche pas :-)
    • [^] # Re: UML n'est pas une methode

      Posté par (page perso) . Évalué à 0.

      Bon, j'ai modifié le site web.
      J'ai fait l'amalgame volontaire entre UML et sa méthode associé, mais maintenant, j'ai préciser la différence (je ne me suis pas étaler car ce site parle de MDA et non d'UML).

      J'ai également corrigé quelques fautes d'orthographe. Il en reste peut etre, mais j'ai au moins enlever les plus voyante (mais quand on se relit tout seul, on passe souvent à côté).

      Pour les images, je vais essayer de voir pour améliorer la lisibilité.
  • # Je dois être très bête

    Posté par . Évalué à 10.

    Mais j'ai beau faire de l'info depuis 10 ans, les méthodes je n'ai jamais trop compris.

    J'ai eu un cours sur Merise a Supélec --> beurk!
    L'idée que j'en ai retenu c'est que cela ferait énormément de paperasserie en plus sans grand intérèt.
    Peut-être que je me trompe, je n'ai jamais utilisé Merise "pour de vrai": c'était passé de mode quand je suis sorti de l'école :-) Ouf!

    Apres il y a eu UML, bon plein de grand terme grandiloquent pour des graphiques bien joli sur des petits exemples, mais qui a mon avis doivent tourner rapidement au plat de nouille sur des projets complexe.. Oui je sais on peut hierarchiser mais bon ce n'est pas forcement plus facile a comprendre pour autant.
    Les use case, ok c'est tres bien m'enfin il n'y a pas besoin d'UML pour savoir que des "scénarios typique d'utilisation" aide beaucoup à comprendre de quoi on parle.

    Bref beaucoup de vent pour des solutions miracles, beurk!
    Sinon n'importe quelle méthode, appliquée intelligeament (c'est là le noeud du problème), pourquoi pas?
  • # Erreurs communes...

    Posté par (page perso) . Évalué à 10.

    Tous les systèmes de modélisation sont fondés sur le fait que l'on dispose de bonnes spécifications.
    Or jusqu'à présent aucune méthode ne permet de valider la pertinence des spécifications.

    Hélas, les spécifications ne sont souvent que les lubies des demandeurs, bien loin des besoins réels des utilisateurs. J'ai pu le vérifier pendant 22 ans.
    Souvent une fonction à usage rare est exigée alors qu'une autre très utile n'a même pas été évoquée car le demandeur n'a pas été capable de l'imaginer.
    Ceci est dû au fait que le demandeur ne connait pas les techniques informatiques et que l'informaticien ne connait pas le métier. Seul, un échange croisé de compétences permettra de créer un bon logiciel et d'imaginer de bonnes solutions.
    Je vous donne deux exemples : au lieu d'installer l'imprimante à listing demandée, j'ai créé une table de plus dans la base de données qui a rendu le listing inutile. L'autre exemple est un serveur Apache au lieu de graver des CD. Dans les deux cas, la solution était loin de la demande exprimée mais correspondait aux besoins réels.

    Pour moi, la modélisation, c'est comme la projection sur un plan d'objets en 3D. C'est commode, mais limité, forcément.
    • [^] # Depuis 30 ans qu'on le dit

      Posté par (page perso) . Évalué à -1.

      Extrait d'une fiche de lecture sur le mois homme mythique (F. Brooks)
      Il commençait par parler de la fascination pour les méthodes qui tuent il avait appelé ça le syndrome de la balle en argent, et ensuite il dit que les méthodes ont finalement moins d'impact sur l'amélioration des logiciels (preuve à l'appui) que les les bons programmeurs, ceux qui ont pas besoin de charabia incompréhensible pour expliquer leur vision:


      There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity."
      Software engineering is made of two parts: dealing with the essence and dealing with the accidents.
      We can define the essential part of the job as the design, the specification, the testing of the conceptual construct. Fred Brooks believe this part is being the hardest, and that every gain on this domain have a great impact on the accidental one. The accidental part consists of mapping the concept to reality through all kind of artificial barriers that are not inherent to the conception. These barriers can be hardware constraints, inadequate programming language, inadequate structure ....

      Werewolves are terrifying creatures that once familiar, become terrifying horrors. Software projects can slip to horror through usually innocent forms such as missed schedule and then blow your budget or become a flawed product. But, as we look at the technique available (in 1975) in both programming and management, we cannot figure a technique that will improve simplicity, reliability, or productivity in an order of magnitude.

      Et sa solution est

      Mythical Men : Peolpeware
      The central theme of this book is software are made by men, and the raw material for success is creativity. Therefore the quality of people their organisation and management structure is much more important than the tools or methods they are using. Brooks enforces its intuition with Boehm's study : the quality of a team is the largest factor for success in software development.
      Then, management's attributions is not to make people work, but to give them the mean to work.

      The Human factor: great designers
      Improving softwares implies de facto improving the development, and this can be done only through people. Good designs can be obtain by following good practices. Good practices can be taught, and spread through literature, and curses ...
      Nevertheless, Fred Brooks do not believe in a strong breakthrough by doing this, he rather thinks that designing is a creative process , and that the only way to have good design is to have great designers. He then point out that great designs usually from few minds considering UNIX, APL, PASCAL, in contrast with COBOL, PL/I and MS-DOS.
      As a consequence organisations should grow great designers. To do so some steps are obvious :
      • identify them early, the best might not be the most experienced

      • mentor their careers

      • grow their competence and responsibility through a career plan

      • provide a stimulating environment that helps designers to interact with each others
    • [^] # Re: Erreurs communes...

      Posté par . Évalué à -6.

      Tous les systèmes de modélisation sont fondés sur le fait que l'on dispose de bonnes spécifications.

      Tiens, c'est marrant, encore du Waterfall, les trucs de dinos ont la vie dure.

      B. Meyer, R.C. Martin dans les années 1990 et Gamma et ses potes, disent le contraire (qu'on a toujours des spécifs douteuses et qu'il faut tenir compte de ça), t'es sûr que tu t'es réactualisé depuis la sortie de smalltalk 80 ?
      <sarcasme>Tu sais que D. Ungar a écrit un bouquin qui a fait décoller la technologies des VM depuis et que smalltalk ça rame plus ? :-)</sarcasme>
      • [^] # Re: Erreurs communes...

        Posté par (page perso) . Évalué à 2.

        OK on reprend :
        hypothèses
        nouveau => bien
        vieux => mauvais
        ou le contraire
        résultat:
        Argument fallacieux, la contraposée aussi est fallacieuse : c'est pas parceque t'es jeune que t'es con.
        Uniquement parce que tu agresses des personnes qui sont sympa et qui ont fait leurs preuves.
        En plus si tu penses que l'on peut faire des programmes en ayant des specs "floues", tu vas finir par faire un programme qui commence par démontrer l'existence de dieu.
        --
        informatique par les blaireaux: s'efforcer d'être obscur pour paraître profond
        • [^] # Re: Erreurs communes...

          Posté par . Évalué à -2.

          Géniale ta signature, je la grave dans ma tête.

          J'ai pas bien compris ton post. Par contre j'ai pas vu d'agressivité dans le mien, si faut foutre des smiley partout pour faire du 2ème degré, on va tous finir sur IRC.

          D'autre part j'ai déjà fait quelques applications (une télécommande d'oscillo sur PC, 2 applications de capture de paramètres électriques, 2 applications dans le dommaine de l'imagerie panoramique dynamique, 1 dans la vidéo surveillance, les autres projets étaient plus carrés) qui avait des specs floues et j'ai satisfait le commanditaire par contre je suis resté en collaboration étroite avec lui, c'est un des principes de XP (que je ne pratique pas qd même).

          La référence à XP est du 2ème degré :-) :-) (faut préciser ici), je ne prédend pas en faire (j'ai même pas encore lu tous les principes de ce truc).


          -1 réponse à un post agressif et pas intégralement compris
      • [^] # Re: Erreurs communes...

        Posté par (page perso) . Évalué à 2.

        Il y a souvent une énorme différence entre les besoins exprimés et les besoins réels.

        Je ne me suis jamais contenté de ce que me disait mon client; j'ai toujours essayé de comprendre ses besoins.
        Ce n'est pas du tout pareil. Or c'est une étape que je n'ai trouvé dans aucune méthode.

        Il n'existe pas non plus de méthode permettant d'affirmer qu'une méthode est applicable à un cas donné.

        C'est pour cette raison que je me suis toujours tenu informé, mais je suis resté à distance de toutes ces modes, euh, méthodes à la mode !

        Le résultat est que j'ai réussi à faire et à faire vivre un gros système d'information à la plus grande satisfaction de tout le monde, sauf de quelques chefs qui ne voulaient pas abandonner leurs lubies !
        • [^] # Re: Erreurs communes...

          Posté par . Évalué à -2.

          Je ne me suis jamais contenté de ce que me disait mon client; j'ai toujours essayé de comprendre ses besoins.
          Ca tombe bien, c'est le devoir de conseil du vendeur envers le client. Ca doit être dans le code du commerce

          Or c'est une étape que je n'ai trouvé dans aucune méthode.
          Il y a aussi peu de méthodes de développement logiciel qui te disent que quand tu as faim il faut mauger, le fait d'avoir bac+5+ ne dispense pas (de plein droit en tout cas) de bon sens.

          C'est pour cette raison que je me suis toujours tenu informé, mais je suis resté à distance de toutes ces modes, euh, méthodes à la mode !
          Si on analyse le fond de certaines méthodes, on constate que ont plus tendance à s'enrichir qu'à réellement varier. Ceci dit j'espère qu'on ne demande à personne de lire des bouquins sans utiliser le sens critique qui est en eux. Il faut aussi faire gaffe à ne pas se prendre 1 train de retard (regarde la dose de projets en C qui gagneraient à passer dans un langage moderne)

          Le résultat est que j'ai réussi à faire et à faire vivre un gros système d'information à la plus grande satisfaction de tout le monde, sauf de quelques chefs qui ne voulaient pas abandonner leurs lubies !

          C'est pas un objectif suffisant en soi, il faut qu'il soit aussi évolutif et qu'il supporte ton absence (documentation et patterns essentiellement).
          • [^] # Re: Erreurs communes...

            Posté par (page perso) . Évalué à 4.

            Je pense que ta remarque est très judicieuse. Pour le sens du commerce, je suis né en 1943 au dessus du magasin de chaussures de ma mère et de ma tante, à côté, ma grand-mère tenait un bureau de tabac et deux maisons plus loin mon père fabriquait et vendait des postes de radio. J'ai donc longtemps vécu dans ce milieu.
            Le seul problème est que l'on doit le plus souvent vendre le service à une personne qui ne va pas l'utiliser. C'est pourquoi je me suis toujours attaché à le vendre aux vrais utilisateurs et à faire comprendre au chef avec d'autres arguments que c'était son intérêt.

            Tout à fait d'accord pour le sens critique et le BSE (Bon Sens Élémentaire). J'ai vu trop souvent des gens penser qu'en appliquant LA méthode à la mode ils étaient certains d'arriver à un bon résultat.

            Le système d'information qui m'a occupé pendant 22 ans est très bien documenté, sa gestion de version a été mise en place en 1992 et nous avons fait tout ce qui était en notre pouvoir pour assurer sa pérennité. Le vrai problème n'est pas informatique. Ce logiciel comporte environ 400 règles relatives au métier. C'est semblable à une théorie mathématique basée sur quelques axiomes à partir desquels on en déduit des centaines de théorèmes. Il faut à peu près un an de pratique pour les maîtriser correctement.
            • [^] # Re: Erreurs communes...

              Posté par . Évalué à -3.

              vendre le service à une personne qui ne va pas l'utiliser

              Un problème inverse est très bien résumé par Meyer (Bertrand, pas l'autre) : "Ne supposez pas que vous connaissez l'utilisateur, vous ne le connaissez pas" l'argument principal est qu'une application qui a du succès sera détournée de son but premier.
              J'ai pas de critères pour foutre une frontière entre les 2 :-(

              Ce logiciel comporte environ 400 règles relatives au métier.
              C'est dans quel domaine ? J'aime assez travailler dans des domaines que je ne connais pas (en dehors de l'info), on découvre des trucs de fous chez les autres :-)

              A titre personnel, je suis assez fier d'avoir fait 5 d'électronique, de mécanique et de productique (durant mes études) ça m'offre un gamme de compétences rares en info. Et facilite la discussion dans certains cas.

              -1 ma life

Suivre le flux des commentaires

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