Donc, quand j'étais à l'université, j'ai appris les avantages de l'UML et de son avenir dans le développement de code.

Mais grâce à mon expérience dans le secteur, j'ai constaté que, bien que nous utilisions des diagrammes (des diagrammes ER, des diagrammes de classes, des diagrammes d'état aux diagrammes de flux de travail), tout cela à des fins de communication.

C'est-à-dire que 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 lorsque je regarde Visio et Enterprise Architect, il me semble qu’ils ont de nombreux types de graphes, de formes, d’objets de propriétés, que je n’utilise pas pour la plupart.

Est-ce que les gens utilisent 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 ont été l’un des éléments les plus en vogue des années 90 ... et n’ont ensuite pas été livrés.

La raison fondamentale en est que les diagrammes UML (ou la plupart des autres types de), permettent de comprendre le problème et / ou le programme qui le résout uniquement dans la mesure où le diagramme fait abstraction des détails d'implémentation du code actuel. Ainsi (pour tout morceau de code non trivial), un diagramme facile à comprendre est intrinsèquement inutile pour la génération de code , car il manque des détails nécessaires. Et inversement, un diagramme directement utilisable pour la génération de code ne vous aide pas beaucoup à mieux comprendre le programme que le code lui-même. Si vous avez déjà vu un diagramme de classe UML désossé à partir de code de production, vous savez probablement de quoi je parle.

La seule exception potentielle que je connaisse concerne les diagrammes Entité-Relation, qui n'englobent pas le code en soi, mais uniquement (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'utilisation de n'importe quel type de diagramme UML pour la génération de code réel [Mise à jour] - c'est-à-dire plus que des squelettes de classe et du code trivial comme des getters / setters -, sauf dans les outils / domaines spéciaux tels que ORM, comme indiqué dans le témoignage. par Doc Brown ci-dessous [/ Update] , et je pense que ce n’est pas un hasard.

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 de discussions de conception, ou pour visualiser l'architecture de votre application. Mais il est préférable de les garder pour cela et de ne pas les utiliser pour des tâches qui ne leur conviennent pas.

Donc, quand j'étais à la fac (il y a quelque temps maintenant), on m'a dit qu'UML était l'avenir, UML va remplacer la programmation et nous allons simplement générer du code à partir de diagrammes, etc.

Ils avaient tord. Cela se produira à peu près au moment où les gens abandonneront la parole pour revenir à 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 sous forme de diagramme pourrait être plus efficace qu'un langage de programmation textuel. Nous expérimentons la programmation sous forme de diagramme 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 manquée que l'écriture:

class ClassName extends SomeThing
{

}

... c'est difficile et a besoin d'être automatisé .

Vous pouvez toujours trouver des croyants occasionnels ou des foules de croyants.
Mais c'est comme ça que ça se passe avec les religions et les sectes.

Été là-bas, je ne l'ai pas trouvé trop utile.

En général, les diagrammes suffisamment spécifiques pour générer du code à partir de ceux-ci, 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 vue d'ensemble tels que les cas d'utilisation ou les activités au niveau de la vue d'ensemble. crucial pour la documentation. Un diagramme utile à la compréhension et sur lequel le code peut être généré est le tableau d'états, très utile lorsque vous avez vraiment besoin d'une machine à états. Mais généralement, vous devriez essayer de les éviter, car ils sont intrinsèquement sujets aux erreurs.

Sur un projet, nous devions concevoir le code dans un 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 du C ++) et les prototypes à la main. La capacité de garder ces deux constants automatiquement était un peu pratique.

Les corps de la 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'autre part, il est plutôt complexe, vous devez donc apprendre beaucoup de choses supplémentaires et, plus important encore, il a été difficile de fusionner. La fusion de fichiers texte a été bien étudiée et fonctionne avec eux, mais personne n’a encore inventé de moyen facile de fusionner les modifications apportées aux diagrammes. En fait, Rhapsody conserve une partie des informations dans le code généré et les analyse, ce qui n’a donc pas été totalement inutilisable, mais il s’agissait toujours d’une complication grave.

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 façon.

D'après mon expérience, la plupart des entreprises semblent l'utiliser comme outil de communication pour les besoins ou "MS Paint pour les schémas de dessin".

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, comprend assez bien le fonctionnement du langage UML et vous pouvez ajouter de nombreux éléments qui ne sont pas directement liés au diagramme. Les diagrammes réels sont simplement des perspectives différentes sur des parties du modèle, ce qui vous permet 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:

1. Outil de conception intégré

2. Outil de communication

3. Une aide à la génération de logiciels

