Bon je n'ai pas tout lu faut de tempsmais voici au moins un dossier d'analyse UML + génération code Delphi assez complet (et en français
), pour répondre au besoin de doc du posteur initial :
http://www.reseaucerta.org/cotelabo/dev/delphipl/
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Pour tous mes projets et de A à Z
Pour tous mes projets : processus partiel
Pour certains projet et de A à Z
Pour certains projets : processus partiel
Rarement
Jamais
Jamais UML, par contre toujours MERISE
Jamais UML, par contre parfois MERISE
Jamais UML, autre (précisez)
C'est quoi UML ?
Sans opinion
Bon je n'ai pas tout lu faut de temps
http://www.reseaucerta.org/cotelabo/dev/delphipl/
Tutoriels sur les UPS, e-commerce, PHP, critiques de livres...
Pensez à consulter les FAQs et les cours et tutoriels.
FAQ Linux - Cours et tutoriels Linux - FAQ PHP - Cours et tutoriels PHP
Ce forum est fait pour vous et surtout par vous, merci d'en respecter les règles.
Je n'ai rien à voir avec la société www.ovh.com !
Je ne suis pas étonné que UML soit un sujet de tant de passion. UML n'est pas une solution en tant que telle. Pourquoi dire que UML doit ou ne doit pas être utilisé, tout cela dépend de nos besoins.
Personnellement j'utilise UML dans toutes les phase d'un projet:
Etudes d'opportunitées: Use case - Diagramme de séquences/collaboration/Etat
C'est une phase conceptuelle où l'utilisation d'un langage commun facilite les échange avec les futurs utilisateurs du produit (pas seulement informatique). Attention à ce moment une documentation complète doit accompagner les diagrammes utiliser et ceci pour la phase suivante:
Conception générale: Quoi de plus simple que d'écrire un cahier des charges avec la documentation issue de la phase précédente !!! reste à le complèter avec le modèle de classes métier et la partie dynamique associée. Pourquoi un modèle métier ? Car ce n'est pas aux développeurs ou aux prestataires (SSII) de connaître et de modèliser le métier ... forcément c'est pas le leur ... chacun à sa place !
Et voilà pourquoi celles-ci ne pronnent pas à mon avis l'utilisation d'UML c'est une manière de se garantir la maîtrise du développement et surtout de la maintenance !!! Qui pourrais reprendre une grosse appli sans documentation avec des délais et des coût corrects ?!!! Personne !
Conception détaillées: Là, les développeurs peuvent enrichir le modèle pas le modifier. La différence est que l'on doit dans tous les cas retrouver le modèle d'origine sans manipulation. Et cela vaux aussi pour la dérivation dans un modèle relationnel: les règles de dérivation doivent pouvoir être remontées pour retrouver le modèle objet métier d'origine. Car une appli évolutive implique que son système de persistence (SGBDR ou SGBDO) soit construit de la même manière (cf des technologies comme JDO en JAVA).
UML sert à formaliser tous les documents "techniques" d'un projet. Aujourd'hui on se doit de faire des applications évolutives à moindre coût ... sans modèliser et documenter c'est impossible.
Formaliser permet aussi que tous les acteurs parlent le même langage et se comprennent ou en tout cas qu'ils essaient ... c'est toujours dur entre la maîtrise d'ouvrage(celui qui décide et paie) et le maîtrise d'oeuvre (celui qui réalise: SSII) les but étant pas souvent identique.
UML est un outil qui bien utiliser s'avère puissant pour contôler le cycle de vie d'une application.
D'autre part j'occupe fréquement les deux postes MOA ou MOE, et comme personne n'est irremplacable je peux affirmer qu'il est important d'utiliser un outil tel qu'UML ou OOA ou MERISE 2 etc ...
Voilà ! J'espère que celà aidera.
Moby
Ovh, le posteur initial te dis merci. Il n'a pas encore tout lu. En fait il est assez surpris du résultat. Ca demande relecture. Je pense avoir fait des progrés sur UML depuis mon post initial, mais c'est pas encore ça.
En tout cas, merci beaucoup pour cette exemple.
Vous avez dit UML ???
Pour avoir assez etudier UML en cours et pour avoir avoir bosser depuis 2 ans dans une grosse boite avec notamment certain TRES GROS projet déployés sur plusieurs dizaines de sites partout en france je peux vous dire que dans cette société je n'ai presque jamais entendu le mot UML !!!
Donc moi j'en conclu pour avoir vu les resultats de ces GROS projets déployés et développés sans analyse et bien que c pas joli joli......
Donc étudier et analyser des projets et programmes OUI mais avec UML pas forcement.....
Je recommande ce Cours et tutoriels pour apprendre UML : Cours complet pour apprendre UML 2.0, une série de tutoriels par Laurent Audibert
je parles pour l'informatique de Gestion
Pour moi, la modélisation des données c'est Merise. La modélisation des classes applicatives UML dépendant de l'analyse Merise.
Pourquoi:
Merise et UML sont pour moi complémentaires et pas conceurrents.
Si on dis UML pour tout, on considère que l'application vaut plus que les données. Depuis quand ?
La grande tendance c'est l'objet à tout va, la modélisation UML etc ... Arrêtons nous un instant. Que veut le client ? Il veux des données qui représentent quelquechose pour lui. Des données qu'il pourra intégrer dans un outil décisionnel, consolider etc ...
Aujourd'hui au regard du relatif échec des bases de données Objet, la plupart des bases me semblent encore aujourd'hui de type Relationnel. Et rien ne remplace Merise sur la conception d'un modèle relationnel de données.
Ensuite on peu parler UML. Quelles classes pour quels traitements, qui à la résponsabilité de quoi et à qui déléguer. Comment communiquer de façon efficace sur les processus métiers (Diagrammes de Séquences etc...).
Voilà comment je l'utilise. Ni plus ni moins et si on me laisse le choix je n'en utilise que les diagrammes pour communiquer sur le projet avec les développeurs pour définir les règles et leur rendre plus facile la compréhension des Design Patterns et la maintenabilité du Système.
Les cartes CRC ne sont pas mortes
Tu peux implanter sur BD relationnel avec une analyse UML ?
En effectuant, l'analyse uml rien ne t'oblige à implanter sur une base Objet...
Je suis d'accord sur ce dernier point mais pour moi le meilleur outil de modélisation pour une base relationnelle est Merise sous AMC Designer. Les MCD et MPD sont des standards sur les projets.
Seuls les MCT (modèle conceptel des traitements) peuvent être avantageusement remplacés par une modélisation UML
J'utilise UML depuis plus de sept ans maintenant et pourtant je n'ai pas d'expérience de génération de code. Pourquoi ?
Parce que je m'en sers pour modéliser des relations fonctionnelles entre applications et entre applications et utilisateurs. En gros je me sers principalement :
- des diagrammes d'activité pour décrire les enchaînements de processus métier de niveau entreprise : acteurs et tâches
- des diagrammes de classe et de packages pour décrire les objets métier par application : une application = un package
- des diagrammes d'interaction pour décrire les échanges entre les objets métier automatisés : plutôt les diagrammes de collaboration, plus pratiques quand il y a beaucoup d'objets en jeu pour peu de messages entre couples d'objets
Le but est de faire le lien entre plusieurs populations :
- - les utilisateurs, acteurs des processus d'entreprise
- les responsables des données de chaque domaine applicatif (DBA)
- les responsables des interfaces inter-applications
L'objectif n'est pas ici de produire du code, mais d'aider à comprendre comment on va produire le code (ou l'acheter et l'intégrer), et à quoi ça sert de le faire. Et de faire collaborer plusieurs groupes de développeurs ou responsables de domaines applicatifs.
Ceci requiert que chaque population concernée retrouve l'écho de ses préoccupations. UML facilite cette approche, parce que c'est un langage à plusieurs plans, et je n'en connais pas d'autre qui ait cette vocation d'associer plusieurs vues entre elles.
>Un utilisateur peut comprendre sans difficulté un diagramme d'activité, et aider à le perfectionner, tout en comprenant en quoi les tâches impliquent des objets métier de chaque package.
>Un DBA peut réutiliser le schéma des objets métier d'un diagramme de classe et le transformer en MCD, MLD, MPD merisien/relationnel.
>Un développeur d'interface ou responsable d'EAI peut reprendre les diagrammes de collaboration et la description logique des messages pour en faire la base de ses négociations avec ses interlocuteurs d'autres domaines.
UML pour moi, c'est ça : préserver avec souplesse l'expression des besoins de chacun en les associant d'une manière formellement cohérente.
Après, on passe aux méthodes et outils de développement propres à chaque domaine, où tout le monde retrouve sa liberté de mouvement et de choix. Y compris, et surtout, dans des approches non objet.
Je trouve cette vision très intéressante et effectivement, je comprends l'intérêt que peut apporter UML à ce niveau.
Du point de vue client, notamment d'un pôle architecture et intégration il est tout à fait intéressant de se plonger dans une optique de système d'information organisé autour d'une modélisation UML et d'intégrer les prestataires dans leur démarche.
La charge en amont pour le client est phénoménale pour atteindre ce stade (formation UML des utilisateurs et administrateurs, mapper les concepts métiers etc ...)
Pour moi la grosse partie du travail doit être menée par le client qui est prêt à en payer le coût.
S'intégrer dans un projet pour un client dont l'UML est une des clefs de l'organisation ne posera pas de problèmes car l'intérêt de l'UML et réel et le coût associé à la mise en oeuvre documentaire est bien compris.
Par contre, si le client ne se pose pas de questions par rapport à l'UML et que l'on débarque avec une méthodologie UML, le coût n'est pas forcément bien compris et surtout la formation utilisateur consommera beaucoup de ressources et une mauvaise compréhension des schémas peut entraîner une inadaptation de la solution.
UML oui, mais pour ceux qui sont prêts et qui le demandent.
Malheureusement aujourd'hui je constate que chez de très gros clients, les problèmes politiques et de compréhension entre services rendent difficile la mise en place de l'UML.
Parfois les clients espèrent que via un projet utilisant UML il vont faire en sorte de mettre en place l'UML dans leur entreprise. Le beurre et l'argent du beurre. La modélisation UML des processus métier d'une entreprise doit être un projet en tant que tel. Si le projet informatique est un projet de refonte complet du système d'information, le coup est jouable mais les coûts doivent suivre.
Re: re
Je fais mes applis sans utiliser UML (j'ai terminé mes études en 96 et à l'époque la seule méthode d'analyse qu'on m'a apprise est une méthode orientée BDDR et il s'agit de Merise).Envoyé par silvermoon
Notre prof nous avait montré les 3 pavés qui constituent la méthode dans son entier et nous a dit que pour l'utiliser complètement il faudrait se plonger pendant 3 ans dedans....
En pratique, de Merise je n'utilise que le MCD.
Pour le reste, je fais ça de tête à et à l'instinct.
Maintenant, si j'avais à développer une appli de 6 millions de lignes de code en C++ avec une centaine de milliers de classes différentes, je pense que je me pencherais sur l'utilité d'une méthode d'analyse orientée "production de code".
Une vie de dev sans formalisme
Je pratique la programmation objet depuis 88 en commençant avec ADA, programmation par objet pour les puristes.
À cette époque, la PME dans laquelle je travaillais, collaborait avec des sociétés de services bien connues, nos rencontres avec les développeurs étaient assez édifiantes, ils nous montraient les gros classeurs de conception formelle, à l'époque ce devait être Merise, et il semblait qu'ils ne les utilisaient pas réellement car entre temps tellement de choses avaient changé que cela était devenu inutile, et les délais ne permettaient plus de les actualiser.
Une expérience plus récente m'a pas mal éclairé aussi. Reprenant la direction d'un projet de 5 ans dans une toute petite entreprise, j'étais très surpris de la quantité de documents écrits par les équipes au démarrage. Au départ très content, j'ai vite déchanté lorsque je me suis aperçu que le décalage avec le code réel était en fait énorme, normal au départ, l'argent d'un capital-risqueur coulait à flot
Une expérience encore plus récente. La startup dans laquelle je débutais avait fait appel à une entreprise de service pour amorcer la partie en Java du projet. Ils ont commencé par faire de l’UML, des graphes de séquence, qu’en est-il resté ? Rien, nous étions dans une approche trop informelle avec des itérations trop nombreuses, essais, échec, tout effacé, recommencer… Ce type de formalisme n’a sans doute pas tenu le coup face aux contraintes de la vie réelle et la personnalité du CTO ?
En 16 ans, je n'ai jamais utilisé de manière formelle d'outils de conception et de formalisation, hormis la lecture de Grady Booch sur Ada et les Packages fin des années 80.
Je dois ma formation objet essentiellement à la pratique de NeXTStep/OpenStep/Interviews et donc l'apprentissage des Design Pattern par osmose... Comme me Jourdain je faisais....
La lecture du code des autres, de quelques bouquins, est la voie la plus utilisée non ?
Nous avons tenté plus d'une fois de faire acquérir des outils spécialisés, mais beaucoup trop cher pour l'employeur, nous utilisions en général les outils GNU, pas très chers il est vrai
Cela nous a t-il empêché de produire des applis de qualité? Non assurément, et les négociations avec les clients se situaient sur un autre niveau, et quelques slides suffisaient amplement.
De mon côté, plutôt académique, j'ai toujours noirci mes cahiers de mes schémas et réflexions, beaucoup de commentaires dans le code afin de retrouver mes petits, mais c'est vrai, c'est surtout bon pour soi même. Pour les autres il est essentiel d'avoir un document 'Concept', mais a t-on le temps? en général non, et ça n'intéresse personne à par soi même pour y voir plus clair...
Il y a une vraie culture de la bidouille, du hack, du patch, malheureusement...
Me trouvant au chômage actuellement, je m'aperçois que les annonces sont remplies d'UML, de Rationale et consort, alors je m'y mets pour avoir le vocabulaire et les bases afin de ne pas paraître ridicule.
Et il est vrai que la perspective de me mettre à mon compte fait que je l'envisage sérieusement. Il m'apparaît clairement que c'est un outil de communication indispensable. Mais ma vocation pour la simplicité me fait croire aussi qu'il est bon de l'utiliser pour les schémas généraux afin qu'ils puissent être réellement compris par le client, et par soi-même par la même occasion. Le code n'en sera que plus simple, et ce n'est pas un mal, vu la tendance à la complexité de certains codeur pur et dur, plus c'est tordu mieux c'est
Certains schémas font très peur quand même
Les méthodos c'est comme la prose: tout le monde en fait sans le savoir
Le besoin de méthodo n'a rien à voir avec tel ou tel langage: quel que soit le langage une méthodo est nécessaire parce que cette nécessité découle des contraintes d'environnement qui évoluent sans cesse, de la taille et de l'organisation des projets: travailler seul est beaucoup plus productif alors que dans une équipe de 10 personnes sa productivité décroît drastiquement sans méthodologie pour communiquer ou coopérer avec les autres.
Mais l'implémentation d'une méthodo dans tel ou tel langage présente plus ou moins de difficultés donc il est nécessaire d'y travailler par avance avant de s'y lancer tête baissée.
2 exemples concernant l'uml pour un projet
via dflp
http://www.nevrax.org/docs/
le premier http://www.nevrax.org/docs/img/nelnet_uml.png
le 2nd http://www.nevrax.org/docs/img/nelnet_uml2.png
UML
J'avais le bon présentiment qu' UML ne fait pas l'unanimité en France. MERISE y a le dessus peut-être pour sa simplicité et il y a aussi le fait que c'est "made in France".
Pour la plupart de mes projets je privilégie MERISE qui est suffisant pour des sujets "bateau" comme la gestion documentaire et compagnie... Des outils comme Visio ou Word peuvent faire l'affaire.
Pour UML, il devient intéressant dans certains cas vu qu'il a une syntaxe plus élaborée et que de nombreuses choses peuvent être modélisée de façon plus fine. Je l'ai utilisé pour la conception d'un système de contrôle d'accès à un site et dans un projet de modélisation d'un logiciel de taxation.
Cependant j'estime qu'un logiciel de modélisation (comme Objecteering) est utile pour gérer facilement la documentation et les nombreux modèles.
Par contre
Avec beaucoup de retard, j'ai regardé les exemples d'emplois d'UML d'aprés le lien fourni par Ovh. Ca me parait etre en fait une demarche inversée. D'aprés les contenus UML, il semblerait que les schemas aient été générés APRES que l'application ai été modélisée et developpée. Je pense que cet génération a été faite avec ModelMaker.
Le temps a passé et j'etudie maintenant au CNAM pour un DEST. L'UML est au programme dans le cadre de l'UV de programmation objet. C'est paradoxal, mais pas comme outil (de représentation) dans l'UV 'methodologie des systèmes d'information' dans lequel nous voyons SADT, Merise et OMT. Il aurait été interressant, par exemple, de voir un même projet, etudié via les 3 méthodes puis au final représenté par UML.
En revanche, parmis mes connaissances du monde du travail, rien n'a evolué concernant l'usage d'UML depuis mon post initial dans ce thread.
Ca devient compliqué. Juste pour parler de la nuance entre UML et une méthode de modélisation (Merise, etc...).
Si pour le prof de 'Methodologie des S.I.', UML n'est clairement qu'un outils ouvrant un eventail de diagramme, pour le prof qui nous enseigne l'UML, ca n'est pas le cas. Je suis d'ailleurs assez d'accord avec lui, dans le sens où finalement, les demarches pour produire les diagrammes est de même nature que celle utilisée dans les autres méthodes (captures des besoins, analyse, rédaction et représentation sous forme de schémas). Les nuances sont sur la forme de reflexion et la façon d'appréhender le probleme (structurée descendante,objet ou systémique). La nuance est d'ailleurs encore plus floue quand on compare OMT et UML.
Aprés discussion avec le prof de 'méthologie des S.I.', il s'averre que les réponses concernant ces nuances ne sont guere convaincante. Ca tourne autour du 'c'est comme ça', avec en arriere plan, un petit gout 'moi prof, moi savoir, toi eleve, toi ecouter'.
Loin de moi l'idée de mettre en conflit ces 2 profs, mais aprés discussion avec le prof enseignant l'UML, je partage son opinion concernant ce type de débat : Ce sont des discussions de principe et d'opinions.
Je vois bien de qui il est question dans ce post. J'ai eu ce prof. Il a beaucoup de connaissance mais dommage qu'il n'écoute pas
Mais ceci n'empêche pas de pouvoir évaluer, mesurer, quantifier la pertinance et l'aisance à l'usage... non ?
Je prends part à la discussion après avoir lu ces 5 pages, ainsi que le cours UML disponibles en lien.
Je suis un développeur junior, plutôt orienté vers la programmation python et la conception de logiciels. Jusqu'à mes exams de BTS IG, je n'avais jamais entendu, enfin je ne m'étais jamais attardé sur UML.
Il est vrai qu'au jour d'aujourd'hui, les annonces d'emploi préconisent l'utilisation d'UML. J'ai lu dans ce topic que certaines personnes se mettent à UML car c'est à la mode. En effet, personnellement, je peux dire que c'est vrai, mais d'un autre coté, si on veut répondre aux exigences d'une entreprise, il est nécessaire d'avoir des notions. Il est clait que comme tout langage, on ne peut pas apprendre en quelques heures de lectures intensives. Mon but, aujourd'hui est d'acquérir les bases d'UML. Pour cela je me lance dans un projet et je compte bien me servir de l'analyse UML pour le créer.
En attendant, j'ai encore quelques lectures à faire. Mais, j'espère que je ne vais pas dire de betises, j'ai un peu besoin de lumières, on parle d'UML vs Merise, je ne vois pas pourquoi, si j'ai bien compris, UML est surtout utilisé pour analyser la conception d'un programme, alors que merise sert plutôt à analyser une base de données.
Pour moi, lors de la planification de mon programme, je vais définir mes classes via UML, mais afin de créer mes bases de données, je vais utiliser merise.
Est-ce que je me trompe? ou est-ce que je mélange tout?
Merci
UML : escroquerie intellectuelle ?
Tout à fait d'accord. Enfin quelqu'un qui brise le tabou. Le problème fondamental d'UML est qu'il n'est pas précisé exactement de quoi il s'agit : tantôt simple norme graphique, tantôt cadre de modélisation, voire même outil de conception, ce qui est une chose tout à fait différente. Si on le conçoit comme simple norme graphique, on peut effectivement l'utiliser; le problème est qu'on essaye à partir d'UML d'orienter la modélisation, ce qui est une aberration car UML est totalement déficient de ce point de vu. Un problème fondamental est l'absence de modélisation fonctionnelle globale du projet, qui doit être le préalable. Baser la réflexion sur le projet à partir des cas d'utilisation (les fameux use case) est totalement idiot, car c'est le projet lui-même qui va définir le mode d'utilisation, et pas l'inverse ! Il faut bien distinguer ce qui est interface de ce qui est fonctionnalité, la première dépendant de la seconde. Un autre problème d'une modélisation UML est la confusion entre modèle de donnée, fonctionnalité du projet et organigramme : si on prétend montrer les interactions fines entre classes, on va rapidement se trouver face à une usine à gaz ingérable.
Si vous ne trouvez pas d'exemple de modélisation intégralement UML appliquée à un cas réel et qui aille au-delà du retrait au guichet bancaire, c'est peut-être parce qu'il n'y en a pas !
UML est enfin le reflet des insuffisances du modèle objet lui-même, qui s'applique en réalité trés mal à la plupart des projets informatiques. Le modèle objet suppose de nombreux exemplaires (instances) d'un même type d'entités possédant leurs propres données et méthodes; or dans les projets on agit généralement séquentiellement sur une même donnée que l'on va modifier en fonction des besoins, ce qui fait qu'on n'utilise presque toujours une seule instance de chaque classe (à l'exception d'objets techniques comme des tables). La "programmation objet" se réduit souvent à utiliser des objets comme on utilisait les modules et les sous-programmes dans les langages traditionnels. Il y a malheureusement une "dictature de la mode" en informatique, où tout le monde fait semblant de trouver trés bien quelque chose de peur de paraître passéiste. Moultes vessies se croient lanternes....
Répondre avec citation
Partager