Visual Studio "15" : Microsoft retire le support du langage de modélisation unifié (UML)
En raison de sa très faible utilisation

Le , par Michael Guilloux, Chroniqueur Actualités
L’Unified Modeling Language (ou langage de modélisation unifié en français), en abrégé UML, est un langage de modélisation graphique conçu pour fournir une méthode normalisée pour visualiser la conception d'un système. Sa dernière version, UML 2.5, est sortie en juin 2015. Publié dans les années 90, le langage de modélisation unifié est couramment utilisé en développement logiciel et en conception orientée objet, mais l’utilisation de l’UML a été en déclin.

Dans la prochaine version de son environnement de développement, de nom de code Visual Studio "15", Microsoft a donc décidé de retirer le support de l’UML dans l’édition Entreprise de son EDI, la seule édition d’ailleurs qui prend en charge les diagrammes UML. « Nous supprimons les concepteurs UML de Visual Studio "15" Entreprise. Supprimer une fonctionnalité est toujours une décision difficile, mais nous voulons nous assurer que nos ressources soient investies dans les fonctionnalités qui offrent la plus grande valeur à la clientèle », explique Jean-Marc Prieur de Microsoft, senior program manager pour Visual Studio.

Dans un billet de blog, il justifie cette décision par deux principales raisons. D’abord, Jean-Marc Prieur explique qu’après analyse des données de télémétrie, ils ont constaté que les concepteurs UML ont été utilisés par très peu de clients. Ce constat a également été confirmé lorsque Microsoft a consulté ses équipes de vente et de support technique. L’autre raison est que la société devrait en plus « investir des ressources d'ingénierie importantes pour réagir aux changements qui se produisent » dans le noyau de Visual Studio avec la nouvelle version.

Pour ceux qui utilisent activement les concepteurs UML, Microsoft recommande donc de continuer à utiliser Visual Studio 2015 ou les versions antérieures, le temps peut-être de décider quel autre outil utiliser pour leurs besoins d'UML.

En réponse au billet de Jean-Marc Prieur de Microsoft, certains utilisateurs suggèrent à l’éditeur des solutions possibles au lieu de supprimer les concepteurs UML. Il s’agit notamment de les proposer en tant qu’extensions ou de les rendre open source. La dernière option pourrait permettre à la communauté de décharger Microsoft de la lourde tâche qu’est aujourd’hui d’améliorer les concepteurs UML pour suivre les changements introduits dans le noyau de Visual Studio avec la nouvelle version.

Il faut toutefois préciser que Microsoft continue de prendre en charge la visualisation de l'architecture .Net et de code C ++ à travers les cartes de code. L’éditeur explique aussi que dans cette version de Visual Studio, des améliorations significatives ont été apportées à la validation de couche (dépendance). Le concepteur de couche, qui permet de spécifier et valider les dépendances dans le code .Net, ajoute un support pour l'analyse architecturale en temps réel (live architectural analysis) avec la Preview 5 de Visual Studio. « Dans cette version, nous avons réécrit la validation de couche pour utiliser le .NET Compiler Platform [mieux connu sous son nom de code “Roslyn”], qui permet de faire la validation de l'architecture en temps réel... Cela signifie également que les erreurs signalées sont traitées comme toute autre erreur d'analyse de code. Ce qui veut dire que les développeurs sont moins susceptibles d'écrire du code qui introduit des dépendances indésirables, car ils seront avertis dans l'éditeur pendant qu'ils écrivent. » On peut donc dire que l'expérience de validation de dépendance dans Visual Studio "15" est destinée à aider les développeurs à respecter les contraintes architecturales d'une application alors qu'ils modifient le code.

Source : Microsoft

Et vous ?

utilisez-vous les concepteurs UML avec Visual Studio ? Que pensez-vous de l’annonce de Microsoft et quelle solution proposez-vous ?

Voir aussi :

Visual Studio "15" : de nouvelles fonctionnalités C++14/17 et des améliorations pour les développeurs Python, dans la cinquième préversion
Visual Studio ''15'' : le générateur de projet CMake s'invite dans l'EDI, une preuve de concept de son support offerte dans la Preview 5
La cinquième préversion de Visual Studio "15" est disponible et apporte le filtrage IntelliSense pour une amélioration de la productivité


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de Jitou Jitou - Membre averti https://www.developpez.com
le 18/10/2016 à 21:23
Le jour ou de vrais développeurs et pas de consultants auto-proclamés développerons des méthodes de conception peut être qu'elles auront un avenir dans nos solutions du quotidien.
Avatar de gretro gretro - Membre actif https://www.developpez.com
le 19/10/2016 à 0:35
Perso, j'aime bien le concept de pseudo-UML lors de la phase de conception, surtout sur Whiteboard. Ça aide beaucoup avec la conception. Cependant, quand le développement est terminé, le code devrait être le morceau qui se décrit. Les tests peuvent également aider.