4. Un moyen de réduire la complexité du problème de mot réel (j'ai appris cela de la réponse de @kevin cline ci-dessus)

5. 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 de considérer une image plus grande que de coder une méthode ou une classe dans un langage.

À mon avis, la modélisation est essentielle pour la construction de bases de données (diagrammes ER), la compréhension des flux de processus (diagrammes d'activité) et pour la compréhension des interactions utilisateur-système (diagrammes de cas d'utilisation).

Est-ce que les gens utilisent 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 (en fonction des capacités de votre outil) pour générer:

1 - Langage de définition de données (DDL)

2 - Procédures stockées pour les diagrammes CRUD et de classes dans votre langue préférée (moins utile car les outils ORM en font plus à ce sujet)

Parmi les fonctionnalités les plus précieuses des outils de modélisation, on trouve:

1 - Capacité à garder l'intégrité du modèle. Si vous faites un changement, cela se propage dans le modèle

2 - Capacité à répondre aux questions sur l'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 - Calques (organisez vos éléments de diagramme en calques) afin que vous puissiez vous concentrer sur un calque à 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 plus performants, font beaucoup plus que Paint.

Nous utilisons Software Architect pour réaliser des conceptions de haut niveau et pour documenter certaines des interactions de composants les plus mystérieuses dans nos contenus. Nous générons parfois le squelette de l'application à partir des diagrammes, mais une fois que cela est fait, nous maintenons les deux systèmes séparément, nous n'essayons pas de reconstituer le code dans un diagramme une fois qu'il est terminé. J'avais l'habitude d'utiliser un outil appelé Rational XDE qui fonctionnait plutôt bien pour les petits programmes, mais il se perdait lorsque vous commenciez à ajouter des gestionnaires d'événements dans Swing ou que vous essayiez de travailler avec Struts.

Je pense qu'une des raisons pour lesquelles les gens n'écrivent pas en UML est qu'il faut beaucoup plus de travail pour tout spécifier en UML, puis pour générer le code à partir de votre diagramme. Je sais que le département de la Défense des États-Unis collabore avec l'OMG pour développer des outils permettant de générer du code "éprouvé" à partir de diagrammes vérifiés, mais mon impression est que vous obtiendrez un ordre de grandeur supérieur à celui des métadonnées par rapport au 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. Vous perdez donc plus de temps proportionnellement.

Le langage UML lui-même est un système de notation, ce qui en fait un support de communication et de documentation. Il est rare de générer du code à partir d'un modèle UML, mais oui, certains le font. Les utilisateurs de Rhapsody le font plus souvent que Rose. La difficulté 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é.

Dans mon dernier projet, j'utilise UML-Lab (https://www.uml-lab.com). C’est un bon outil qui permet également au modèle d’être inversé. L'outil génère du code Java et même les annotations JPA qui sont assez précises.

Le défi consiste à travailler en équipe. Le modèle est statique et se trouve dans une seule ressource, ce qui rend sa synchronisation avec plusieurs modifications de développeur un peu difficile. Il existe une version d’essai disponible pendant 1 mois, ce qui est un bon moment pour explorer et comparer avec d’autres si vous effectuez une enquête.

C'est la première fois que je vois un produit en train de faire de la modélisation d'objet et de la modélisation de données en une fois, ainsi que de générer du code.

Sinon, dans mes projets antérieurs, j'ai toujours vu des modèles obsolètes inexacts ou trop détaillés.

Dans mes projets antérieurs, j'ai parfois généré des diagrammes par ingénierie inverse. La plupart du temps, je trouvais que les diagrammes étaient encombrés et je préférais les dessiner en filtrant manuellement tout le bruit.

Je pense que nous pouvons utiliser UML pour générer du code. Pas de logique métier, car la logique métier n’est pas un standard et varie d’une application à l’autre. Les diagrammes de classes, ainsi que les diagrammes ER, peuvent être utilisés pour générer des interfaces, des classes, des entités d'hibernation, des méthodes de base de calcul, etc. .

De plus, comme mentionné dans les commentaires précédents, le schéma de base de données, les scripts DDL, etc. peuvent être générés à l'aide de modèles.

En utilisant OAW et un outil de modélisation comme Enterprise Architect, nous pouvons écrire des générateurs de code plus puissants, qui peuvent même aider à générer des fichiers de configuration, du code d'usine à l'aide de stéréotypes et de valeurs étiquetées.

Je ne comprends toujours pas pourquoi l'informatique décisionnelle avec des outils tels que Business Object est capable d'analyser et de tirer parti de toutes les informations de l'entreprise alors qu'au niveau technologique, nous travaillons toujours au niveau du code ou au niveau abstrait avec UML!

Le problème n'est pas UML mais la transformation de modèle entre UML et MOF et la génération de code à partir d'un diagramme de classe ou de xmi à l'aide de modèles. On dit que UML donne une vision abstraite du monde réel, vous ne voyez donc que ce qui est vraiment important. Cela dit, comment générer un code précis si le diagramme UML n’est qu’une vue du monde réel? Il est impossible et par conséquent, le développement piloté par un modèle qui générerait du code à partir d'un modèle a échoué.

La solution consiste à transformer le monde réel et, par conséquent, tout le code du projet en un seul modèle UML. Avec un modèle unique et la logique complète du projet, vous pouvez ensuite générer des vues à partir du modèle et non du code à chaque fois. Omondo a pris une initiative courageuse dans le cadre de la technologie Java / Jee. Le concept est en direct synchronisé MOF et UML directement avec le code et ORM. Les diagrammes UML ne sont plus qu'une vue de haut niveau du modèle qui mappe l'ensemble du projet. Vous pouvez créer des centaines de vues, ajouter des centaines de notes, etc. pour mieux comprendre le projet. Le code ne sera généré que si l'élément est modifié ou créé. Technologie merveilleuse dans laquelle l'ID Java est mappé sur l'ID UML sans le pont de transformation traditionnel entre MOF et UML.

Ce qui est également fantastique, c’est de pouvoir modéliser mon domaine au niveau UML et d’obtenir mes annotations ORM directement dans le code. Ainsi, en utilisant Hibernate, je peux créer, effacer, créer ma base de données, le déployer, etc. dans une intégration permanente et permanente dans laquelle UML fait partie de l’ensemble de l’architecture et non de l’architecture même du projet.

Je n'ai jamais été déçu par UML en tant que visionneuse de haut niveau si la synchronisation en direct avec le code était absolument dévastée par l'utilisation traditionnelle de MDA avec la génération de code par modèles de développement pilotés par modèle. La génération de code à partir d'un modèle est comme une page HTML provenant d'un document Word. Comment le changer une fois qu'il est généré? Il est tout simplement impossible de mettre à jour et vous passez plus de temps à nettoyer le code qu'à écrire à partir de rien!