Com que frequência você usa UML formal?

Eu usei o MUML ad-hoc (linguagem de modelagem inventada) para projetar e explicar o sistema com bastante frequência. Parece semelhante à UML e tende a ser bastante bem compreendido.

No entanto, tive um professor ou dois que insistiram no uso de UML formal e estrita, o mais próximo possível das especificações. Eu sempre suspeitei que a UML estrita não era tão comum quanto eles alegavam. Então, que tal - com que freqüência você realmente desenha diagramas completos que usam todas as terminações de linhas, multiplicidade, símbolos de tipo de membro, etc.?

Nunca.

Caramba, já faz anos desde a última vez que criei qualquer UML. Diagramas de linhas em quadros brancos e pedaços de papel não contam.

De fato, acabamos de remover a única pergunta UML do guia que usamos durante as entrevistas, porque nenhum de nós realmente se importava com as respostas.

Utilizo UML apenas o suficiente (tanto em termos de tipos de diagramas quanto do conteúdo das informações no diagrama) para mostrar meu ponto de vista e permitir que eu ou outra pessoa implemente o sistema ou subsistema. E a única razão pela qual uso a UML é porque é um conjunto de símbolos amplamente conhecido, que significa algo muito específico, portanto não há ambiguidade - qualquer engenheiro de software deve poder olhar o diagrama e entender o que estou tentando dizer sobre o sistema.

Ironicamente, a UML deve ser flexível.

No mundo real, não é suposto ser um exercício pedante em fazê-lo uma maneira certa. Trata-se de comunicar e documentar efetivamente um sistema / processo / idéia.

Para responder sua pergunta, eu estou com os outros. Nunca usei totalmente a UML formal e completa.

Eu usei a UML muito regularmente por cerca de quatro anos para um produto que gerou todos (a maioria) de seus esqueletos de código do Rational Rose.

Nos últimos cinco anos, houve mais "caixas e flechas" inventadas principalmente no local e geralmente o suficiente para transmitir a idéia geral. Corrija formalmente a UML apenas algumas vezes durante esse período.

No entanto, tive um professor ou dois que insistiram no uso de UML formal e estrita, o mais próximo possível das especificações.

Pergunte ao seu professor quando foi a última vez que ele usou essa abordagem em um sistema real. A sério.

Tento ser o mais formal possível quando se trata de UML, mas apenas se / quando fizer sentido. Os fanáticos dos dois lados do espectro (de cowboys a formalistas rígidos) não conseguem entender isso.

Existem contextos em que uma abordagem menos rígida (como a que você usa pessoalmente) é a melhor abordagem a seguir. Um bom exemplo é para pequenos sistemas ou alterações, onde os requisitos são pequenos e não estão totalmente definidos; o grupo responsável é eficiente e eficaz; é mais importante tirá-lo do que aperfeiçoá-lo. É feito iterativamente e algumas deficiências são aceitáveis.

Ou talvez você esteja em um estágio em que está fazendo guestimation e esboçando em oposição a uma fase de modelagem formal completa. Esses são exemplos que viriam à mente.

Em outros momentos, você precisa de uma abordagem UML formal rígida. Por exemplo, você pode estar contratualmente vinculado; você tem um número muito grande de desenvolvedores em várias equipes (possivelmente distribuídas); o escopo do projeto pode estar em anos; é um sistema muito grande (incluindo componentes de software e hardware); o custo da falha é alto etc.

Em outras ocasiões , é necessário usar outra coisa / além da UML (modelos matemáticos formais reais, como redes de pesca, CSP ou lógica temporal). Exemplo disso são sistemas em tempo real, sistemas em que as falhas são catastróficas (dispositivos médicos) ou onde você está contratualmente vinculado (ou seja, como na Europa ao desenvolver sistemas de transporte.)

Tudo depende das circunstâncias e do que esperamos obter de cada abordagem. Um professor que se preocupa com a formalidade está simplesmente sendo um fanático cego. O mundo da engenharia não é uma dicotomia em preto e branco, certo / errado. É um mundo de compensações inteligentes.

Se você é inteligente o suficiente para usar um modelo informal e informal de maneira eficaz e apropriada para realizar o trabalho, que assim seja. Da mesma forma, espera-se que você reconheça quando NÃO usar uma abordagem informal e / ou quando NÃO usar uma abordagem formal.

Dito isto, você deve tocá-lo com os professores. Dê a eles um osso para que eles lhe dêem uma nota e, se isso significa finalmente curvar-se ao mantra zelote, tudo bem. Você sabe o que funciona para você e, esperançosamente, saberá quando usar o que e como no mundo real.

Como parte de minha pesquisa de doutorado, estudei como designers experientes usam a UML em colaborações de design (embora em ambientes artificiais).

Minhas conclusões foram de que as metáforas e notações da UML são emprestadas, mas há pouca adesão ao rigor das ferramentas.

Posteriormente, alguns modelos podem ser transformados iterativamente em UML mais rigorosa, geralmente quando uma ferramenta CASE exigente está envolvida para fins de geração de código.

As advertências usuais da pesquisa acadêmica se aplicam, é claro :)

Um link para o resumo do artigo e o próprio artigo (se você não tiver acesso ao ACM) .

Além disso, recomendo a "Agile Modeling" de Ambler.