C'est donc une nouvelle que j'accueille avec ni froid ni chaud.
Avatar de gstratege gstratege - Membre habitué https://www.developpez.com
le 19/10/2016 à 9:21
C'est dommage, mais en même temps c'est normal que "personne" ne l'utilise puisque ils la mettent dans la version Enterprise... A mon avis si c'était dans la version Community ça aurait été beaucoup plus utilisé. C'est dommage.
Avatar de ncambier ncambier - Nouveau Candidat au Club https://www.developpez.com
le 19/10/2016 à 9:43
Heureusement il y a "understand c++"
Avatar de Arnard Arnard - Membre émérite https://www.developpez.com
le 19/10/2016 à 21:45
La partie UML je la fais avec Visio perso :/
Avatar de dranduncandane dranduncandane - Nouveau membre du Club https://www.developpez.com
le 20/10/2016 à 11:41
Et Microsoft a raison de la faire. D'abord l'UML n'était que disponible dans la version architect et UML n'est pas un outil d'architect. UML est un language qui a pour but la compréhension entre business et technicien. Il y a une confusion terrible avec UML a cause de bouquain expliquant les patterns se basant sur un ou deux diagram UML. Alors oui certain outils de UML semblent sympas pour aider a l'architecture mais rien en UML ne permet de vraiment faire ou représenter de l'architecture complexe.
Avatar de Gugelhupf Gugelhupf - Modérateur https://www.developpez.com
le 20/10/2016 à 12:10
Parmi tous les types de diagrammes proposés par UML, les diagrammes de structure, c'est-à-dire diagramme de classe (lorsqu'ils sont techniques) et diagramme de composant, sont très utiles car ils représentent une vision concrète du projet, le diagramme de séquence (famille des diagrammes interaction) est bien aussi pour représenter les échanges synchrones/asynchones entre les différents éléments.

Le problème c'est plus les diagrammes de comportement (diagramme de cas d'utilisation et diagramme d'activité), car ils relèvent plus de l'interprétation qu'autre chose, j'ai déjà vu plusieurs cas durant mes études où un enseignant se contredisait sur sa propre correction d'exercice que l'on refaisait, ou des enseignants qui n'étaient pas d'accord avec leurs collègues (lorsqu'on ne leur révélaient pas l'auteur des corrections ), et bien sûr ils ne sont jamais d'accord avec tout ce qui traîne sur internet et notamment les cours sur Developpez

Le diagramme d'activité pourrait être cool si on le combine à un outil de workflow (genre Activiti), mais au niveau modélisation théorique ça reste assez abstrait dans la compréhension, surtout lorsque la maîtrise d'ouvrage se charge de le créer et que la maîtrise d'oeuvre se charge de l'implémenter
Avatar de Stéphane le calme Stéphane le calme - Chroniqueur Actualités https://www.developpez.com
le 20/10/2016 à 17:08
Visual Studio "15" : Microsoft donne plus de détails sur l'outillage .NET Core,
qui tourne principalement autour des fichiers csproj

Au début du mois, Microsoft a rendu disponible la cinquième préversion de Visual Studio “15”, sa suite de logiciels de développements. Nous avons déjà creusé les nombreux changements apportés comme la disponibilité du filtrage IntelliSense pour C#, VB et C++ afin d’améliorer la production, ou l’intégration du générateur de projet CMake, qui permet la réutilisation de code C ++ sur plusieurs EDI et systèmes. Cette fois-ci, nous allons nous intéresser à l’outillage .NET Core que propose l’EDI aux développeurs.

La suite apporte la commande dotnet new qui permet de créer de nouveaux templates en passant par les outils de ligne de commande .NET Core. Cette commande permet de générer des fichiers projet csproj et Program.cs. Concernant le premier fichier (csproj), par défaut, il aura le même nom que le répertoire.


Microsoft annonce avoir simplifié de manière significative le format csproj pour offrir aux développeurs une expérience plus conviviale de la ligne de commande : « si vous êtes habitué au project.json, vous pouvez voir qu'il contient des informations très similaires », a indiqué l’éditeur. Et de préciser que ce format supporte également la syntaxe générative pour vous éviter de citer les fichiers sources individuels dans le fichier projet. Cela permet d’avoir des dossiers de projets qui ne nécessitent pas l’ajout manuel de tous les fichiers, ce qui a pour conséquence d'améliorer considérablement la collaboration au sein des équipes étant donné que le fichier de projet n'a pas besoin d'être modifié chaque fois qu'un nouveau fichier est ajouté.

