|
|
||
|
Navegação |
Enviado por raphael em qui, 10/02/2008 - 17:23.
Bem não sou completamente contra a UML, acho ate uma ferramenta bastante interessante para lhe mostrar seu sistema como um todo. Na minha opinião existe uma grande mania de cartório no Brasil, tudo tem que ser documentado, tudo com muita burocracia, sem falar na visão da indústria que existe o analista de sistemas todo poderoso e seus implementadores, que são responsáveis em pegar aquele diagrama e implementar todos os métodos ali definidos, mas desde quando a UML descreve mecanicamente como os métodos irão funcionar, até posso concordar que ela descreve os métodos, mas quem hoje programa sem os milhares do frameworks existentes EJB3, Hibernate, Castor, AOP, etc… a UML irá tratar tudo isto para você O grande ponto que quero chegar é analista de sistemas, não e analista de negócios, na minha cabeça nem existe esse tal analista de sistemas, o que seria este cara um programador que resolve negócios, o que tenho visto na maioria das empresas onde eu passo e um cara que levanta requisitos, fica hora e horas desenvolvendo um modelo do sistema, que em muito em breve não servirá mais para nada, e passa tudo para seus estagiários e programadores Junior resolver. Hoje visitei uma empresa, que já prestei consultoria em Java a algum tempo atrás eles estavam justamente discutindo isto em uma reunião, hora porque não conseguimos aproveitar os códigos em Java feitos no passado, se Java prover isto, hora justamente porque em nenhum momento tive um arquiteto de software para pensar como as coisas poderiam ser reaproveitadas, perdi horas e horas nos meus modelos que hoje são totalmente desatualizados mais nunca pensei em integrar, como reutilizar meu código, ai sempre escuto há mais não a tempo para pensar em tantas coisas, não da porque você está engessado em sua metodologia, por que documenta tanto que mal sobra tempo para implementação do produto, documente somente o necessário, as metodologias ágil estão ia para isto, comunicação e chave para tudo, na minha visão a UML e uma forma bacana de comunicação, mas ela não será implementada, e muito menos testada, se fosse não programaríamos em C#, Java, e sim em OCL.
|
Novos tópicos no fórum Posts recentes no blog Divulgar  |
Melhor analisarmos os casos...
Enviado por Francisco Rosa ... em sex, 10/10/2008 - 14:28.Bom dia, Raphael. Estava passando pelo seu blog e vi esta thread sobre UML. Discussão interessante.
Então, polemica esta história de documentar não documentar. Mas, uma coisa é certa não podemos ser pragmáticos e dizer que UML é uma coisa desnecessária. Assim, como Java, .NET, Jude, Hibernate... todas são ferramentas para se chegar a um objetivo único: Sistemas de qualidade.
Onde entendemos como sendo “Sistemas de qualidade”, aqueles que atendam os requisitos do cliente e além disso, os requisitos de negócio da empresa que está produzindo o sistema. Assim, como escolhemos Hibernate quando temos requisitos de produtividade e portabilidade entre SGBDs, a escolha de documentar envolve requisitos de compreensão do domínio do problema pela equipe durante o desenvolvimento e a flexibilidade de adaptações futuras seja no quadro de colaboradores ou em funcionalidades da aplicação.
Esta questão deve ser fundamentada também na política da empresa, como ela encara procedimentos. Onde trabalho, existem vários procedimentos, mas não são vistos por nós como processos documentados por serem bonitos assim, ao longo do nosso ganho de maturidade reconhecemos a necessidade de se terem guias para conduta durante o desenvolvimento dos projetos. Como isso é percebido? Como a maioria das coisas da vida, ou você segue orientações ou apanha. E com nós não foi diferente. Entendemos que um grande número de problemas durante desenvolvimento e no pós-desenvolvimento com a manutenção dos produtos são resolvidos com a descrição de procedimentos.
Você exemplificou empresas que documentam por documentar e que não se preocupam com outros itens como o de reutilização, que não possuem a figura do arquiteto para ponderar sobre tantos aspectos que poderiam dar ganho em produtividade. Ocorre que o uso de documentação e a existência de um arquiteto não são fatores que se excluem. Um processo pode muito bem ser definido para que o papel do arquiteto exista e que a documentação seja produzida e mantida.
“Mantida”, está é a resposta para o problema que você aponta com modelos desatualizados. Se não é política da empresa manter a atualização desses, realmente a única utilização deles será durante o desenvolvimento. Mas, então ocorre que o quadro de colaboradores foi reformulado ou que novas funcionalidades devem ser criadas e a rastreabilidade de impacto precisa ser pensada. Documento desatualizado é documento obsoleto. Entenda então que o problema não está na existência da documentação, mas sim na definição de quando deve ser aplicada e como será mantida.
Adeus UML ? ? ?
Enviado por lordjava em qui, 10/02/2008 - 18:10.Raphael, ja que você , comentou sobre metodologia ágil gostaria de esclarecer uma duvida: Test-Driven Development (TDD) pode substituir a UML ?
GO ! GO !! SCJD !!!
Nao vejo assim..
Enviado por raphael em qui, 10/02/2008 - 22:52.Cara ñ vejo TDD como uma linguagem de especificaçao do sistema, e sim como uma ferramenta de apoio para medir os impactos e aumento de qualidade no código, existe algumas pessoas que falam que TDD pode substituir, mas tipo vamos pensar na seguinte forma, nao vejo como desenvolver sistema sem vc criar um modelo, e acho a UML fantastica para isto, vc gera o modelo e tem uma discusao bacana com toda a equipe, acho que uma apoia a outra, o TDD e fantastico quando vc vai efetuar mudanças no sistema, com ele vc realmente sabe onde aquela mudança vai dar boro.
Vejo da seguinte forma, conheça tudo e utilize tudo que pode melhorar a qualidade de seu código, mas utilize somente o necessário, antes de utilizar qualquer recurso devemos pensar realmente preciso utilizar isto.