À quelle fréquence utilisez-vous UML formel?

J'ai utilisé un langage de modélisation composé ad-hoc pour concevoir et expliquer le système assez fréquemment. Il ressemble à UML et a tendance à être assez bien compris.

Cependant, j'ai eu un professeur ou deux qui ont parlé de l'utilisation d'un langage UML formel strict, aussi proche que possible de la spécification. J'ai toujours soupçonné que le langage UML strict n'était pas vraiment aussi courant qu'ils le prétendaient. Alors, qu'en est-il - à quelle fréquence dessinez-vous des diagrammes complets qui utilisent toutes les fins de ligne, la multiplicité, les symboles de type de membre appropriés, etc.?

Jamais.

Zut, ça fait des années que j'ai créé un UML pour la dernière fois . Les schémas linéaires sur les tableaux blancs et les bouts de papier ne comptent pas.

En fait, nous venons de supprimer la seule question UML du guide que nous utilisons lors des entretiens, car aucun d'entre nous ne s'intéressait vraiment aux réponses.

J'utilise juste assez de langage UML (en termes de types de diagrammes et de contenu de l'information dans le diagramme) pour faire passer mon message et permettre à moi-même ou à quelqu'un d'autre de mettre en œuvre le système ou le sous-système. Et la seule raison pour laquelle j’utilise UML, c’est parce que c’est un ensemble bien connu de symboles qui signifient chacun quelque chose de très spécifique. Il n’ya donc aucune ambiguïté. Tout ingénieur logiciel devrait pouvoir consulter le diagramme et comprendre ce que j’essaie de dire à propos du système.

Ironiquement, UML est supposé être flexible.

Dans le monde réel, ce n'est pas censé être un exercice pédant de le faire d' une seule manière. Il s’agit de communiquer et de documenter efficacement un système / processus / idée.

Pour répondre à votre question, je suis avec les autres. Je n'ai jamais utilisé pleinement le langage UML formel.

J'ai utilisé UML très régulièrement pendant environ quatre ans pour un produit générant tous les squelettes de code (la plupart) de Rational Rose.

Au cours des cinq dernières années, il y a eu davantage de "boîtes et de flèches" principalement inventées sur place et généralement suffisantes pour faire passer l'idée générale. Corrigez formellement le langage UML à quelques reprises seulement pendant cette période.

Cependant, j'ai eu un professeur ou deux qui ont parlé de l'utilisation d'un langage UML formel strict, aussi proche que possible de la spécification.

Demandez à votre professeur quand était la dernière fois qu'il a utilisé cette approche sur un système réel. Sérieusement.

J'essaie d'être aussi formel que possible en ce qui concerne UML, mais uniquement si cela a du sens. Les zélés des deux côtés du spectre (des cow-boys aux formalistes exigeants) ne comprennent pas cela.

Il existe des contextes dans lesquels une approche moins rigide (comme celle que vous utilisez personnellement) est la meilleure approche à suivre. Un bon exemple concerne les petits systèmes ou les changements, où les exigences sont petites et pas complètement définies; le groupe responsable est efficace et performant; il est plus important de le sortir que de le rendre parfait. Cela se fait de manière itérative et certaines lacunes sont acceptables.

Ou peut-être êtes-vous à un stade où vous faites de la guestimation et du croquis, par opposition à une phase de modélisation formelle complète. Ce sont des exemples qui me viennent à l’esprit.

D'autres fois, vous avez besoin d'une approche UML formelle rigide. Par exemple, vous pourriez être lié contractuellement; vous avez un très grand nombre de développeurs dans plusieurs équipes (éventuellement distribuées); la portée du projet pourrait être en années; c'est un très gros système (y compris les composants logiciels et matériels); le coût de l'échec est élevé, etc.

A d'autres moments , vous devez utiliser autre chose à la place / en plus du langage UML (modèles formels mathématiques formels tels que réseaux de Petri, CSP ou logique temporelle.) où vous êtes lié contractuellement (par exemple, comme en Europe lors du développement de systèmes de transport).

Tout dépend des circonstances et de ce que nous attendons de chaque approche. Un professeur qui persévère dans les formalités est simplement un zélote aveugle. Le monde de l'ingénierie n'est pas une dichotomie noir / blanc, vrai / faux. C'est un monde de compromis intelligents.

Si vous êtes assez intelligent pour utiliser un modèle informel occasionnel d’une manière efficace et appropriée pour que le travail soit effectué, qu’il en soit ainsi. De même, vous devrez reconnaître quand ne PAS utiliser une approche informelle et / ou quand NE PAS utiliser une approche formelle.

Cela dit, vous devez jouer avec les professeurs. Donnez-leur un os pour qu'ils vous attribuent une note, et si cela signifie de vous incliner enfin devant leur mantra zélé, c'est très bien. Vous savez ce qui fonctionne pour vous et si tout va bien, vous saurez quand utiliser quoi et comment dans le monde réel.

Dans le cadre de ma thèse, j'ai étudié la manière dont des concepteurs expérimentés utilisent UML dans des collaborations de conception (bien que dans des environnements artificiels).

Mes conclusions ont été que des métaphores et des notations UML sont empruntées, mais que la rigueur des outils est peu respectée.

Par la suite, certains modèles peuvent être transformés de manière itérative en langage UML plus strict, souvent lorsqu'un outil CASE exigeant est impliqué dans le but de générer du code.

Les mises en garde habituelles de la recherche académique s’appliquent bien sûr :)

