Por que o UML não é usado na maioria dos softwares livres (por exemplo, no Linux)?

Estou tentando entender por que a UML não é usada na maioria dos projetos de software livre . Por exemplo, meu sistema Debian / Linux provavelmente possui mais de dez mil pacotes de software livre, e não posso citar nem um que tenha sido desenvolvido usando estrutura e metodologia UML explícitas . Por exemplo, Qt , GCC , Linux kernel , bash , GNU make , Ocaml , Gnome , Unison , lighttpd , libonion , docker são projetos de software livre que (AFAIK) não mencionam UML.

^{(Meu palpite é que a UML é muito adequada para a subcontratação formal de tarefas de desenvolvimento, e não é assim que o software livre é desenvolvido)}

Observe que, embora tenha lido algum material sobre a UML, não pretendo ter uma boa compreensão dele.

Na verdade, não posso nomear facilmente um software livre em que a UML tenha sido usada (exceto talvez algumas ferramentas UML implementadas como software livre). Talvez o openstack seja uma exceção (algo que menciona UML).

^{(mesmo projetos antigos de software livre podem ter adotado a UML depois de iniciados, mas não o fizeram)}

Alguns colegas que trabalhavam na Papyrus mencionaram que a maioria dos projetos de software livre não possuía, no início, nenhum modelo formalizado explicitamente (e suficientemente profundo). Além disso, a UML parece muito mais relacionada ao Java do que afirma (não tenho muita certeza de que faria sentido para Ocaml ou Common Lisp ou Haskell ou Javascript, e talvez nem mesmo para C ++ 11 ....). Talvez o desenvolvimento ágil de software não seja muito amigável para UML.

Veja também esta resposta para uma pergunta de alguma forma relacionada. O blog de M.Fowler Is Design Dead? é perspicaz.

^{PS. Não acho que seja principalmente uma questão de opinião; deve haver algum motivo objetivo e alguma característica essencial do software livre, que explica o porquê. Costumo adivinhar que a UML é útil apenas para subcontratação formalizada e é útil apenas quando alguma parte do software desenvolvido está oculta, como em projetos proprietários. Se isso for verdade, a UML seria incompatível com o desenvolvimento de software livre.}

^{NB: Eu não sou fã de UML. Não defino UML apenas como documentação em papel, mas também como um [meta-] formato de dados para ferramentas de software}

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.

Vamos usar o Linux como exemplo,

• Não é um projeto orientado a objetos, algumas partes, como o VFS, podem ser modeladas em UML, mas outras não podem ser ou não muito eficazes, ou seja, basicamente, apenas uma tradução direta de structum diagrama de classes sem relacionamentos.
• A UML é boa para documentação, para que alguém novo em um projeto se atualize. Isso não é algo que realmente seja atendido pelo Linux, é esperado que as pessoas aprendam isso sozinhas.
• Não tendo certeza de qual ferramenta UML usar, as pessoas precisam concordar com algo para que ele seja mantido. Havia um aplicativo java gratuito para isso, mas acho que muitos não gostariam de usá-lo.
• Nos anos 90, a GUI ainda era um desafio para o Linux. Basta ir cavar o arquivo da lista de discussão, eu aposto que você não encontrará nenhum tipo de gráfico que não seja o logotipo do Linux em si no formato xpm a ser mostrado no momento da inicialização. Texto sem formatação é o formato preferido.
• Eu não acho que ninguém realmente se importa com design. As pessoas se preocupam com os recursos e, se forem aceitos, o código será examinado. Os casos de uso ainda são melhor descritos em palavras, assim como os padrões como POSIX e SUS são escritos.
• Muitos objetos no domínio dos sistemas operacionais são bem entendidos e padronizados na comunidade. Por exemplo, as pessoas saberiam como se struct in_addrparece na memória, nenhum diagrama poderia torná-lo mais claro.
• A UML não ajuda muito no algoritmo de modelagem, como o alocador de memória, o planejador, os manipuladores de interrupção etc. A fonte é provavelmente mais fácil de entender.

Essas são as coisas que consigo pensar nas configurações do projeto Linux. É mais uma questão de praticidade, eu acho. Curiosamente, não me lembro de que Tanenbaum tenha usado qualquer UML em seu livro de SO para descrever o Minix.

Provavelmente vale a pena mencionar, também não uso a UML no trabalho. Provavelmente 20% das pessoas com quem trabalho conhecem algum subconjunto da UML.

UML é uma representação, por isso é uma forma de linguagem e, por razões de argumento, vamos assumir que seu objetivo é comunicar um modelo mental de uma pessoa para outra.

O que procuro em um idioma é sua eficiência em capturar mudanças no modelo mental de alguém. Suponha que, depois de escrever a descrição do modelo, seja necessário fazer uma pequena alteração. Quão grande deve ser feita uma alteração na representação? Em uma linguagem textual, uma maneira de medir isso é executar um diffentre o código antes e depois e contar as diferenças. Em uma linguagem gráfica, deve haver uma maneira semelhante de medir a diferença.

IMHO, chamo uma linguagem de "domínio específico" (DSL) na medida em que minimiza a medida acima, o que tem benefícios óbvios na redução de custos e bugs de manutenção. Como fazer uma DSL? Existem várias maneiras. Um dos mais simples é apenas definir estruturas e métodos de dados em uma linguagem de programação existente. Isso adiciona substantivos e verbos ao idioma base, tornando mais fácil dizer o que se deseja. (Nota: não procuro uma DSL que não tenha curva de aprendizado. Pode ser que o leitor de uma DSL precise investir o custo único de aprendê-la.)

O ponto importante é: Em todos os casos, o DSL deve conter os termos que tornam a expressão do modelo e as alterações no modelo convenientes. Como não há um limite óbvio para o intervalo de domínios possíveis, nenhuma DSL pode servir a todos eles.

Minha impressão da UML é isso que ela tentou.