Existem diferentes maneiras de usar a UML. Martin Fowler chama esses modos UML e identifica quatro: UML como Notes , UML como Sketch , UML como Blueprint e UML como uma linguagem de programação .
A UML como linguagem de programação nunca decolou. Houve algum trabalho nesta área com nomes diferentes, como Arquitetura Orientada a Modelo ou Engenharia de Software Baseada em Modelo. Nesta abordagem, você cria modelos altamente detalhados do seu sistema de software e gera o código a partir desses modelos. Pode haver alguns casos de uso em que essa abordagem é útil, mas não para software geral e, especialmente, não fora das grandes empresas que podem pagar as ferramentas que impulsionam essa abordagem. Também é um processo demorado - posso digitar o código de uma classe mais rapidamente do que criar todos os modelos gráficos necessários para implementá-lo.
UML como Blueprint é frequentemente indicativa de um projeto de "grande design inicial" . Não precisa ser, é claro. O modelo também pode ser totalmente descrito para um incremento específico. Mas a ideia é que o tempo seja gasto na criação de um design na forma de modelos UML que são então entregues a alguém para conversão em código. Todos os detalhes estão detalhados e a conversão em código tende a ser mais mecânica.
UML como Sketch e UML como Notes são de natureza semelhante, mas diferem com base em quando são usadas. Usar UML como esboço significa que você esboçará projetos usando notações UML, mas é provável que os diagramas não estejam completos, mas se concentrará em aspectos específicos do design que você precisa para se comunicar com outras pessoas. UML como Notes é semelhante, mas os modelos são criados após o código para ajudar no entendimento da base de código.
Quando você está considerando isso, acho que tudo acima é verdadeiro para qualquer tipo de notação de modelagem. Você pode aplicá-lo a diagramas de relacionamento entre entidades, diagramas IDEF , notação de modelagem de processos de negócios e assim por diante. Independentemente da notação de modelagem, você pode escolher quando aplicá-la (antes como uma especificação, depois como uma representação alternativa) e quantos detalhes (detalhes completos para os principais aspectos).
O outro lado disso é a cultura de código aberto.
Freqüentemente, projetos de código aberto começam a resolver um problema que um indivíduo (ou hoje uma empresa) está enfrentando. Se estiver sendo lançado por um indivíduo, o número de desenvolvedores será 1. Nesse caso, a sobrecarga de comunicação é extremamente baixa e há pouca necessidade de se comunicar sobre os requisitos e o design. Em uma empresa, é provável que haja uma equipe pequena. Nesse caso, você provavelmente precisará comunicar possibilidades de design e discutir trade-offs. No entanto, depois de tomar suas decisões de design, você precisa manter seus modelos à medida que sua base de códigos muda com o tempo ou jogá-los fora. Nos termos da modelagem ágil , "documente continuamente" e mantenha uma "única fonte de informações" .
Como um resumo, há a ideia de que o código é design e que os modelos são apenas visualizações alternativas do design. Jack Reeves escreveu três ensaios sobre código como design , e também há discussões no wiki C2, discutindo as idéias de que o código-fonte é o design , o design é o código-fonte , o código - fonte e a modelagem . Se você concorda com essa crença (o que eu faço), o código-fonte é a realidade e quaisquer diagramas devem existir para facilitar a compreensão do código e, mais importante, a lógica por que o código é o que é.
Um projeto de código aberto bem-sucedido, como os que você mencionou, tem colaboradores em todo o mundo. Esses colaboradores tendem a ser tecnicamente competentes nas tecnologias que alimentam o software e provavelmente também são usuários do software. Os colaboradores são pessoas que podem ler o código-fonte com a mesma facilidade que os modelos e podem usar ferramentas (IDEs e ferramentas de engenharia reversa) para entender o código (incluindo a geração de modelos, se achar necessário). Eles também podem criar esboços do fluxo por conta própria.
Dos quatro modos descritos por Fowler, acho que você não encontrará um projeto de código aberto, ou muitos projetos em qualquer lugar, que usem linguagens de modelagem como linguagens de programação ou blueprints. Isso deixa notas e esboços como possíveis usos para UML. As anotações seriam criadas pelo colaborador para o colaborador, portanto você provavelmente não as encontraria carregadas em nenhum lugar. Os esboços diminuem de valor à medida que o código se torna mais completo e provavelmente não seria mantido, pois isso exigiria apenas esforço dos contribuidores.
Muitos projetos de código aberto não têm modelos disponíveis porque não agregam valor. No entanto, isso não significa que os modelos não foram criados por alguém no início do projeto ou que os indivíduos não criaram seus próprios modelos do sistema. É apenas mais eficiente manter uma fonte de informações de design: o código fonte.
Se você quiser encontrar pessoas trocando informações de design, recomendo procurar em qualquer tipo de fórum ou lista de discussão usada pelos colaboradores. Freqüentemente, esses fóruns e listas de discussão servem como documentação de design para projetos. Você pode não encontrar UML formal, mas pode encontrar algum tipo de representação gráfica de informações e modelos de design. Você também pode entrar em salas de bate-papo ou outros canais de comunicação do projeto - se você vir pessoas falando sobre decisões de design, elas podem estar se comunicando com os modelos gráficos. Mas eles provavelmente não se tornarão parte de um repositório, pois não são valiosos, uma vez que cumpriram seu objetivo na comunicação.