Un lien vers le résumé papier et le document lui-même (si vous n'avez pas accès à ACM) .

En dehors de cela, je recommande fortement la "modélisation agile" d'Ambler.

Nous utilisons UML formel pour la génération de code d’un ORM hibernate. La plupart des autres choses sont informelles ou un tableau blanc. C'est seulement important pour nous avec la génération de code parce que le manque de formalité le casserait.

Cela dépend du secteur dans lequel vous vous trouvez. Si vous travaillez pour des clients qui nécessitent des examens techniques fréquents (par exemple, PDR, CDR, etc.), ils préfèrent une sorte de normalisation plutôt que des systèmes de notation ad hoc. En particulier le travail du gouvernement. Cela évite une mauvaise communication et l'explication initiale de 15 minutes de la notation que vous avez inventée.

En outre, ce n'est pas parce que vous utilisez UML que vous devez doter chaque i de chaque point et le traverser conformément au standard. C'est seulement si vous voulez faire une sorte de génération / exécution de code automatique. Je ne connais personne qui l'ait fait pour plus d'un projet.

D'autre part, si vous travaillez uniquement pour votre entreprise avec une équipe de vos propres développeurs, alors quelle que soit la notation que vous utilisez. Bien que, si vous choisissez le bon outil, cela peut vous faire gagner beaucoup de temps.

Cela dit, vous aurez du mal à vous débrouiller dans certaines industries sans être en mesure de concevoir en utilisant UML. Dans d'autres industries, vous ne le verrez jamais.

De plus, je pense que vous constaterez également une corrélation entre les industries qui exigent une conception correcte, car les coûts de correction sont proportionnellement élevés en tant que gros utilisateurs d’UML; Par rapport aux industries, les coûts des corrections de conception ne représentent guère plus que des modifications de la documentation / du code, car ce sont des endroits où UML n’est probablement jamais utilisé.

En ce qui concerne la question initiale. La plupart des collèges ont tendance à orienter la formation de leurs étudiants vers les entreprises qui recrutent le plus souvent leurs étudiants. Si votre professeur pense que le langage UML est important, cela ne me surprendrait pas que beaucoup d'entreprises qui recrutent dans votre école utilisent le langage UML. Ainsi, vous devriez apprendre à l'utiliser.

Lorsque j'ai lu sur UML, j'ai essayé ceci sur tous les problèmes que je devais résoudre dans mon cours de C ++. Heureusement, l'un des premiers exemples que j'ai essayé était de décrire une liste chaînée.
N'a pas fonctionné
Cela dit, couplé à un bon processus de modélisation, UML est utile. Juste parce que c'est pour le meilleur ou pour le pire une norme.
J'aimerais voir un langage de description de la méta-programmation par modèle. Je pense que cela aiderait beaucoup à comprendre ce qui se passe dans <<<>>> -land

UML est pénible si vous essayez également le développement basé sur les modèles. Je veux dire que UML n’est qu’une notation graphique très utile et que tout le reste est inutile. Je ne dépense pas en modélisation, mais utilise UML tous les jours pour créer la structure de mes projets. Ce que je fais est de dessiner rapidement un diagramme de cas d'utilisation de base aux niveaux requis, puis de passer immédiatement aux diagrammes de classes. J'ajoute une traçabilité des exigences entre les diagrammes usecase et class. Mon diagramme de classes crée également du code car il est synchronisé en direct. Aucune balise dans le code. Tous les modèles sont enregistrés dans le modèle UML associé au projet Java.

Je crée le squelette de mon application avec quelques diagrammes de classes, puis je passe au code. Une fois le code terminé, je le fusionne avec le modèle. C'est une sorte d'itération entre le code et le modèle où le code exécute le modèle. Ainsi, mes diagrammes de classes me donnent un niveau d'abstraction plus élevé et mon code, tandis que mon code me donne l'implémentation de ma logique métier (par exemple, des méthodes).

La modélisation UML nécessite moins de 10 minutes par jour, ce qui est fait lorsque j'ai besoin de temps pour penser à ce que j'ai besoin de développer et comment.

UML est génial, fantastique et vraiment utile mais le développement basé sur les modèles est inutile !!

Si je documente un système que nous avons mis en place, j'essaie de le définir avec du langage UML formel complet. Mais le reste du temps, je n’utilise que tout ce qui est nécessaire pour faire passer l’idée. Je me retrouve également à utiliser plus de DFD qu’UML, car ils semblent mieux convenir aux systèmes que nous avons conçus récemment.

Je viens d'abandonner (du moins temporairement) mon soi-disant collège de premier niveau en raison de son insistance sur des activités de modélisation visuelle excessivement fastidieuses, des tâches de forum, des compétences excessivement redondantes que toute personne qui a grandi autour d'ordinateurs ou qui l'a jamais ludique pensivement vers une interface utilisateur deviendrait suffisamment bon pour que l'idée de s'endetter profondément puisse donner envie de casser des choses dans une frustration totale.

Je devais choisir entre apprendre ce que je voyais comme une tâche exigeante pour les débutants et les subalternes et ce que les CES imposent pour l'accréditation ABET de l'université, ce qui oblige les décideurs à ne rien dire alors qu'il existe des problèmes criants de contraintes de temps et d'attentes irréalistes qui une évaluation PERT révélerait. L'université ne pratique pas ce qu'elle enseigne.

À mon avis, le processus unifié a beaucoup de mérite, mais toute la pratique consistant à frapper des artefacts visuels, quel que soit le langage de modélisation utilisé, est un peu ridicule. Un document affiné de manière itérative contenant une liste sériée, telle que pouvant être produite avec Word, Workflowy, Evernote, OpenOffice ou nommer un traitement de texte, est parfaitement capable de documenter les exigences du processus unifié. Plusieurs utilisateurs peuvent facilement travailler sur ce problème, avec un contrôle de version, et si l’on choisissait le bon outil pour le faire, une équipe pourrait même y travailler en même temps. Cela est tellement plus facile à faire que lorsque UML semblait être un mode nécessaire pour unifier les hordes.