Pourquoi UML n'est-il pas utilisé dans la plupart des logiciels libres (par exemple sous Linux)?
J'essaie de comprendre pourquoi UML n'est pas utilisé dans la plupart des projets logiciels libres. Par exemple, mon système Debian/Linux a probablement plus de dix mille paquets logiciels gratuits, et je ne peux même pas en nommer un qui a été développé en utilisant explicite le cadre et la méthodologie UML. Par exemple, Qt , GCC , noyau Linux , bash , GNU make , Ocaml , Gnome , nison , lighttpd , libonion , docker sont des projets de logiciels libres qui (AFAIK) ne mentionnent pas du tout UML.
(Je suppose que UML est très bien adapté à la sous-traitance formelle des tâches de développement, et c'est pas comment le logiciel libre est développé)
Notez que même si j'ai lu des informations sur UML, je ne prétends pas en avoir une bonne compréhension.
En fait, je ne peux pas facilement nommer un logiciel gratuit où UML a été utilisé (sauf peut-être certains outils UML mis en œuvre en tant que logiciel libre). Peut-être openstack est une exception (quelque chose mentionne UML).
(même les anciens projets de logiciels libres auraient pu adopter UML après leur démarrage, mais ils ne l'ont pas fait)
Certains collègues travaillant sur Papyrus ont mentionné que la plupart des projets de logiciels libres n'avaient à leur début aucun modèle formalisé explicite (et suffisamment approfondi). En outre, UML semble beaucoup plus lié à Java qu'il ne le prétend (je ne suis pas sûr que cela aurait du sens pour Ocaml ou Common LISP ou Haskell ou Javascript, et peut-être même pas pour C++ 11 ....) Peut-être développement logiciel agile n'est pas très convivial UML.
Voir aussi this réponse à une question en quelque sorte liée. Le blog de M.Fowler Design Dead? est perspicace.
PS. Je ne pense pas que ce soit principalement une question d'opinion; il devrait y avoir une raison objective, et une caractéristique essentielle du logiciel libre, qui explique pourquoi. J'ai tendance à deviner que UML n'est utile que pour la sous-traitance formalisée, et n'est utile que lorsqu'une partie du logiciel développé est cachée, comme dans les projets propriétaires. Si c'est vrai, UML serait incompatible avec le développement de logiciels libres.
NB: Je ne suis pas moi-même un fan UML. Je ne définis pas UML uniquement comme documentation papier, mais aussi comme format de [méta-] données pour outils logiciels
Il existe différentes façons d'utiliser UML. Martin Fowler appelle ces modes UML et en identifie quatre: ML comme notes , ML comme croquis , ML comme Blueprint , et ML comme langage de programmation .
UML en tant que langage de programmation n'a jamais vraiment décollé. Il y a eu quelques travaux dans ce domaine sous différents noms, comme Model Driven Architecture ou Model Based Software Engineering. Dans cette approche, vous créez des modèles très détaillés de votre système logiciel et générez le code à partir de ces modèles. Il peut y avoir des cas d'utilisation où cette approche est utile, mais pas pour les logiciels généraux et surtout pas en dehors des grandes entreprises qui peuvent se permettre les outils qui alimentent cette approche. C'est aussi un processus qui prend du temps - je peux taper le code d'une classe plus rapidement que je ne peux créer tous les modèles graphiques nécessaires pour l'implémenter.
UML en tant que Blueprint est souvent indicatif d'un projet "big design up front" . Cela ne doit pas l'être, bien sûr. Le modèle peut également être entièrement décrit pour un incrément particulier. Mais l'idée est que le temps est consacré à la création d'un design sous forme de modèles UML qui sont ensuite remis à quelqu'un pour les convertir en code. Tous les détails sont énoncés et la conversion en code a tendance à être plus mécanique.
UML en tant que croquis et UML en tant que notes sont de nature similaire, mais diffèrent selon le moment où ils sont utilisés. L'utilisation d'UML comme esquisse signifie que vous allez esquisser des conceptions à l'aide de notations UML, mais les diagrammes ne sont probablement pas complets, mais se concentreront sur des aspects particuliers de la conception dont vous avez besoin pour communiquer avec les autres. UML as Notes est similaire, mais les modèles sont créés après le code pour aider à comprendre la base de code.
Lorsque vous envisagez cela, je pense que tout ce qui précède est vrai pour tout type de notation de modélisation. Vous pouvez l'appliquer aux diagrammes entité-relation, aux diagrammes IDEF , à la notation de modélisation des processus métier, etc. Quelle que soit la notation de modélisation, vous pouvez choisir quand vous l'appliquez (avant en tant que spécification, après en tant que représentation alternative) et combien de détails (tous les détails sur les aspects clés).
L'autre côté de cela est la culture open source.
Souvent, les projets open source commencent par résoudre un problème rencontré par un individu (ou, aujourd'hui, une entreprise). S'il est lancé par un individu, le nombre de développeurs est de 1. Dans ce cas, la surcharge de communication est extrêmement faible et il n'est pas nécessaire de communiquer sur les exigences et la conception. Dans une entreprise, il y aura probablement une petite équipe. Dans ce cas, vous devrez probablement communiquer les possibilités de conception et discuter des compromis. Cependant, une fois que vous avez pris vos décisions de conception, vous devez soit maintenir vos modèles à mesure que votre base de code change avec le temps, soit les jeter. En Modélisation Agile termes, "documenter en continu" et maintenir un "source unique d'information" .
En bref, il y a l'idée que le code est la conception et que les modèles ne sont que des vues alternatives de la conception. Jack Reeves a écrit trois essais sur le code comme conception , et il y a aussi des discussions sur C2 wiki, discutant des idées qui le code source est la conception , le la conception est le code source , et code source et modélisation . Si vous souscrivez à cette croyance (ce que je fais), alors le code source est la réalité et tous les diagrammes devraient simplement exister pour faire comprendre le code et, plus important encore, la raison derrière laquelle le code est ce qu'il est.
Un projet open source réussi, comme ceux que vous mentionnez, a des contributeurs à travers le monde. Ces contributeurs ont tendance à être techniquement compétents dans les technologies qui alimentent le logiciel et sont également susceptibles d'être des utilisateurs du logiciel. Les contributeurs sont des personnes qui peuvent lire le code source aussi facilement que les modèles et peuvent utiliser des outils (IDE et outils de rétro-ingénierie) pour comprendre le code (y compris la génération de modèles, s'ils en ressentent le besoin). Ils peuvent également créer eux-mêmes des esquisses du flux.
Parmi les quatre modes décrits par Fowler, je ne pense pas que vous trouverez un projet open source, ou de très nombreux projets n'importe où, qui utilisent des langages de modélisation comme langages de programmation ou plans directeurs. Cela laisse des notes et des croquis comme utilisations possibles pour UML. Les notes seraient créées par le contributeur pour le contributeur, donc vous ne les trouveriez probablement pas téléchargées n'importe où. Les croquis diminuent de valeur à mesure que le code devient plus complet et ne sera probablement pas maintenu car cela nécessiterait simplement des efforts de la part des contributeurs.
De nombreux projets open source n'ont pas de modèles mis à disposition car cela n'ajoute pas de valeur. Cependant, cela ne signifie pas que les modèles n'ont pas été créés par quelqu'un au début du projet ou que les individus n'ont pas créé leurs propres modèles du système. Il est juste plus efficace de gérer une seule source d'informations sur la conception: le code source.
Si vous souhaitez trouver des personnes qui échangent des informations sur la conception, je vous recommande de consulter tout type de forums ou de listes de diffusion utilisés par les contributeurs. Souvent, ces forums et listes de diffusion servent de documentation de conception pour les projets. Vous ne trouverez peut-être pas d'UML formel, mais vous pouvez y trouver une sorte de représentation graphique des informations de conception et des modèles. Vous pouvez également accéder à des salles de discussion ou à d'autres canaux de communication pour le projet - si vous voyez des gens parler de décisions de conception, ils peuvent communiquer avec les modèles graphiques. Mais ils ne feront probablement pas partie d'un référentiel car ils ne sont pas utiles une fois qu'ils ont atteint leur objectif de communication.
Permet d'utiliser Linux comme exemple,
- Ce n'est pas un projet orienté objet, certaines parties, comme le VFS peuvent être modélisées en UML, mais d'autres ne peuvent pas être ou pas très efficaces, c'est-à-dire simplement une simple traduction de
structen un diagramme de classe sans relations . - UML est bon pour la documentation, pour obtenir quelqu'un de nouveau à un projet se met à jour. Ce n'est pas quelque chose qui est vraiment pris en charge par Linux, les gens sont censés l'apprendre eux-mêmes.
- Vous ne savez pas quel outil UML utiliser, les gens doivent se mettre d'accord sur quelque chose s'il allait être maintenu. Il y avait une application Java Java gratuite pour cela, mais je ne pense pas que beaucoup voudraient l'utiliser.
- Dans les années 90, l'interface graphique était toujours un défi sous Linux. Allez simplement creuser les archives de la liste de diffusion, je parie que vous ne trouverez aucun autre type de graphisme que le logo pour Linux lui-même au format xpm à afficher au démarrage. Le texte brut est le format préféré.
- Je ne pense pas que personne ne se soucie vraiment du design. Les gens se soucient des fonctionnalités et s'ils sont acceptés, le code sera examiné. Les cas d'utilisation sont toujours mieux décrits en mots, tout comme la façon dont les normes comme POSIX et SUS sont écrites.
- Beaucoup d'objets dans le domaine des systèmes d'exploitation sont bien compris et standardisés au sein de la communauté. Par exemple. les gens sauraient comment un
struct in_addrressemble en mémoire, aucun diagramme ne pourrait le rendre plus clair. - UML n'aide pas beaucoup dans l'algorithme de modélisation, comme l'allocateur de mémoire, le planificateur, les gestionnaires d'interruption, etc. La source est probablement plus facile à comprendre.
Ce sont les choses auxquelles je peux penser dans les paramètres d'un projet Linux. C'est plus une question pratique, je suppose. Curieusement, je ne me souviens pas que Tanenbaum ait utilisé du UML dans son livre de texte OS pour décrire Minix.
Il vaut probablement la peine de le mentionner, je n'utilise pas non plus UML au travail. Probablement 20% des personnes avec lesquelles je travaille connaissent un sous-ensemble d'UML.
UML est une représentation, c'est donc une forme de langage, et pour le bien de l'argument, supposons que son but est de communiquer un modèle mental d'une personne à une autre.
Ce que je recherche dans une langue, c'est son efficacité à capter les changements de son modèle mental. Supposons qu'après avoir écrit la description de son modèle, un petit changement doit être fait. Quelle ampleur doit être apportée à la représentation? Dans un langage textuel, un moyen de mesurer cela est d'exécuter un diff entre le code avant et après, et de compter les différences. Dans un langage graphique, il devrait y avoir une manière similaire de mesurer la différence.
À mon humble avis, j'appelle un langage "spécifique au domaine" (DSL) dans la mesure où il minimise la mesure ci-dessus, ce qui présente des avantages évidents en termes de réduction des coûts de maintenance et des bogues. Comment faire une DSL? Il y a plusieurs façons. L'un des plus simples consiste à simplement définir les structures et les méthodes de données dans un langage de programmation existant. Cela ajoute des noms et des verbes à la langue de base, ce qui permet de dire plus facilement ce que l'on veut. (Remarque: je ne recherche pas qu'un DSL n'ait pas de courbe d'apprentissage. Il se peut que le lecteur d'un DSL doive investir le coût unique de son apprentissage.)
Le point important est: dans tous les cas, la DSL doit contenir les termes qui rendent l'expression de son modèle et les modifications du modèle commodes. Puisqu'il n'y a pas de limite évidente à la gamme de domaines possibles, aucun DSL unique ne peut les servir tous.
Mon impression d'UML est que c'est ce qu'il a essayé de faire.