Le code est-il généralement généré à partir d'UML?
Donc, quand j'étais à l'université, j'ai été éduqué sur les avantages de UML et son avenir dans le développement de code.
Mais d'après mon expérience dans l'industrie, j'ai découvert que même si nous utilisons des diagrammes - allant des diagrammes ER, des diagrammes de classes, des diagrammes d'état aux diagrammes de flux de travail - tout cela est à des fins de communication.
Autrement dit, je n'ai jamais généré de code automatiquement à partir de diagrammes, et du point de vue de la communication, j'essaie généralement de garder mes diagrammes aussi simples et faciles à comprendre que possible.
Mais quand je regarde Visio et Enterprise Architect, il semble qu'ils ont de nombreux types différents de graphiques, formes, objets de propriétés, dont la plupart ne sont pas utilisés.
Les gens utilisent-ils UML pour faire des choses plus sophistiquées telles que la génération de code ou de base de données?
Oui, les outils UML CASE étaient l'un des articles phares des années 90 ... et n'ont pas été livrés.
La raison fondamentale en est que les diagrammes UML (ou la plupart des autres types de diagrammes) aident à comprendre le problème et/ou le programme qui le résout uniquement dans la mesure où le diagramme est résumant les détails de l'implémentation du code réel . Ainsi (pour tout morceau de code non trivial), un diagramme qui est facile à comprendre est intrinsèquement inutile pour la génération de code, car il manque les détails nécessaires. Et vice versa, n diagramme qui est directement utilisable pour la génération de code ne vous aide pas beaucoup à comprendre le programme mieux que le code lui-même. Si vous avez déjà vu un diagramme de classe UML rétroconçu à partir du code de production, vous savez probablement ce que je veux dire.
La seule exception potentielle à ce que je sache est les diagrammes Entité-Relation, qui ne comprennent pas le code en soi, seulement (comme leur nom l'indique) des éléments de données et leurs relations. Mais je n'ai jamais entendu parler d'une tentative réussie d'utiliser tout type de diagrammes UML pour la génération de code réel [Update] - c'est-à-dire plus que des squelettes de classe et du code trivial comme des getters/setters -, sauf dans des outils spéciaux/domaines comme ORM, comme en témoigne Doc Brown ci-dessous [/ Update], et je pense que ce n'est pas un accident.
Personnellement, je ne déteste pas UML - je pense que les diagrammes UML peuvent être un excellent outil de communication - pour montrer votre intention et vos idées lors des discussions de conception, ou pour visualiser l'architecture de votre application. Mais il vaut mieux les garder à cela et ne pas essayer de les utiliser pour des choses dans lesquelles ils ne sont pas bons.
Donc, quand j'étais à uni (il y a quelque temps maintenant), on m'a dit que UML était le futur, UML remplacera la programmation et nous générerons simplement du code à partir de diagrammes, etc.
Ils avaient tord. Cela arrivera au moment où les gens abandonneront le discours et retourneront à la peinture rupestre.
Les problèmes du monde réel et les programmes qui les résolvent ont une complexité essentielle qui ne peut être réduite. Pour produire un programme de travail, cette complexité doit être capturée et exprimée dans un langage exécutable. La question est de savoir si un langage de programmation schématique pourrait être plus efficace qu'un langage de programmation textuel. Nous expérimentons la programmation schématique depuis une trentaine d'années et jusqu'à présent, les preuves sont largement en faveur de la programmation textuelle. Je ne connais aucune application importante produite par la génération de code à partir de diagrammes.
NON
La légende était basée sur l'hypothèse ratée que l'écriture:
class ClassName extends SomeThing
{
}
... c'est difficile et a besoin d'automatisation.
Vous pouvez toujours trouver le croyant occasionnel, ou des foules de croyants.
Mais c'est comme ça que ça se passe avec les religions et les cultes.
J'y suis allé, je ne l'ai pas trouvé trop utile.
Généralement, les diagrammes suffisamment spécifiques pour générer du code à partir d'eux, principalement des diagrammes de classes, n'ajoutent pas grand-chose à la compréhension du programme et vous ne pouvez pas générer de code à partir des diagrammes de présentation comme un cas d'utilisation ou une activité de niveau de présentation qui sont crucial pour la documentation. Un diagramme qui est utile pour comprendre et peut générer du code à partir de son graphique d'état, qui est utile lorsque vous avez vraiment besoin d'une machine d'état. Mais en général, vous devriez essayer de les éviter, car ils sont intrinsèquement sujets aux erreurs.
Sur un projet, nous devions concevoir le code dans le modélisateur UML (Rhapsody) et le générer à partir de là. Cela a fonctionné et était probablement très légèrement plus facile que de taper les en-têtes (c'était C++) et les prototypes à la main. La possibilité de garder ces deux automatiquement cohérents était quelque peu pratique.
Les corps de méthode devaient encore être remplis à la main, car les diagrammes ne peuvent pas vraiment représenter cela, à l'exception des squelettes de machines à états.
D'un autre côté, c'est plutôt complexe, donc vous devez apprendre beaucoup de choses supplémentaires et, plus important encore, cela a été difficile de fusionner. La fusion est bien recherchée pour les fichiers texte et fonctionne avec eux, mais personne n'a encore inventé un moyen facile de fusionner les modifications des diagrammes. Rhapsody conserve en fait une partie des informations dans le code généré et les analyse, donc ce n'était pas totalement inutilisable, mais c'était quand même une complication sérieuse.
Bien qu'il soit certainement possible de générer du code (et même des systèmes entiers) directement à partir de modèles UML, je ne l'ai jamais rencontré utilisé de cette manière.
D'après mon expérience, la plupart des entreprises semblent l'utiliser comme un outil de communication pour les exigences, ou "MS Paint pour dessiner des diagrammes".
Une distinction importante que je voudrais faire est que la plupart des outils de modélisation UML vous permettent de créer un modèle unique de votre système. Visio, par exemple, a une assez bonne compréhension du fonctionnement d'UML et vous pouvez ajouter de nombreuses choses qui ne sont pas directement liées au diagramme. Les diagrammes réels sont simplement des perspectives différentes sur des parties du modèle, vous permettant de mettre en évidence différents aspects du système.
tout cela (diagrammes de modélisation) est à des fins de communication
La modélisation a 4 utilisations importantes dans le processus de développement logiciel:
Outil de conception intégré
Outil de communication
Une aide à la génération de logiciels
Un moyen de réduire la complexité du problème réel de Word (j'ai appris cela de la réponse de @kevin cline ci-dessus)
Le processus de modélisation amène certains concepteurs à réfléchir à des détails non pris en compte lors du codage (et vice versa). La modélisation au moment de la conception vous permet d'envisager une image plus large que de coder une méthode ou une classe dans une langue.
À mon avis, la modélisation est vitale pour la création de bases de données (diagrammes ER), la compréhension des flux de processus (diagrammes d'activité) et la compréhension des interactions utilisateur-système (diagrammes de cas d'utilisation).
Les gens utilisent-ils UML pour faire des choses plus sophistiquées telles que la génération de code ou de base de données?
Oui en effet. Les ERD (pas un diagramme UML) et les diagrammes de classes peuvent être utilisés (selon les capacités de votre outil) pour générer:
1 - DDL (Data Definition Language)
2 - Procédures stockées pour CRUD et diagrammes de classes dans votre langue préférée (moins utile car les outils ORM font plus à ce sujet)
Parmi les fonctionnalités les plus précieuses des outils de modélisation figurent:
1 - Capacité à maintenir l'intégrité du modèle. Si vous effectuez une modification, elle se propage dans le modèle
2 - Capacité de répondre aux questions sur les lieux d'utilisation (où le "compte" est-il utilisé dans mon modèle?)
3 - Possibilité de permettre aux utilisateurs simultanés de travailler sur le modèle
4 - Recherche dans les représentations graphiques
5 - Contrôle d'impression
6 - Superposition (organisez vos éléments de diagramme en couches) afin de pouvoir vous concentrer sur une couche à la fois
7 - Génération de code de base de données pour plusieurs systèmes de base de données
8 - Validation du modèle (vérifie la cohérence, les clés manquantes, les cycles, etc.)
Ainsi, les outils de modélisation, en particulier les bons, font bien plus que Paint.
Nous utilisons Software Architect pour faire des conceptions de haut niveau et pour documenter certaines des interactions de composants les plus obscures dans notre domaine. Nous générons parfois le squelette de l'application à partir des diagrammes, mais une fois cela fait, nous conservons les deux séparément, nous n'essayons pas de rétroconcevoir le code dans un diagramme une fois qu'il est terminé. J'avais l'habitude d'utiliser un outil appelé Rational XDE qui fonctionnait assez bien pour les petits programmes, mais il se perdait lorsque vous commenciez à ajouter des gestionnaires d'événements Swing ou essayiez de travailler avec Struts.
Je pense qu'une grande partie de la raison pour laquelle les gens n'écrivent pas en UML est qu'il faut beaucoup plus de travail pour tout spécifier en UML, puis générer le code à partir de votre diagramme. Je sais que le DoD américain travaille avec l'OMG pour développer des outils qui généreront du code "éprouvé" à partir de diagrammes qui ont été vérifiés correctement, mais j'ai l'impression que vous vous retrouverez avec un ordre de grandeur plus de métadonnées que le code réel. Ce qui est probablement bon (c'est de la documentation, après tout), mais générer des métadonnées n'est pas plus rapide que d'écrire du code, donc vous passez proportionnellement plus de temps.
UML lui-même est un système de notation, de sorte qu'il est une cause de communication et de documentation. Il est rare de générer du code à partir d'un modèle UML, mais oui, il y a des gars qui le font. Les utilisateurs de Rhapsody le font plus souvent que Rose. La partie difficile est de garder le modèle et le code synchronisés, pour la plupart des projets réels, le coût est tout simplement trop élevé.