Une fois que vous avez lancé la commande dotnet new, voici le template csproj qui est créé par défaut. Notons qu’il vous donne accès à tous les ensembles qui viennent avec le runtime .NET Core comme System.Collections. Il donne également accès à tous les outils et cibles qui accompagnent le SDK Core .NET.

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<Project>
 <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" />
 <PropertyGroup>
   <OutputType>Exe</OutputType>
   <TargetFramework>netcoreapp1.0</TargetFramework>
 </PropertyGroup>
 <ItemGroup>
   <Compile Include="**\*.cs" />
 </ItemGroup>
 <ItemGroup>
   <PackageReference Include="Microsoft.NETCore.App" Version="1.0.0" />
   <PackageReference Include="Microsoft.NET.SDK" Version="1.0.0" />
 </ItemGroup>
 <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
</Project>
Les références paquets Nuget sont désormais intégrés et font partie du format csproj et non plus d’un fichier spécial utilisant son propre format. Ces références sont sous la forme <PackageReference Include="[Package-Name]" Version="[Package-Version]" />.

Par exemple, si vous voulez ajouter une référence à WindowsAzure.Storage, il vous suffit simplement d’ajouter aux deux références précédentes la ligne avec le nom du paquet ainsi que celui de la version.

Code : Sélectionner tout
1
2
3
4
5
<ItemGroup>
   <PackageReference Include="Microsoft.NETCore.App" Version="1.0.0" />
   <PackageReference Include="Microsoft.NET.SDK" Version="1.0.0" />
   <PackageReference Include="WindowsAzure.Storage" Version="7.2.1" />
 </ItemGroup>
Si dans plusieurs cas vous n’aurez besoin que de cibler une seule instance .NET Core, .NET Framework ou .NET Standard avec votre bibliothèque, il peut arriver que vous ayez besoin de plus de flexibilité. MSBuild supporte le multi ciblage comme scénario principal. La syntaxe est relativement simple puisqu’il suffit de spécifier l’ensemble des cibles séparées par un point virgule comme ceci :

Code : Sélectionner tout
1
2
3
<PropertyGroup>
   <TargetFrameworks>netstandard16;net452</TargetFrameworks>
</PropertyGroup>
Cette commande va automatiquement établir le droit #defines que vous pourrez paramétrer dans votre code pour activer ou désactiver des blocs de code spécifiques en fonction des framework visés.

Vous aurez aussi la possibilité d’effectuer une migration de projets project.json existant vers csproj facilement en vous servant de la commande dotnet migrate. Après avoir lancé la commande dotnet migrate, ce project.json génère le même fichier csproj qui a été indiqué plus haut :

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{
 "version": "1.0.0-*",
 "buildOptions": {
   "debugType": "portable",
   "emitEntryPoint": true
 },
 "dependencies": {},
 "frameworks": {
   "netcoreapp1.0": {
     "dependencies": {
       "Microsoft.NETCore.App": {
         "type": "platform",
         "version": "1.0.1"
       }
     },
     "imports": "dnxcore50"
   }
 }
}

Source : blog Microsoft
Avatar de tomlev tomlev - Rédacteur/Modérateur https://www.developpez.com
le 20/10/2016 à 22:39
Cette nouvelle approche semble régler l'essentiel des problèmes qu'il y avait jusqu'ici avec .NET Core. Ils ont gardé les features essentielles du project.json en les adaptant à la sauce MSBuild. Je pense que c'est tout ce qu'il manquait pour pouvoir se mettre sérieusement à .NET Core, parce que jusqu'ici c'était une galère sans nom...
Avatar de Excellion Excellion - Membre averti https://www.developpez.com
le 30/10/2016 à 10:35
Ah, l'UML... des heures de cours, d'apprentissage, de TD, d'exams... toutes basées sur la très fameuse Etude de cas.
Et dès qu'on arrive en entreprise... l'Etude de cas est un post-it rempli à coup de "non, mais je vous demande un truc simple", "non, mais c'est facile", "attendez, on va rajouter un petit truc, pas compliqué"...
Et bien sur chaque "petit truc" remet tout à plat, et c'est autant de diagrammes à revoir.

Et allez expliquer à un employeur d'une PME, que vous allez passer 1 semaine à écrire des hiéroglyphes pour fabriquer LA calculatrice... qu'il n'avait pas imaginé comme ça, et pour qui "ben c'est simple, on clique sur une touche et ça affiche un nombre...".

A cela il faut ajouter des langages comme l'ASP.net qui fait un peut ce qu'il veut en terme de classes, le multithreading après coup, qui vous flingue la conception...

Bref, autant Merise est adaptable aux PME pour les base de données, autant l'UML (d'ailleurs, certains développeurs écrivent tout dans une classe, voir la procédure main, sans se soucier d'optimisation ou des modifications futures) ...

C'est dommage, car l'idée d'origine est louable, mais inapplicable sur des petits projets conçus pour une ou deux fonctionnalités...
Contacter le responsable de la rubrique Accueil