UML - générateur de code
iSofTom
Membre
Bonjour,
je sais que le sujet a déjà été traité plusieurs fois, mais comme je n'y ai trouvé aucune solution je repose la question...
Je suis à la recherche d'un logiciel de modélisation UML (comme le fait très bien Omnigraffle), mais qui va également posséder un générateur de code (pour générer les squelettes des classes, les liens, les attributs, les méthodes, ...).
Est-ce que quelqu'un en connait un (qui tourne sur mac, et bien sûr génère de l'objective-c) ?
Sinon comment est-ce que vous faites pour travailler? Est-ce que vous ne fait que dessiner les schémas UML d'un côté et recodez tout à la main après? C'est ce que je fais actuellement, mais à la longue, et surtout avec un gros projet, c'est vite énervant!
je sais que le sujet a déjà été traité plusieurs fois, mais comme je n'y ai trouvé aucune solution je repose la question...
Je suis à la recherche d'un logiciel de modélisation UML (comme le fait très bien Omnigraffle), mais qui va également posséder un générateur de code (pour générer les squelettes des classes, les liens, les attributs, les méthodes, ...).
Est-ce que quelqu'un en connait un (qui tourne sur mac, et bien sûr génère de l'objective-c) ?
Sinon comment est-ce que vous faites pour travailler? Est-ce que vous ne fait que dessiner les schémas UML d'un côté et recodez tout à la main après? C'est ce que je fais actuellement, mais à la longue, et surtout avec un gros projet, c'est vite énervant!
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
J'ai pas mal tourné en rond mais j'ai rien trouvé.
de même un outil d'édition convivial de Schémas XML qui permet de produire un parser et un ensemble de classes pour impléménter le modèle.
à ce jour les éditeur de shémas sur mac sont plutôt de simple éditeur de texte légèrement amélioré et il ne permettent au mieux que de générer un parseur DOM qui va valider le document.
Mais par exemple lorsqu'on manipule des calendriers. xClaendar (même chose que les iClalendar mais en XML) le Tag Event d'un fichier Xcal repésente un événement.
aujourd'hui sur maC on peut au mieux crer avec un pseudo éditeur de schéma (un éditeur de source) le schémas xCalendar. Avec celui-ci on peut obtenir un parser qui va créer un DOM en vérifiant que le XML était conforme au schéma. mais le tag Event aura généré un Noeud Dom de type élément mais ce ne sera pas un objet Event de la classe des événements.
sur d'autre plateforme le définis mon schéma et je modélise en UML mes objets métier. j'établit les relation entre le modèle et le shéma et l'outil me produit un parseur capable de m'instancier mes objets métier directement à partir du XML et dans l'autre sens me générer le XML à partir des objets métier.
Je trouve la platef-orme Mac superbe et super bien le frameWork Cocoa est plutôt bien foutu.
Mais côté outillage pour le faire entrer dans un monde industriel c'est tout autre chose.
Jetez un oeil à des outils comme Modélio et vous vérez que sur se plan là le Mac est très en retard.
A+JYT
Il le s'agit pas là de générer du code Objective-C pour avoir un parseur XML à partir du schéma XML (du XSD), parseur donc pour parser du XML.
Il s'agit là de modéliser l'architecture de ton logiciel via des diagrammes UML, et une fois que tu es bien au point sur ton diagramme de classes UML et a bien fait la phase d'architecture avec des outils comme UML, de générer le squelette du code Objective-C des classes modélisées en UML.
Un peu comme ce que propose CoreData où tu peux designer ton modèle graphiquement avec Xcode, avec tes entitiés etc... et ensuite il génère le code tout seul.
Malheureusement je ne connais pas d'outils de mon côté non plus, et suis preneur d'une solution.
A moins qu'on ne monte le projet de créer ce genre d'outil ?
Je trouve d'ailleurs ça super bizarre que l'outils intégré à Xcode pour CoreData permette de visualiser ET modifier, alors que pour l'uml il ne peut que visualiser... C'est super bizarre... pourtant j'ai bien fouillé Xcode!
J'en étais arrivé à cette solution également! Bon pas tout de suite car on a un paquet de projets à finir pour la fac. Mais à partir de mi-Mars, et si je n'en ai toujours pas trouvé, je commencerais à y refléchir...
et j'ajoutait qu'il en va de même avec les XSD
les outils de modélisation aujourd'hui sont particulièrement avancé dans le monde java, moins nombreux mais très évolué aussi pour C# ou C++
mais inexistant pour Cocoa.
modélio pour ne citer que lui mais il y en a d'autre propose sur son site un exemple d'une application java sur une architecture SOA dont le but est de gérer le processus de réservation d'un voyage dans une agence.
ce qui inclus la problématique de mettre en adéquation les hébergements avec le transport bref si on regarde la volumétrie de code
sur 40 classes java nécessaire à l'application 38 sont généré automatiquement soit 95% du code
en nb de linge de code sur un total de 4035 2987 sont généré depuis le modèle soir 74%
pour les donné géré par MySQL 140 ligne de SQL généré à 100%
La gestion de bout en bout du processus métier et supporté par BPEL soit 251 lignes de code généré à 100%
On est très loin de ça sur mac.
A+JYT
Cet outil intégré à XCode regorge de défauts, mais l'un d'eux est particulièrement haà¯ssable: il modélise tout. Par exemple, il modélise que chaque objet hérite de NSObject (vraiment très intéressant comme information), ce qui rend les diagrammes totalement illisibles.
Martin Fowler, dans son livre UML Distilled, attire l'attention du lecteur sur les perspectives d'utilisation des diagrammes: Conceptuel, de Spécification, ou d'Implementation.
L'outil intégré à XCode, mais aussi les éditeurs qui pratiquent le retro-engineering ou la génération automatique de code, fonctionnent au niveau de l'Implémentation. Or, il me semble que le but des diagrammes UML est d'abord de documenter l'application ou d'envisager des alternatives lors de la conception. Dans mes propres projets (pas encore trop complexes), j'utilise donc plutôt les diagrammes de classe dans la perspective de Spécification. Voilà qui explique pourquoi je ne me suis pas lancé moi-même dans la programmation d'un éditeur UML (ce qui ne veut pas dire que de tels outils n'ont pas d'intérêt).
Mon travail consiste à modéliser le SI tel qu'il existe (et non pas tel qu'on voulait le faire) et de prendre les modélisation logique des fonctionnels pour arriver à produit un processus d'évolution du SI pour qu'il s'adapte à l'organisation.
bien sur je ne dois pas perdre de vus que le modèle de SI que je propose ne sera jamais atteint et que des évolutions même profondes sont prévisibles.
par manque de chance les personnes côté fonctionnel avec qui je travaille n'utilisent pas de méthodes formelles pour décrire leur organisation ni leur processus métier. j'utilise donc des chose comme BPMN pour la modélisation Métier et UML2 pour modéliser mon SI
Je n'ai finalement jamais de classe très concrètes et remonter un diagramme de classe à partir de code ou d'une base SQL n'est que très marginal pour moi. cela ne permets pas de remonter suffisamment haut dans l'abstraction.
Une fois la modélisation de l'évolution faite au niveau SI Général et actée par l'entreprise. je vais initier plusieurs projets de transformations tant au niveau fonctionnel donc l'organisation des hommes et des métiers que SI et donc logiciel.
pour cela je vais décliner le Processus de transformations global du SI en autant de modèle que d'élément impacté et me servir de modèle UML ou BPMN pour pour faire lancer les projets.
Comme vous pouvez le constater je ne produit pas de soft moi-même. mais l'activité de modélisation est centrale pour moi. Je travaille sur de gros SI et bien sur je ne suis pas seul. et ce n'est pas moi qui décide. d'où la nécessité d'utiliser des méthode formelle pour apporter la matière au décideurs.
Je suis un adepte du Mac depuis 1986. une longue histoire. je n'ai toujours eu que des machine Apple.
souvent je déplore le peu d'implication d'Apple dans le monde dans lequel je travaille. Je comprends qu'Apple ne veuille pas entrer sur ce marché elle-même. la concurrence y est féroce et les acteur de gros morceau. mais je constate que le mac (MacOS) n'est pas adapté à cet univers et difficilement adaptable.
je suis le premier à dire que tout ce qu'on fait avec un PC on peut le faire avec un Mac mais force est de constater qu'à part le mode Bébé (finder restreint) la mise en phase entre un métier et le système n'est pas des plus simple.
et le manque d'outils de modélisation ne font qu'aggraver la chose. lorsque je fille un modèle UML à une boite pour me produire un poste utilisateur répondant à mon besoin fonctionnel elle enrichie le modèle de départ et en produit une conception. de là elle génère un outil en C# qui prends en compte les contrainte métier et les spécificité du SI par dérivation du modèle. de façon quasi automatique. reste une partite plus ou moins grande en fonction de la complexité du problème à coder.
si c'est pour mettre sur un poste Mac bien intégré à MacOS l'équipe de développement doit s'approprier la spec et ensuite se palucher tout le travail à la mimine.
A+JYT