Usamos UML formal para geração de código de um ORM de hibernação. A maioria das outras coisas é informal ou quadro branco. É importante apenas para a geração de código, porque a falta de formalidade a quebraria.

Depende do setor em que você está. Se você trabalha para clientes que exigem análises técnicas frequentes (por exemplo, PDR, CDR etc.), eles preferem algum tipo de padronização em vez de sistemas notacionais ad-hoc. Em particular o trabalho do governo. Isso evita falhas de comunicação e a explicação inicial de 15 minutos da notação que você inventou.

Além disso, o fato de você estar usando UML não significa que você precisa pontilhar todos os i e cruzar todos os t de acordo com o padrão. Isso é apenas se você quiser fazer algum tipo de geração / execução automática de código. Não conheço ninguém que fez isso por mais de um projeto.

Por outro lado, se você está trabalhando apenas para sua empresa com uma equipe de seus próprios desenvolvedores, quem se importa com a notação que você usa. Embora, se você escolher a ferramenta certa, ela poderá economizar tempo real.

Com tudo isso dito, você encontrará dificuldades em alguns setores sem poder projetar usando UML. Em outros setores, você nunca verá isso.

Além disso, acho que você também encontrará uma correlação entre os setores que exigem que o design seja correto, porque os custos de correção são correspondentemente altos por serem usuários pesados ​​de UML; versus indústrias, que os custos das correções de design são pouco mais do que alterações na documentação / código, como locais em que a UML provavelmente nunca é usada.

Em relação à pergunta original. A maioria das faculdades costuma orientar o treinamento de seus alunos para as empresas que recrutam seus alunos com mais frequência. Se o seu professor achar que a UML é importante, não me surpreenderia que muitas empresas recrutadas em sua escola usem a UML. Assim, você deve aprender a usá-lo.

Quando li sobre a UML, tentei isso em todos os problemas que deveria resolver no meu curso de C ++. Felizmente, um dos primeiros exemplos que tentei foi descrever uma lista vinculada.
Não funcionou.
Dito isto, em conjunto com um bom processo de modelagem, a UML é útil. Só porque é para melhor ou para pior um padrão.
Gostaria muito de ver uma linguagem de descrição da meta-programação de modelos. Eu acho que isso ajudaria muito a entender o que está acontecendo em <<<>>> -land

A UML é dolorosa se você também tentar o desenvolvimento orientado a modelo. Quero dizer que UML é apenas uma notação gráfica muito útil e tudo o resto é inútil. Não gasto em modelagem, mas uso a UML todos os dias para criar a estrutura dos meus projetos. O que faço é desenhar rapidamente um diagrama básico de casos de uso nos níveis de exigência e mudar imediatamente para os diagramas de classes. Eu adiciono rastreabilidade de requisitos entre diagramas de casos de uso e de classe. Meu diagrama de classes também cria código porque é sincronizado ao vivo. Nenhuma tag no código todo o modelo é salva no modelo UML que é mapeado para o projeto Java.

Crio o esqueleto do meu aplicativo com poucos diagramas de classe e depois mudo para o código. Depois de terminar o código, mesclo-o com o modelo. É um tipo de iteração entre código e modelo em que o código executa o modelo. Portanto, meus diagramas de classes me proporcionam um nível mais alto de abstração e meu código, enquanto meu código me fornece minha implementação de lógica de negócios (por exemplo, métodos).

A modelagem UML requer menos de 10 minutos por dia, o que é feito quando preciso de tempo para pensar no que preciso desenvolver e como.

A UML é ótima, fantástica e realmente útil, mas o desenvolvimento orientado a modelo é inútil!

Se estou documentando um sistema que implementamos, tento defini-lo com UML formal e completa. Mas o resto do tempo, eu uso apenas o necessário para transmitir a ideia. Também me vejo usando mais DFDs que UML, pois eles parecem ser mais apropriados para os sistemas que estamos projetando ultimamente.

Acabei de sair da minha faculdade, supostamente de nível superior (pelo menos temporariamente) por causa de sua insistência rígida em atividades de modelagem visual excessivamente demoradas, tarefas do fórum, coisas de habilidades sociais excessivamente redundantes que qualquer pessoa que tenha crescido em torno de computadores ou tenha olhado pensativa em direção a uma interface de usuário ficaria bem o suficiente para que o pensamento de endividar-se profundamente fizesse com que alguém quisesse quebrar as coisas com total frustração.

Eu tive que escolher entre aprender o que eu via empregos iniciantes e de nível júnior e o que a CES define para o credenciamento ABET da universidade, o que faz com que os tomadores de decisão fiquem burros quando há problemas flagrantes com restrições de tempo e expectativas irreais que uma avaliação PERT revelaria. A universidade não pratica o que ensina.

Na minha opinião, o Processo Unificado tem muito mérito, mas toda a prática de cunhar artefatos visuais, seja qual for a linguagem de modelagem, é um pouco ridícula. Um documento refinado iterativamente contendo uma lista seriada, como pode ser produzido com Word, Workflowy, Evernote, OpenOffice ou nome de um processador de texto, é perfeitamente capaz de documentar o que é exigido pelo Processo Unificado. Algo que pode ser facilmente trabalhado por vários usuários, controlado por versão, e se alguém escolher a ferramenta certa para fazer isso, uma equipe poderá até trabalhar ao mesmo tempo. Isso é muito mais fácil do que quando a UML parecia um modo necessário de unir as hordas.