Il existe différentes façons d'utiliser UML. Martin Fowler appelle ces modes UML et en identifie quatre: UML comme notes , UML comme croquis , UML comme Blueprint et UML comme langage de programmation .
UML en tant que langage de programmation n'a jamais vraiment décollé. Il y a eu des travaux dans ce domaine sous différents noms, comme l' architecture pilotée par les modèles ou l'ingénierie logicielle basée sur les modèles. 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 long - 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 le signe d'un projet de "grande conception d'avance" . 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 d'entité-relation, aux diagrammes IDEF , à la notation de modélisation de 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 termes de modélisation agile , "documenter en continu" et maintenir une "source unique d'informations" .
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 en tant que conception , et il y a aussi des discussions sur le wiki C2, discutant des idées que le code source est la conception , la conception est le code source , et le code source et la 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.
Des 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 échangeant 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.