Outro dia fiz uma entrevista para um vaga bastante interessante para mim por alguns fatores, porém quando perguntaram de UML e tal, e quando naqueles testes vi que tinha bastante coisa de UML já me deu até um desânimo, vi que é uma empresa como tantas outras ai com o mesmo cascata de sempre, sendo que eu to com o saco cheio de cascata e estava (estou) buscando um local que utilize agilidade.
Pior que na entrevista eu dei até uma fritada de leve no cascata, não sei se isso pesou negativamente. As vezes os caras também pensam como eu mas o processo já é definido e não é fácil alterar, vai saber…
Bom sei que nessa altura vc deve estar se perguntando, mas o que raios tem a ver agilidade x cascata com UML, sendo essa diagramação útil (pelo menos era considerada) e meio que “oficializada” no mercado e independente da metodologia, mas sabemos que prática quem aplica é o pessoal que está no velho cascatinha de sempre e vejo muita contestação do pessoal da agilidade em relação a UML até mesmo pelo fato de terem abolido o up front design.
Enfim, queria saber se na sua opinião ainda é algo que deve ser estudado (ou pelo menos ter um livro ali na cabeceira do cara preocupado com um desenvolvimento correto e organizado) ou se já é mais uma bala de prata que caiu como tantas outras.
Eu acho que UML ainda é bem presente. Mas o importante é que ela tem que ser uma ferramenta de comunicação, não de documentação.
Primeiramente, na literatura. Muitos livros que explicam conceitos, como design patterns, usam UML. É uma notação simples, elegante e conveniente.
Se sua empresa tem o hábito de contratar equipes de desenvolvimento externas (como a minha tem) ou trabalha com equipes em outras filiais geograficamente separadas, conversar usando UML também é uma mão na roda. A especificação nesse caso ajuda muito na comunicação.
Só acho que a UML não serve para documentar o sistema todo. Alguns módulos de mais alto nível até podem ser diagramados, e algumas pessoas podem usar o diagrama provisoriamente para uma análise. Mas, o problema de ter uma documentação de todo sistema é justamente a tarefa hercúlea de manter todos os diagramas atualizados. Nesse caso, é melhor ir para a alternativa ágil, que tenta gerar esses diagramas automaticamente, quando necessário.
Um entrevistador pode te dar diagramas UML para ver se você entende padrões, se você consegue entender um cenário, mas isso não significa que o ciclo dele seja em cascata. Eu mesmo já apliquei provas com UML, e aqui usamos SCRUM no desenvolvimento. Aliás, nenhum processo de desenvolvimento sério, incluindo os menos iterativos como o RUP, se baseiam em ciclos em cascata.
Se a empresa realmente usa um ciclo waterfall, você fez bem em não ter entrado por lá.
O ViniGodoy foi perfeito em sua colocação. UML é muito presente e deve ser usado como ferramenta de comunicação.
Em relação ao modelo cascata, o fato de uma determinada empresa utilizar UML não quer dizer que ela utiliza o modelo cascata; é necessário avaliar como o processo de desenvolvimento da empresa funciona. No livro de XP do Vinicius Teles ele deixa bem claro que é comum empresas que utilizam metodologias ágeis utilizar notação UML para determinadas situações a qual facilita o entendimento dos casos de uso, atores, comunicação etc.
Sempre deve existir o mínimo de padrão possível para que não exista o caos dentro de uma empresa de desenvolvimento. Esse mínimo padrão possível precisa ser analisado a partir do tamanho da empresa, quantas equipes existem, qual o fluxo de comunicação, qual a metodologia de desenvolvimento utilizada etc.
Nunca se esquecendo que não existem balas de prata: a realidade da minha empresa pode ser completamente diferente da realidade da sua.
Sim eu me expressei mal, ainda tem muita gente que usa e vão continuar usando por muito tempo, isso é um fato. O que eu quis expressar como passado é como por exemplo o Cobol, também se usa bastante e vão continuar usando, porém é passado no sentido de não ser tecnologia contemporânea e empregada fortemente na industria atual.
No caso da UML é muito mais fácil perder esse vínculo do que no caso do Cobol, embora com isso eu não queria dizer que seria fácil haja visto que UML está disseminada no mercado.
Eu usei o termo bala de prata pela força com que a UML surgiu lá no começo do século e que perdurou até alguns anos atrás, quando o hype da agilidade começou a aparecer por aqui. É o comportamente típico, no começo todo mundo fala: “Ohhhhh, agora vai”. Depois começa os “veja bem”. Não estou falando com isso se a tecnologia é boa ou ruim, e sim que parece ter perdido um pouco a força e outrora já foi considerada a salvação dos processos de desenvolvimento.
Sim, eu sei que na teoria não é pq a empresa usa UML que é cascata, até coloquei ali no meu primeiro post, mas vamos ser pragmáticos, na prática é quase como se fosse. A coisa anda atrasada por aqui e se a empresa adota UML fortemente é alta a chance de utilizar o cascatão nojento e ineficaz.
De fato, ainda há lugares em que é possível ouvir o termo “Metodologia UML”, como se houvesse uma correspondência entre os vários tipos de diagramas da UML e o ciclo de vida do projeto (caso de uso -> sequencia -> diagrama de classe), o que definitivamente, não tem nada a ver. Porém, eu acho que o mercado está amadurecendo nesse sentido. As empresas tem cada vez mais adotado processos baseados na evolução do software, e não na evolução da documentação, e acho que nesse meio, as pessoas estão aprendendo quando vale a pena partir para os diagramas e quando não vale a pena.
Particularmente, eu acho que UML pode ajudar na hora de planejar uma entrega. Eu duvido muito que dá pra fazer um bom sistema simplesmente escrevendo estórias de usuário e logo em seguida começar a escrever testes unitários. Traduzir essas estórias em casos de uso, modelar alguns fluxos e algumas partes do domínio podem ajudar muito a definir uma arquitetura inicial e uma entrega 0.
Quando não precisarmos mais fazer MER pra modelar banco de dados ou modelar as classes antes de programar, o UML será ainda útil na engenharia reversa, ou até que alguém faça uma notação de modelo mais atual.
Se o próprio código for a documentação, e/ou os diagramas forem automaticamente gerados pelo código é óbvio que a UML é desnecessária, porém ela pode ser usada para a comunicação como o VinyGodoy explicou brilhantemente.
A linguagem e os diagramas são formas de nos comunicar, seja com nós mesmos ou com as máquinas
UML é definida como uma linguagem. Como qualquer linguagem, ela serve para comunicar. Entre usar um “template de documento em word” e usar UML, eu prefiro usar UML. Agora se as pessoas que vão trabalhar no projeto não entendem a UML como uma forma de comunicação, ai fica complicado. Um diagrama “bem escrito” pode informar muito mais que um monte de texto e blablablas.
A mesma historia de sempre: se não souber usar da forma correta, é melhor não usar.
Como a maioria das pessoas ainda pensam com zeros e uns, tendem a ir aos extremos: ou é agil com tudo de bom, ou então é ‘empresa waterfall tradicional’, sendo que UML não tem nada a ver.
Diversas vezes um diagrama de sequência me ajudou a entender melhor o fluxo de informação através de determinados sistemas e bancos de dados, facilitando o entendimento do caso de uso(ou estória de usuário).
UML, sabendo usar com destreza, nos mostra muitas funções do softwere em desenvolvimento, que de outra maneira só iriam aparecer no teste beta.
É o que penso.
fjfeitosa.