Arquivo

Posts Tagged ‘UML’

UML como documentação?

01/12/2009 6 comentários

Uma coisa que muitos acabam confundindo é a real função da Unified Modeling Language – UML: UML para documentação ou para entendimento de um problema?

O Craig Larman fala disso no livro “Utilizando UML e Padrões” e cita que diversas pessoas perdem muito tempo modelando com UML no sentido de documentar e atrasam a codificação. Quando vão ver, tudo aquilo que foi modelado em diversos diagramas “bonitos” e que demoram bastante tempo ($$$) para serem produzidos não são soluções que poderiam ser implementadas na realidade.

UML é para modelagem, visando que as pessoas entendam o problema e a solução proposta. Uma vez que a informação foi passada, se quiser registrar o que foi desenhado, tire uma foto e guarde. Pronto!

Exemplo de modelo criado durante reunião com cliente

O Vinicus Teles, no seu livro sobre XP, fala, inclusive, que em sua experiência dificilmente precisou dessas fotos.

Em alguns casos, os modelos são realmente importantes e precisam ser registrados (como modelos de domínio e diagramas de atividade modelando o fluxo do processo, por exemplo). Nestes casos, após modelar, transfira para uma ferramenta case e deixe arquivado (o modelo acima, por exemplo, foi inserido em um documento de visão, criado no início do projeto).

Mas é bom lembrar que de nada adianta se este modelo não for atualizado ao longo do tempo. Documentação desatualizada é pior que não ter documentação!

Agile utiliza UML?

Métodos ágeis podem, sim, utilizar UML. Eu inclusive utilizo bastante, porém temos que ter em mente que o que é importante é saber bastante sobre análise e projeto orientado a objetos, padrões, modelagem e não apenas saber UML.

Os métodos ágeis usam esse tipo de modelagem (visando entendimento de um problema e criação da solução), seja com UML ou o quer que seja. Uma boa referência são os artigos do Scott Ambler (em Agile Modeling) sobre o assunto.

Modele para entender, em um quadro branco, em grupo (e junto com o cliente quando quiser descobrir os conceitos do negócio e modelá-los no sistema), tire foto ou deixe isso fixado na parede da sala de projeto e corra para desenvolver o que modelou, pois é isso que vai dizer se o que desenhou está correto…

Com relação a o que é feito antes de por o software para rodar, devo dizer que não acredito nessa idéia de esperar até que todo o software esteja pronto e documentado com belos diagramas para aí sim validar e colocar em produção! Métodos ágeis trabalham com iterações e o software vai sendo produzido aos poucos (incrementalmente) e a cada novo incremento, temos uma versão funcional do software que já pode ser colocada em produção, gerando valor para o cliente.

Uma grande fase de design ou de modelagem no início, o famoso Big Design Up Front (BDUF) ou Big Modeling Up Front (BMUF), retardando o desenvolvimento, não vai garantir qualidade ao seu projeto do ponto de vista do design. Para isso, existem diversas práticas que podem ser utilizadas durante o processo de desenvolvimento, como programação em par, TDD, etc…

Bom, IMHO, é isso…

PS.: Após escrever e publicar este post, cheguei a esse vídeo do Vinicius: http://vimeo.com/1450383. Sem tirar nenhuma vírgula, é isso!

Tags:, ,