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.
# La modélisation c'est bien beau...
Posté par Aza . Évalué à 10.
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 Dugland Bob . Évalué à -5.
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 Jul (site web personnel) . Évalué à 10.
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 Jul (site web personnel) . Évalué à 10.
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 Etienne Juliot (site web personnel) . Évalué à 10.
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 Aza . Évalué à 10.
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 Dugland Bob . Évalué à 3.
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 Neo Futur (site web personnel) . Évalué à 4.
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 boris . Évalué à 1.
[^] # Re: H2O+alcooloïde anisé (pastaga, non ?)
Posté par Dugland Bob . Évalué à -7.
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 Erwan . Évalué à 10.
"- 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 Aza . Évalué à 10.
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 phq . Évalué à -5.
Même le truc du type avec sa maitrîse de chimie ?
[^] # Re: probablement
Posté par Aza . Évalué à 6.
- 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 Adrien BEAUCREUX . Évalué à 1.
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 Adrien BEAUCREUX . Évalué à -2.
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 imr . Évalué à 2.
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.
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 imr . Évalué à 5.
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 Neo Futur (site web personnel) . Évalué à 10.
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 François Petitjean . Évalué à 10.
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 Jul (site web personnel) . Évalué à 5.
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 phq . Évalué à 2.
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 Etienne Juliot (site web personnel) . Évalué à 10.
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 Dugland Bob . Évalué à 3.
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 Etienne Juliot (site web personnel) . Évalué à 5.
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 _seb_ . Évalué à 10.
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 VACHOR (site web personnel) . Évalué à 10.
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 Flyounet (site web personnel) . Évalué à -10.
"docs" : c'est le diminutif de "documentations" féminin pluriel :P
[^] # Re: UML n'est pas une methode
Posté par VACHOR (site web personnel) . Évalué à -3.
"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 Pierre Tramo (site web personnel) . Évalué à -4.
[-1 because là, on commence à enc..er les mouches]
[^] # Re: UML n'est pas une methode
Posté par Frank-N-Furter . Évalué à -3.
Depending on the time of day, the French go either way.
[^] # Re: UML n'est pas une methode
Posté par daggett . Évalué à -4.
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 Frank-N-Furter . Évalué à -2.
Depending on the time of day, the French go either way.
[^] # Re: UML n'est pas une methode
Posté par Etienne Juliot (site web personnel) . Évalué à -1.
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 Dugland Bob . Évalué à 0.
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 imalip . Évalué à 10.
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 Frank-N-Furter . Évalué à 9.
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 PloufPlouf (site web personnel) . Évalué à -3.
je suis d'accord
[^] # Re: UML n'est pas une methode
Posté par Frank-N-Furter . Évalué à -5.
Depending on the time of day, the French go either way.
[^] # Re: UML n'est pas une methode
Posté par PloufPlouf (site web personnel) . Évalué à -3.
faut le dire
[^] # Re: UML n'est pas une methode
Posté par Frank-N-Furter . Évalué à -3.
Depending on the time of day, the French go either way.
[^] # Re: UML n'est pas une methode
Posté par PloufPlouf (site web personnel) . Évalué à -5.
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 Frank-N-Furter . Évalué à -1.
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 PloufPlouf (site web personnel) . Évalué à 3.
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.
On t'as mis une mauvaise note récemment ?
[^] # Re: UML n'est pas une methode
Posté par Dugland Bob . Évalué à -2.
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 imalip . Évalué à -1.
[^] # Re: UML n'est pas une methode
Posté par Dugland Bob . Évalué à -3.
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 phq . Évalué à -1.
[^] # Re: UML n'est pas une methode
Posté par Etienne Juliot (site web personnel) . Évalué à 9.
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 Jul (site web personnel) . Évalué à 0.
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 :
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 Erwan . Évalué à 9.
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 Etienne Juliot (site web personnel) . Évalué à 0.
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 reno . Évalué à 10.
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 Pierre Jarillon (site web personnel) . Évalué à 10.
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 Jul (site web personnel) . Évalué à -1.
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 :
[^] # Re: Erreurs communes...
Posté par Dugland Bob . Évalué à -6.
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 Jul (site web personnel) . Évalué à 2.
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 Dugland Bob . Évalué à -2.
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 Pierre Jarillon (site web personnel) . Évalué à 2.
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 Dugland Bob . Évalué à -2.
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 Pierre Jarillon (site web personnel) . Évalué à 4.
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 Dugland Bob . Évalué à -3.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.