"Pour développer un logiciel avec des coûts contrôlés, dans un délai raisonnable, nous avons besoin de méthodes de développement ou plutôt un processus de développement. Nous allons décrire un processus de développement bien particulier qui est commercial, développé par Rational Software (le créateur de UML)."
| Titre | Initiation au Rational Unified Process |
| Auteur | Philippe Kruchten |
| Editeur | Eyrolles |
| ISBN | 2-212-09104-4 |
| Pages | 282 |
| Prix | Prix constaté 246F. |
| Rédacteur | François Revest |
alt="Couverture">
<!-- Ceci est a mettre comme texte de la news annoncant la revue<br/> du livre -->
Pour développer un logiciel avec des coûts contrôlés, dans un délai
raisonnable, nous avons besoin de méthodes de développement ou plutôt
un processus de développement. Nous allons décrire un processus de
développement bien particulier qui est commercial, développé par
Rational Software (le créateur de UML).
<!-- Fin du texte de la news -->
Je ne veux pas critiquer la
méthode de développement mais ce livre qui fait partie (Introduction au
Rational Unified Process) de cette méthode. Cet ouvrage
est décomposé en 7 parties
- Preface
- Partie 1 : Le processus (chapitre 1 à 6): Cette partie décrit les
concepts de processus, le contexte, l'histoire, le cycle de vie d'un
logiciel.
- Partie 2 : Enchaînement d'activités du processus(chapitre 7 à 17): Elle
définit les activités du processus.
- Annexe A : Liste des travailleurs: L'explication des rôles rentrant dans
le projet.
- Annexe B : Liste des artefacts: La listes des artefacts avec les
personnes qui doit les fournit rangé en cinq parties :
Les exigences, la conception, l'implémentation, le déploiement, la
gestion.
- Glossaire :Le glossaire décrit les termes spécifiques au R.U.P. mais
aussi en génie logiciel.
- Bibliographie: Cette bibliographie assez complète est classée en thèmes
(général, processus de développement, technologie orientée objet, modélisation
et UML, gestion de projet, gestion des exigences, gestion de configuration,
test et qualité, architecture logicielle).
- Lexiques Ils sont deux :
anglo-français
franco-anglais.
Le premier chapitre explique pourquoi est-on ammené à utiliser un
processus de développement pour un logiciel et les pratiques les plus viables
pour un développement logiciel.
Le deuxième chapitre est une présentation de
cette méthode.
Le chapitre suivant concerne l'approche statique du processus (les
éléments ne bougeant pas d'un projet à l'autre).
Le quatrième chapitre est une
petite critique du R.U.P. en mettant le doigt sur ses insuffisances et en
introduisant des solutions.
Enfin, les deux derniers paragraphes de la partie 1(chap.
5 et 6) sont la description du pilotage du processus c'est à dire un processus
centré sur l'architecture logicielle et piloté par les cas d'utilisation (use
case).
La seconde partie est la description des activités il y a un chapitre
pour chaque activité et est découpée en six parties
- Description des objectifs des activités
- Définition des mots clés
- Liste des travailleurs et des artefacts
(document ou code à produire à
la fin de l'activité)
- Enchaînement d'activités typiques
- Les outils disponibles
- Un résumé de l'activité
Les onze activités du RUP avec leur explication si nécessaire sont
- La gestion de projet
- Modélisation du métier : Ce sont les attendes des utilisateurs
(comprendre les besoins informatiques). Cette modélisation est décomposée en
deux parties, modèle de cas d'utilisation métier et un modèle objet métier
- Gestion des exigences
- Analyse et conception
- Implémentation
- Test
- Gestion de la configuration et des changements
- Environnement : quel type d'environnement ai-je besoin ?
- Déploiement :comment livrer le produit au client ?
- Enchaînement d'itération : comment s'enchaînent les différentes
activités ?
- Configuration et implémentation du RUP : Comment peut-on mettre en place
le RUP ?
En conclusion, ce livre est destiné avant tout au gestionnaire de
projet, mais aussi au développeur qui aimerait connaître cette méthode.
Ce
livre est une bonne introduction au génie logiciel en complément d'un livre
d'UML.
Cet opus est bien réalisé avec des illustrations compréhensibles qui
remplacent avantageusement de longs textes et un résumé de
chaque chapitre à la
fin de ceci. Je regrette tout de même que les outils décrits (logiciel) soit des
logiciels commerciaux provenant essentiellement du catalogue Rational (ce qui
est compréhensible du fait de l'origine de la méthode provenant de cette
firme) et Microsoft, et donc ne permet pas d'offrir un panorama complet des
logiciels concurrents.
Table des matières
- Préface
- Chapitre 1 : Les meilleures pratiques de développement logiciel
- Chapitre 2 : Présentation générale du Rational Unified process
- Chapitre 3 : Dimension statique du processus
- Chapitre 4 : Dimension dynamique du processus
- Chapitre 5 : Un processus centré sur l?architecture
- Chapitre 6 : Un processus piloté par les cas d?utilisation
- Chapitre 7 : Gestion du projet
- Chapitre 8 : Modélisation du métier
- Chapitre 9 : Gestion des exigences
- Chapitre 10 : Analyse et conception
- Chapitre 11 : Implémentation
- Chapitre 12 : Test
- Chapitre 13 : Gestion de la configuration et des changements
- Chapitre 14 : Environnement
- Chapitre 15 : Déploiement
- Chapitre 16 : Les enchaînements d?itération
- Chapitre 17 : Configuration et implémentation du RUP
- Annexe A : Liste des travailleurs
- Annexe B : Liste des artefacts
- Glossaire
- Lexiques
- Index
# c quoi ?
Posté par SUrOB . Évalué à 3.
[^] # Re: c quoi ?
Posté par LAurent ROUX . Évalué à 10.
IL s'agirait donc d'une méthode propriétaire pour implémenter un language propriétaire dans des milieux par définition fermés... JE me demande ce que ca fout là... CA semble surtout être là pour rassurer les investisseurs...
[^] # Re: c quoi ?
Posté par pasBill pasGates . Évalué à 10.
Maintenant le fait que ca vienne d'une boite commerciale qui fait de l'argent en vendant cela peut ne pas te plaire, ca n'empeche que cela s'applique tout aussi bien aux logiciels libres qu'aux logiciels proprietaires.
Si quelqu'un veut ecrire un projet un tant soit peu gros, libre ou pas, il ferait bien de lire ce bouquin, ca lui epargnera beaucoup d'efforts inutiles et de reecriture de code.
Maintenant, il y a aussi d'autres techniques qui peuvent etre utilisees aussi, mais celle ci fonctionne, et il serait dommage de s'en priver.
[^] # Re: c quoi ?
Posté par Anonyme . Évalué à 4.
Mon conseil: faites tout ce qu'on vous deconseille de faire en matière de programmation (pas de conception, regles de codages au panier...), puis rendez-vous compte du bien-fondé de l'ingénieurie logicielle, et écrivez un bouquin.
--
Johann, en bonne voie pour réaliser le bien-fondé de l'ingénieurie logicielle.
[^] # Re: c quoi ?
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: c quoi ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
[^] # Re: c quoi ?
Posté par Jean-Yves B. . Évalué à 6.
UML est juste un pseudo standard pour les gribouillis
pré-implémentation.
Le RUP est la méthode officielle utilisée par rational
pour développer ...
Rien de bien terrible là dedans ...
C'est juste un mini cours de conception de logiciels
orientés objets.
Ce bouquin est loin d'être une solution universelle.
[^] # Re: UML et logiciels libres ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 8.
Un autre projet, FreeCase http://www.freecase.seul.org/(...) est toujours en attente d'un nouveau leader.
[^] # Re: UML et logiciels libres ?
Posté par Brice Favre (site web personnel) . Évalué à 5.
En bref et pour ceux qui veulent en savoir plus, l'UML est une méthode de conception qui est utilisé pour les programmes à objet (ne pas confondre avec MERISE plutot destiné aux SI et Base de Données).
Celà permet d'avoir de beau graphique pour les investisseurs mais aussi de pouvoir fragmenter le travail pour un équipe, voire même en donné une partie à des générateurs de code.
Par exemple on peut génerer le code qui va mettre à 0 ou à 1 un attribut d'un objet.
C'est un gain de temps apréciable pour des projets ambitieux et avec des équipes distantes (d'où l'intéret pour le LL avec des équipes aux quatre coins de la terre). A ne pas négliger donc.
Pour un petit projet fait tout seul chez soi je crois que ce n'est pas la peine.
[^] # Re: UML et logiciels libres ?
Posté par Anonyme . Évalué à 4.
ensuite UML est utile dans toutes les phases de dev (Analyse, Conception, Implémentation .)
Ne pas confondre methode et modelisation.
cd uml.free.fr
[^] # Re: c quoi ?
Posté par Anonyme . Évalué à 3.
C'est de l'épate commerciale, moi ca me gonfle un max , y a pas un modérateur sur cette news ?
[^] # Re: c quoi ?
Posté par Anonyme . Évalué à -4.
ah c'est malin, j'ai mon coca qui me resort par le nez.
Enfin c'est bon de rire un peu, vous nous la refaites?
Un quoi? un mo..? mo..? modAHHHAHHAHAHHAAAHHAHrgg... *couic*
mdr
[^] # Re: c quoi ?
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Petite précision, Jacobson et Rumbaugh bossent pour Rational. Donc au-dessus de la méthode de modélisation objet, ils ont pondu un process complet de génie logiciel qui s'appuie sur les produits Rational donc le RUP.
[^] # Re: c quoi ?
Posté par kadreg . Évalué à 0.
Philippe Desfray plutot.
[^] # Re: c quoi ?
Posté par harbort . Évalué à 2.
En gros, quand des gens ont voulu faire UML, ils ont réunis les meilleurs mecs pour la modélisation et leur ont dit : "faites-nous un langage et une méthode de développement". Le problème est que les gars n'ont JAMAIS réussi à s'entendre ... et ça a donné UML, un langage trop pauvre pour faire quoi que ce soit !
Dire qu'on connait UML c'est pas trop mal, mais c'est complètement insuffisant. Il faut connaitre des méthodes de développement, qui elles n'ont pas été normaliséses, qui s'appuient sur un UML modifié pour représenté ce qui manque (en général, des relations entre classes définies de manière plus précise).
Pour Rational, c'est une boite très connue qui vent son logiciel et sa méthode mais c'est loin d'être la seule, et les grosses boites de développement ont souvent leurs propres méthodes qui marchent tout aussi bien !
[^] # Re: c quoi ?
Posté par kadreg . Évalué à 1.
Modifié, modifié, il faut le dire vite. UML a été concu pour être étendu par le mécanisme de stéréotypes (Derivation d'une metaclasse) et de tagged values (ajout d'attributs sur la metaclasse) et de contraintes complémentaires.
Par exemple, si je cherche a representer un site web, je vais ajouter un stereotype sur la metaclasse component, puis une tagged value DocumentRoot, donc, j'aurais le debut de modélisation d'un serveur. (Bon, c'est un exemple, cherchez pas directement un interet :) )
# XP c'est mieux
Posté par Anonyme . Évalué à 2.
[^] # Re: XP c'est mieux
Posté par Anonyme . Évalué à 0.
Faut arrêter d'urgence d'appeler tout et n'importe quoi XP sinon ça va devenir dur de troller sérieusement.
"xp ça suce"
"oui, mais ça r0x0r aussi... enfin je crois"
[^] # Re: XP c'est mieux
Posté par Jean-Yves B. . Évalué à 6.
ne voudrais pas faire partie de l'équipe[1] qui va faire
la maintenance derrière.
En plus, rien ne t'empêche de faire un beau design et
le raffiner au fur et à mesure ...
(Note pour plus tard : vendre des bouquins en proposant
LA méthode qui mêle XP et OOD standardisé)
[1] au sens équipe différente de celle qui à conçu le
logiciel au départ.
(ce message est buzzword-compliant)
[^] # Re: XP c'est mieux
Posté par Tutur . Évalué à 1.
Ben une programmation bien faite et qui est lisible des le depart par differentes personnes. C'est toujours mieux qu'un soft mal ecrit.
[^] # Oops
Posté par Jean-Yves B. . Évalué à -2.
Ca m'apprendra à n'être tombé que sur du XP mal utilisé.
-1 pour la peine.
[^] # Re: XP c'est mieux
Posté par Anonyme . Évalué à -1.
http://www.design-up.com(...)
[^] # Re: XP c'est mieux
Posté par Vincent Creusillet . Évalué à 3.
Et je ne comprends pas très bien ton argument.. La dernière fois que je l'ai utilisé, l'UP (dont RUP est un descendant très direct), préconisait une approche itérative.. donc, très exactement, une prise en compte des 'changements qu'il peut y avoir en cours de réalisation'. Et en plus, quand tu changes quelque chose, tu peux raisonnablement facilement voir sur quoi ça va impacter (ce qui évite de casser quelque chose qu'on avait pas vu à chaque changement). Et la maitrise d'ouvrage (destinataire final), est associé au developpement, suivant les UP.. Normalement, ils doivent valider les cas d'utilisation, et certains éléments de l'analyse.
Donc, que l'eXtreme Programming soit une méthodologie intéressant.. pourquoi pas, moi ça m'a toujours paru épouvantablement brouillon, mais bon... Mais les avantages que tu lui prètes comparé à UML/UP ne m'ont pas convaincu..
[^] # Re: XP c'est mieux
Posté par Brice Favre (site web personnel) . Évalué à 1.
Tout a fait.
En XP le client te demande un changement et tu va faire une estimation à la louche des changements, du temps et du prix de celui ci. Tu as toutes les chances de te planter.
Avec une méthodologie tu peux très précisément (mais ça demande du travail) voir tous les points impacter par le changement, connaitre le temps/homme et chiffrer le coût supplémentaire.
Evidemment si tu codes dans ton coin un produit pour ton usage, l'extreme programming à toujours raison d'être.
[^] # Re: XP c'est mieux
Posté par Philippe F (site web personnel) . Évalué à 2.
Reprenons dans le detail:
"En XP" --> X
"tu va faire une estimation à la louche des changements, du temps et du prix de celui ci" --> Y
"avec une methodologie" --> Z
"(mais ça demande du travail)" --> opppose de Y
Ma conclusion:
Que tu utilises XP ou UML, si tu fais tes estimations a la louche, ce sont des estimations a la louche et tu as toutes les chances de te planter. Si tu y consacres du travail et du temps (si tu t'appliques), tu as toutes les chances de moins te planter.
XP ne t'empeche pas d'avoir une approche propre et de faire les choses comme il faut.
A mon avis, une bonne analyse marche quelle que soit la methode.
Avec XP cependant, comme ton programme est blinde de test (mais vraiment blinde: "TEST EVERYTHING THAT COULD POSSIBLY BREAK"), l'approche la plus simple pour voir l'impact d'un changement est de le faire. Pas besoin de l'implementer, casse juste tout ce que ton changement va casser et regarde les tests qui foirent. C'est bon, tu sais exactement ce qui va foirer et tu peux faire ton estime.
Avec ton diagramme UML, tu vas reflechir, reflechir, analyser, fouiller jusqu'a te dire
"ca va casser ca et ca et a mon avis, ca aussi. Faudra verfier ca." . Tu n'as aucune assurance que tu n'a pas oublie un bout de code dans un coin.
"Evidemment si tu codes dans ton coin un produit pour ton usage, l'extreme programming à toujours raison d'être."
Je pense que tu ne connais pas bien XP pour dire une chose pareille. La chose la plus importante en XP est le client. C'est lui qui definit tout.
Je t'invite a aller lire "XP installed", en libre telechargement:
ftp://ftp.xprogramming.com/ftp/xpinstall.pdf(...)
C'est en anglais, mais ce sont des chapitres courts qui se lisent tres agreablement, dans un anglais simple.
Je parie ma chemise que au contraire, le bouquin d'UML modelise des trucs complexe et se lit mieux avec un aspirine a portee de main.
Des gens dans ce post se sont plaints de programmes code en XP non maintenables. Vous etes tombes sur du faux XP, sur des gens qui n'avaient pas applique tous les principes.
Je ne vois pas comment du code peut etre non maintenable quand:
- "Pair programming": il est ecrit par deux personnes au moins devant un ecran. Donc il y en a au moins deux qui le comprennent.
- "Do the simplest thing": il n'est pas plus complique qu'il ne devrait.
- "Test everything that could possibly break": le code est teste profondement. Donc, si tu casses qqch, ca se verra tout de suite. Cela impose aussi d'utiliser des structures plus simple. Tu ne peux pas tester proprement une fonction de 200 lignes. Mais tu peux tester facilement 20 fonctions de 12 lignes.
- "Refactor mercilessly": notamment, toute chose n'est faite qu'a un et un seul endroit. Il suffit de changer cet endroit pour modifier le comportement.
- "Let your code express your intention": le code doit etre clair en lui-meme, pas de bidouilles obscures.
- "Shared ownership": tout le monde partage le code et le travaille, le programmeur n'est pas dans son coin a coder sa bidouille.
[^] # Re: XP c'est mieux
Posté par Blackknight (site web personnel, Mastodon) . Évalué à -2.
# Attention
Posté par Anonyme . Évalué à 4.
Rationnal joue tjrs sur cette ambiguité dans tous les dommaines.
Ils laissent volontier confondre norme "officiel" avec "leur" norme et leur outils (bien que RUP et UP est été crée par les meme personne):
Il laissent penser aux gens que UML = Rationnal Rose
et que UP = RUP
[^] # Re: Attention
Posté par Jean-Yves B. . Évalué à 5.
\begin{digression}
Un jour je serais assez motivé pour me lancer dans la tâche titanesque que représente le développement de ce type de produit, parce que dia pour faire les diagrammes de classe et surtout de séquence, ca va 5 minutes ...
\end{digression}
Même si Rational pousse SA méthode, un bon ingénieur/architecte gros systèmes va lire le bouquin et fondre son contenu dans sa méthode personnelle qui ne pourra en être que meilleure (quoique).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # [OT] Diagrammes UML en LaTeX
Posté par Jean-Yves B. . Évalué à 6.
hop => http://www.ensta.fr/~diam/latex/pst-uml/(...)
Mouais, apres un rapide coup d'oeil ça fait des jolis
trucs mais le placement à l'air au moins aussi pénible que de cliquer comme un fou dans dia.
Donc, je reste sur dia[1] pour les diagrammes de classe et de séquence, et je garde mon graphviz[2] pour les statecharts et les diagrammes de collaboration.
En plus ce package LaTeX n'est pas vendu comme stable par son auteur ...
[1] http://www.lysator.liu.se/~alla/dia/(...)
[2] http://www.research.att.com/sw/tools/graphviz/(...)
attention -> licence à la con.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Attention
Posté par Dodji Seketeli . Évalué à -1.
Dia comme case tool ça va 5 minutes ...
Le jour ou tu veux commencer un rose libre
(pourquoi pas tulip comme nom ?) fait moi signe ...
C'est vrai que ça manque vraiment un soft comme ça
dans le libre ...
<troll>
Et ne venez pas me parler des softs de ce type
en Java ou il faut 512 Mega octets de ram pour ne
pas swapper.
</troll>
[^] # La ram mouai
Posté par Laurent Mouillart . Évalué à -2.
En plus les 2Go sont profitables a toutes les autres applications.
[^] # Re: La ram mouai
Posté par Dodji Seketeli . Évalué à 5.
je prefere utiliser pour mon portable a 128 Mo de ram, des softs avec le moins de java possible. Et ce n'est pas faute d'avoir essayé.
Je n'ai rien contre ce langage, je l'utilise au jour le jour dans mon taf ...
OK, il est plus simple a utiliser que le C++.
Mais, personnellement, pour des applis qui doivent
s'integrer dans des desktops managers aujourd'hui, tu es d'accord que java/swing c'est pas top...
Je prefere de loin le look et la charge memoire des applis ecrites en C++/MFC
(meme si c'est du fenetres), en C++/KDE ou C/gnome.
Mes chefs preferent aussi le Java. Mais, je persiste à croire *qu'aujourd'hui*, pour mes besoins, java est trop gourmand. Je continuerai donc a en faire au taf, mais pour mon utilisation
personnelle, je me tiens a l'ecart ... jusqu'a ce
que j'ai assez de thunes pour changer de becane ...
Ok, j'avoue que ce n'est pas tres objectif tout ça
mais bon, c'est ce que je pense.
[^] # Re: Attention
Posté par Anonyme . Évalué à 4.
Diagramme de classes, collaboration, déploiement, séquences ,uses case
ocl
Ce soft permet de generer en java et d'autres support de langage seront a venir
[^] # La vache le monstre !
Posté par Jean-Yves B. . Évalué à 3.
Je viens de le downloader, je lance ...
Ouais ca peut etre bien mais c'est leeeeeeennnnnt.
Et en plus, mon petit canard bublemon a grimpé de > 60 Megs d'un coup, dur.
Franchement c'est dommage d'avoir fait ça en Java ... mais c'est bien de le faire.
(Oui, je sais c'est la faute a ma JVM qui est pourrie, Java c'est bien gnagna ...)
Bref!, mitigé quand même, surtout quand on veut seulement faire des graphes et pas de génération automatique de code (ma religion me l'interdit, je n'ai que des templates mitonnés main).
Je garde le site dans mes bookmarks quand même.
[-1 pour le tir à vue]
[^] # Re: Attention
Posté par nicolasr . Évalué à 2.
http://uml.sourceforge.net(...)
voili voilo.
Ceci étant dit, j'ai juste vu, jamais utilisé ;)
C'est du K, je suis donc désolé pour les Gnomeurs du coin, dont moi...
[^] # ca a l'air pas mal
Posté par Dodji Seketeli . Évalué à -1.
sous gnome ...
Penses tu que le gtkmm soit assez stable pour commencer un projet de ce type ?
Car franchement, faire un truc comme cela en C,
c'est trop chiant ...
[^] # Re: Attention
Posté par Anonyme . Évalué à 0.
Pourquoi désolé pour les Gnomeurs?
Ca t'empeche d'utiliser des applications K, Gnome?
Bon ça s'intègre un peu moins bien au desktop, mais ce n'est pas la mort..
Personellement, j'utilise KDE et parfois des applications Gnome: PAN (plus complet que KNode), Abiword (encore que je préfère le concept de frame de KWord)..
reno
[^] # Re: Attention
Posté par kadreg . Évalué à 0.
Tu peux expliciter un peu s'il te plait ?
[^] # Re: Attention
Posté par Jean-Yves B. . Évalué à -1.
# hum rational mefiance
Posté par Anonyme . Évalué à 0.
Perso je m'interesse plus au modéle de maturité, il me semble plus fiable pour obtenir des gains sur le développement. Sans oublier que le développement des ll (une revolution soit dit en passant) ne semble pas être pris en compte.
- Gas (faut qu'j'm'inscrive)
[^] # Tu peux développer ?
Posté par Jean-Yves B. . Évalué à -1.
[^] # Re: Tu peux développer ?
Posté par Anonyme . Évalué à 4.
Le processus de développement à 5 niveaux:
1 initial
2 réitérable
3 defini
4 maitrise
5 optimise.
Le processus débute au niveau 1. Beaucoup plus tard quand le niveau 5 est atteint ben on a multiplie par 4 son efficacité. Le pire s'est que cela marche aussi sur d'autres types de process.
http://saku.crim.ca(...) est une adresse francophone sympa. rechercher cmm.
Sinon il y a aussi le SEI : http://www.cei.cmu.edu(...)
GAS
[^] # Re: Tu peux développer ?
Posté par Jean-Yves B. . Évalué à -1.
Interessants comme sites (c'est sei et pas cei dans l'URL)
Leur methode OCTAVE (rien a voir avec l'OO) a l'air interessante aussi ...
[^] # Re: Tu peux développer ?
Posté par Anonyme . Évalué à 2.
Argh .. désolé correctif http://www.sei.cmu.edu/(...)
Octave je ne connaissais pas je devrais venir plus souvent sur ce site. :).
Gas
# De Merise à UML en entreprise
Posté par sToR_K . Évalué à 0.
Je pense qu'en ce qui concerne son efficacité quand aux schematisation des bases de données ou la methode UML et opposée à la methode Merise, la discussion n'a pas lieu d'etre compte tenu qu'UML englobe les principes de l'analyse Merisienne...
[^] # Re: De Merise à UML en entreprise
Posté par G. R. (site web personnel) . Évalué à 5.
Premièrement, UML est un langage de conception et non une méthode.
UP (et RUP) est une méthode qui s'appuie sur le langage UML, mais tu peux très bien modéliser en UML avec une autre méthode (celle de ton prof par exemple) ou sans méthode (ce qui est assez stupide).
Comme tout langage, UML nécessite un minimum d'apprentissage, mais c'est indispensable quand tu travailles sur des projets un tant sois peu important et pour travailler en équipe.
En ce qui concerne Merise, c'est le contraire. Merise est une méthode qui utilise plusieurs langages, comme les modèles entités-associations.
Enfin, UML et Merise ne sont pas incompatibles. Tu peux très bien faire une conception Merise, et utiliser UML pour la représentation de tes modèles et pour l'approche organisationnelle.
# hum
Posté par Anonyme . Évalué à -2.
essayer pas de faire croire qu'on peut savoir à quoi va ressembler du code avant de l'avoir fait.
C'est plus un secret et c'est comme ça que ça marche tu code ce que t'as prevu et tout au long tu modifie parceque c'est pas comme ça qu'il fallait faire (qui peut me dire qu'il est capable de savoir a l'avance comment sont code fonctionneras avant de l'avoir fait?)
la solution: te retaper tout ton bordel d'uml a la con a chaque fis que t'as une modif a faire
Tout ça c'est du vent de chercheur d'universite+ une maniere de forcer les coders à plus avoir aucun talent parce que justement c'est la qu'il est le talent d'un bon codeur: (faire que ça marche meme si c'est pas tres evident)
[^] # Re: hum
Posté par Obsidian . Évalué à -3.
La programmation est un art avant d'être une technique.
Un programme, çà s'écrit, c'est une oeuvre de l'esprit (donc protégée par copyright ou droit d'auteur), et çà a un style. Même compilé, j'ai réussi à reconnaitre la pate de deux ou trois auteurs différents dans un grand logiciel que j'avais désassemblé et commenté.
l'UML semble n'être qu'une recette pour ceux que la programmation dépasse malgré eux.
Amitiés.
[^] # Re: hum
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Ceci dit, je n'empêche personne de ne pas utiliser de conception mais bon. Au passage, la conception ne veut pas dire qu'une fois qu'on a écrit les noms des méthodes dans les classes que tout est figé. En effet, les cycles de vie de logiciel, c'est pas pour les chiens. On peut très bien faire évoluer un modèle sachant que si la modification touche carrément des classes (suppression de certaines classes entre autres) alors c'est qu'il y avait un problème de conception dès le départ.
Enfin, la conception aussi est un art. Certains feront des conceptions bateaux, d'autres des trucs un peu plus réfléchis et élaborés. Il suffit de regarder le design pattern des états pour comprendre que faut aussi avoir l'idée et que c'est quelque part un peu du génie.
La programmation sans conception, c'est de la bidouille au jour le jour et ça ne peut pas donner un produit stable et maintenable. Y ajouter de la conception et un minimum de réflexion renforce le logiciel et ses capacités à évoluer.
[^] # Re: hum
Posté par Anonyme . Évalué à 1.
> coins et des #define à gogo, moi aussi, je
> reconnais le codeur : c'est un dégeulasse qui
> dans un ou deux ans ne saura pas capable de
> faire une seule modif de son code par que
> celui-ci tient plus de l'acrobatie que de la
> logique.
port50-2:~$ cat /usr/include/*.h |grep -c typedef
998
port50-2:~$ cat /usr/include/*.h |grep -c define
10592
Tu dis que c'est dégueu, mais comment ferais tu sans eux ? Tu peux aussi utiliser un autre langage...
Jé-encoreperdumonpassword-rôme
[^] # Re: hum
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Si tu me réponds que je sais pas lire du code, je te dirai que j'ai pas énormément de temps à perdre pour comprendre un truc que je veux réutiliser. En clair, si je trouve plus clair sans relire tout le code (donc avec une interface bien définie), je prends de suite.
[^] # Re: hum
Posté par Anonyme . Évalué à 1.
Par contre, quand je vois un bon gros programme en C voire C++ avec des typedef dans tous
les coins et des #define à gogo, moi aussi, je reconnais le codeur : c'est un dégeulasse [...]
Les typedef et define ont leur utilité quand il s'agit de faire du code portable avec autoconf et automake.
En C un define est utile pour des constantes: c'est plus efficace que d'utiliser des variables.
[^] # Re: hum
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: hum
Posté par pasBill pasGates . Évalué à 7.
Ce "bordel uml a la con" comme tu l'appelles est ce qui te permet de savoir a l'avance a quoi va ressembler ton code, quels sont les differents modules, comment ils interagissent,etc...
Maintenant si tu bacles cette etape, ben faut pas t'etonner si tu dois tout refaire, mais ca c'est pas du a UML.
Finalement, UML c'est typiquement le truc que les chercheurs d'universite n'utilisent pas ou tres peu, mais que les societes utilisent car elles se sont rendues compte que ca permettait d'aider a tenir les delais et reduire les couts.
Quand au fait que le talent d'un bon codeur est que "ca marche meme si c'est pas tres evident", ben pour moi cette description c'est typiquement celle d'un MAUVAIS programmeur.
Si personne n'est capable de comprendre ton code et que meme toi tu n'es pas sur du pourquoi de son fonctionnement, vaut mieux jeter le code et tout refaire de maniere correcte.
Un bon programmeur c'est quelqu'un qui :
- ecrit des specs avant d'ecrire du code
- ecrit du code clair
- ecrit du code reutilisable
- utilise les bon algorithmes au bon endroit plutot que faire des optims douteuses et floues
- documente son code
- ecrit des routines de tests pour les differents modules de son soft... et les utilise :+)
- est humble et n'accuse pas le compilateur, le linker, l'OS ou la meteo quand son soft plante mais essaye de trouver la raison dans son code
[^] # Re: hum
Posté par Anonyme . Évalué à -3.
> - est humble et n'accuse pas le compilateur,
> le linker, l'OS ou la meteo quand son soft
> plante mais essaye de trouver la raison
> dans son code
J'ai même entendu parler de sociétés qui blamaient les utilisateurs...
Tu cherches vraiment le bâton pour te faire battre !
</FLAME>
Jé-encoreperdumonpassword-rôme.
[^] # Re: hum
Posté par Anonyme . Évalué à -4.
[^] # Re: hum
Posté par Philippe F (site web personnel) . Évalué à 1.
Un bon programmeur c'est quelqu'un qui :
- ecrit des specs avant d'ecrire du code
- ecrit du code clair
- ecrit du code reutilisable
- utilise les bon algorithmes au bon endroit plutot que faire des optims douteuses et floues
- documente son code
- ecrit des routines de tests pour les differents modules de son soft... et les utilise :+)
Un bon programmeur c'est quelqu'un qui :
- ecrit des specs avant d'ecrire du code
- ecrit du code clair
- ecrit du code reutilisable
- utilise les bon algorithmes au bon endroit plutot que faire des optims douteuses et floues
- documente son code
- ecrit des routines de tests pour les differents modules de son soft... et les utilise :+)
"
A part peut-etre pour le premier point qui est plus flou en Extrem Programming, ce sont la toutes les choses recommandees en XP. Et je suis d'accord pour dire que ce sont de bonnes pratiques. Ce que je ne vois pas en revanche, c'est ou UML intervient pour favoriser ca.
Je ne connais pas UML mais ce me donne tres fort l'impression d'etre un truc de masturbation intellectuelle pour avoir la meilleure conception possible avant meme de developper le produit, et d'etre contraint pas la suite.
Comment tu fais quand ton client decouvre au bout de 6 mois qu'il voudrait un truc different mais un peu pareil ?
Ce qui dicte la ou le projet doit aller, c'est le client, pas les specs ecrites par le client. Negliger cette realite me parait etre equivalent a foncer dans le mur. C'est pour ca que tous les processus hyper formels de specification me repugnent. Non pas qu'il ne faut pas concevoir, mais il faut plutot le faire pour avoir une idee generale. XP est bien adapte a ca.
"
- est humble et n'accuse pas le compilateur, le linker, l'OS ou la meteo quand son soft plante mais essaye de trouver la raison dans son code
"
C'est vrai, mais les bugs les plus mechants, ceux qui t'ont fait souffrir, ce sont justement ceux-la. D'ou une haine spontanee envers microsoft, parce que quoi que t'en dises, il y en a plus chez eux [1]
--
[1]: sous windows, tu fais une DLL. Dans ta DLL tu fais "int * a = new int(3)". Puis dans ton prog, tu passe le pointeur 'a' qq part et tu fais "delete a". Malheureux!!! Segfault!!! Et oui, sous windows, ca s'appelle "bibliotheque dynamique" pas "bibliotheque partagee". Deux semaines pour decouvrir que le modele memoire de windows etait ... different.
[^] # Re: hum
Posté par kadreg . Évalué à 0.
UML est une grosse boite a outils qui te permet de t'aider a realiser ces condition par l'utilisation d'outils de modelisations divers et variés.
[^] # Re: hum
Posté par Philippe F (site web personnel) . Évalué à 0.
Blabla pipo blabla!
Peux-tu, au lieu de me reciter une phrase toute faite me dire en quoi UML t'encourage:
- a ecrit du code clair ?
- a ecrire du code reutilisable ?
- a ecrire des routines de tests pour les differents modules de son soft ?
- et a les utiliser ?
XP t'incite a faire tout ca.
[^] # Re: hum
Posté par kadreg . Évalué à 1.
Oh, la belle entrée en matière, j'ai failli pas répondre a cause de cette phrase. Tu as de la chance, je suis de bonne humeur.
XP t'incite a faire tout ca.
Je répond et tu me dit comment XP va le faire pour faire tout ça OK ?
- a ecrit du code clair ?
C'est quoi du code clair ? Deja, un générateur de code basé sur UML va te garantir une uniformité des signatures, des formats de fichiers. De plus, je vais te rajouter un générateur de documentation par dessus ta modélisation, et attention, si tu ne commente pas chacune de tes méthodes, j'ai un mail qui par chez le chef de projet. Plus quelques metriques assez générales peuvent donner une indication.
- a ecrire du code reutilisable ?
Pour des raisons indépendante de ma volontée, je dois zapper cette question (non, je me defile pas).
- a ecrire des routines de tests pour les differents modules de son soft ?
Pour chaque classe définie je doit définir un ensemble de jeux de test. Une classe est validée au niveau projet que si elle passe ses jeux de test. Sinon, refus d'intégration. A noter que les jeux de test sont bien entendus definis par un tiers, à partir de la spécification.
- et a les utiliser ?
Forcement, si t'a pas envie d'utiliser les outils définis pour le projet, ca va pas marcher terrible (ou si tu met blabla dans tes commentaires aussi). Mais en XP, je laisse mon binome bosser et faire ce qu'il veut de toutes façon.
Je le redis. UML est une boite à outil. Si t'a pas envie d'utiliser un tournevis numero 14 pour enfoncer une vis numero 14, ca va pas marcher terrible.
[^] # Re: hum
Posté par Anonyme . Évalué à 0.
> Oh, la belle entrée en matière, j'ai failli pas répondre a cause de cette phrase.
> Tu as de la chance, je suis de bonne humeur.
Vraiment, ta phrase ne meritait pas mieux.
> Je répond et tu me dit comment XP va le faire pour faire tout ça OK ?
Pour XP, j'ai fini le bouquin hier soir, donc je n'ai pas eu encore le temps de tester en reel :-)
Mais tout ce qu'ils recommandent me parait tres tres sense..
Comme UML, je pense que c'est un tout et que tu as du mal a ne parler que d'un des aspects.
L'accent tres fort mis sur la communication inter-developeur, developeur-client, developer-manager, manager-client, le partage du code, les tests, la recherche de la simplicite, la restructuration permanente de ton code, les release a intervalles courts. Tout ca doit contribuer aux effets precites.
Ce que tu dis a l'air interessant et merite certainement d'etre creuse (un peu). Mais je n'arrive pas a me defaire de l'idee que c'est un carcan rigide.
Comment UML gere-t-il les changements de spec ? Genre, je fais mon schema UML, j'ecris ma classe, et je m'apercois deux mois plus tard que en fait, il faut fusionner cette classe avec une autre, qui a aussi deja ete codee. Est-ce que tou mon travail est nique ?
"C'est quoi du code clair ?"
Du code que tout le monde comprend. Notamment 6 mois plus tard, quand qq'un doit faire une modif. Puisqu'en XP, il est ecrit a deux, il y a de fortes chances qu'il y ait plus de deux personnes qui le comprennent. Le code est aussi le plus simple possible.
"- a ecrire du code reutilisable ?
Pour des raisons indépendante de ma volontée, je dois zapper cette question (non, je me defile pas)
"
De toute facon, la reponse est difficile.
L'approche XP de ce probleme est:
- on utilise des regles de codage donc le code est lisible.
- le code est deja ecrit par deux personnes donc il est pas trop "private"
- faire le code le plus simple possible qui resoud votre probleme. Pas la peine de s'embeter avec des solutions compliquees potentiellement utiles et inutiles en pratique.
- votre code doit parler de lui-meme.
- ne pas hesiter a le restructurer en permanence pour qu'il parle plus et soit plus clair. On ne doit aussi avoir une fonctionnolite codee qu'a un seul endroit et un seul. Donc facilite de modification..
- un jeu de test garantit qu'il marche.
"- a ecrire des routines de tests pour les differents modules de son soft ?
Pour chaque classe définie je doit définir un ensemble de jeux de test. Une classe est validée au niveau projet que si elle passe ses jeux de test. Sinon, refus d'intégration. A noter que les jeux de test sont bien entendus definis par un tiers, à partir de la spécification
"
-> Black box testing.
Celui qui teste verifie uniquement que ta classe ressemble a sa specification et repond au methodes qui sont definies.
XP prefere le "white box testing". Tu connais ta classe. Tu teste "tout ce qui pourrait ne pas marcher". Cela veut dire que tu vas probablement ne pas tester une ou deux fonctions triviales, mais que en revanche, la ou tu as des doutes, tu va tester beaucoup plus. Tes tests seront plus intelligents.
UML m'evoque une approche tres theorique et academique de la programmation. Voici les problemes, voici les solutions theoriques: plus de doc, une meilleure conception des le depart, patati patata. Mais tout le monde sait qu'ecrire de la doc, ca fait chier les developpeurs. Faut pas aller trop contre la nature, mieux vaut se faire plaisir..
XP a l'approche opposee: d'habitude, un dev, ca se passe comme ca: la doc n'est jamais a jour, ca emmerde tout le monde de la faire, les documents de conceptions ne sont pas a jour, les specs ont eu besoin d'etre changee parce que le client a change d'avis, ...
Et XP a une approche pour gerer ces problemes reels.
Comment tu fais quand tu t'apercois au bout de 6 mois que ton projet va prendre non pas 6 mois de plus mais un an ? Quand ton client change d'avis ?
[^] # Re: hum
Posté par kadreg . Évalué à 0.
Je vais faire une réponse un peu générale. Les réponses que je t'ai donné correspondent à comment utiliser UML pour répondre aux différents besoins que tu as exprimé. La mécanique des métriques de lisibilité, ou des black box testing sont une réponse courament apportée pour utiliser UML dans un projet. Dans un autre projet (cas quand même très particulier), il a fallut outiller autour d'UML pour modéliser des test fonctionnels et non fonctionnels dans le cadre du temps réél. Donc on s'est couplé sur un système de couverture de test afin de générer automatiquement une couverture maximale de tests, et de trouver les chemins possibles, etc ...
UML n'est pas une méthode (redite). On ne te dit pas comment faire quelque chose (c'est du role du process, dont le RUP est un exemple, mais il y en a d'autre qui vont mieux suivant le cas, notamment dans le domaine des télécommunications), mais on te donne des outils pour exprimer ce que tu veux avec un modèle.
D'ailleurs, XP fonctionne très bien avec UML, notamment toute la partie correspondant aux CRC cards.
[^] # Re: hum
Posté par kadreg . Évalué à 1.
Euh, en UML, tu peux modéliser n'importe quoi. La specification de base de données ne represente qu'une infime part de la modélisation UML. Ici, on modélise tout, aussi bien en statique qu'en dynamique, et quand quelqu'un doit intervenir sur le projett, on commence par lui faire lire la spécification, farcie de diagrammes UML. Il ne touchera au code que quand il aura compris la structure de l'application, et pour ca, UML nous aide bien.
# RationalRose == M$ !
Posté par Anonyme . Évalué à 5.
Sinon, en rapport au sujet de ce commentaire, je voudrai signaler que RR est l'equivalent de M$ dans le monde des modeleurs/AGL. Ils imposent leur produit toujours pas de tres bonne qualite et enferment leur client a leur propres outils grace a des formats proprietaires (ou est XML et XMI pour la sauvegarde des donnees par exemple).
Malheureusement, les autres alternatives ne valent pas mieux la plupart du temp :(
Sinon, il existe differents projets dans le monde du libre : ArgoUML, kUML et UML Modeller. Le seul point negatif de ces projets : ils priviligient le design model au detriment de l'analyse model ; ils veulent se focaliser surement sur la generation de code qui n'est pas le propre d'un modeleur mais d'un AGL. Malheureusement, ils font le meme betise que les autres. Au lieu de se distinguer en offrant toutes les fonctionnalites de simple modeleur dans un premier temps (donc en incluant le modele d'analyse qui est le modele qui permet un taux de reutilisabilite assez elevee), ils suivent les traces de produits proprietaires qui n'ont d'interet que de gagner de l'argent, pas de satisfaire avant tout leur client comme ils essaient de leur faire croire ; or ces produits libre n'ont pas cet enjeu ! Pourquoi ne choisissent t'ils pas d'apporter autrer chose, cet autre chose que je n'ai pas encore trouve :(
[^] # Re: RationalRose == M$ !
Posté par Mokona . Évalué à 2.
Tu peux donc tout à fait exporter tes données le jour où Rose ne te plait plus (je ne dis pas que c'est simple par contre).
Sinon, les fichiers de sauvegarde de Rose sont en textes et relativement clairs. On peut donc aussi écrire un exporteur externe à Rose soit même.
Ca c'était pour le deuxième point. Pour le second, je suis d'accord. Rien trouvé dans le libre de très probant. C'est bien dommage car, si j'utilise Rose au bureau, je ne peux pas me permettre de l'utiliser pour mes développements personnels.
[^] # Re: RationalRose == M$ !
Posté par Anonyme . Évalué à 0.
Quant a la methode, ils imposent le leur et qd tu suis un autre processus base sur USDP autre que RUP, he ben tu te fais chiers a incorporer tes propres structures dans la leur :((
Par contre j'ai un peu essaye ObjectDomain et il a l'ai pas mal. Il est aussi scriptabe ... en PYTHON. Il est en full java, aussi tu peux l'utiliser aussi bien sous Windows que sous Unix ou GNU/Linux.
Mig
[^] # Re: RationalRose == M$ !
Posté par Mokona . Évalué à 1.
[^] # Re: RationalRose == M$ !
Posté par Nicolas Roard (site web personnel) . Évalué à 3.
En gros il est franchement bien foutu, il permet de créer des diagrammes de classe, des diagrammes de séquences. Il génère du code (C++ uniquement), de la doc (html et rtf), et sais prendre en compte des modifs faites sur le code ou la doc généré pour les réintégrer dans le shéma. Un vrai régal. Sinon des trucs sympa, par exemple au changement d'un nom de classe tout le projet est impacté, idem si on change la position des arguments d'une fonction, etc.
Son seul défaut est qu'il n'a, bizarrement, pas la possibilité d'importer un projet C++ !!
Donc difficile de le conseiller pour reprendre un projet existant. Par contre, pour un projet qui commence, je le conseille fortement !
(note : la page web a déjà été proposé en lien, voir plus haut).
# Et pour la prog non objet?
Posté par Anonyme . Évalué à 0.
UML c'est très bien pour la conception objet (enfin, c'est ce qu'on dit), mais qu'elles sont les méthodes pour les grands projets en C, par exemple, qui n'utilsent pas une conception objet?
Si qq'un avait une ou deux url, ce serait sympa!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.