Início > Agile, UERJ > UML como documentação?

UML como documentação?


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:, ,
  1. Paulo
    02/12/2009 às 12:45

    Texto interessante. Porém, com relação ao diagrama de classes da foto, a classes ADM, ALUNO, PROF, ETC… devem ser estados da classe USUARIO, caso contrário, não haverá a possibilidade de haver um cidadao ALUNO e PROF simultaneamente (se houver, serão registros duplicados e distindos).

  2. 02/12/2009 às 13:45

    Olá Paulo. Primeiramente, obrigado pelo comentário.

    O diagrama acima foi apenas um exemplo que peguei para ilustrar a questão das fotos. Especificamente, ele foi desenhado em conjunto com o cliente em um dos primeiros workshops de requisitos que fizemos neste projeto.

    Neste primeiro momento não estavamos nos preocupando com regras da UML, padrões de projeto, etc, mas simplesmente em nivelar o entendimento de todos e descoberta dos conceitos envolvidos (definição/descoberta da ubiquitous language).

    Na época, modelamos ADM, Aluno e Prof herdando de Usuario porque existiam estados e comportamentos relativos a Usuários (englobando todos) e estados e comportamentos específicos a ADM, Aluno e Prof, individualmente.

    Este modelo sofreu alterações antes de ser inserido no documento de visão (que falei no post). Quando codificamos, acabou ficando mesmo uma classe usuário com o estado indicando seu tipo.

    A[]´s
    Marcelo Zeferino

  3. Fábio
    03/02/2010 às 14:59

    Quando sua IDE tem algum plugin para UML em você modela, gera o código e faz engenharia reversa tudo são flores. O problema é quando você tem uma ferramenta de análise que não interage com a IDE. Em 99.9999% dos casos a UML acaba virando documentação desatualizada… Mas creio que ela é importante para dar uma visão geral do projeto, mesmo quando desatualizada.

    • 03/02/2010 às 15:23

      Pois é, para falar, acho que nunca são flores (ao menos para mim).

      Mas tenho usado o Jude há algum tempo para fazer algumas coisas e tenho tido facilidade. Claro que diagramas de sequência com engenharia reversa é quase impossível (só conheço o NetBeans que faz isso e está longe de ser legal ao ponto de valer o esforço, IMHO).

      Abraços.

  1. 21/02/2010 às 20:36
  2. 03/01/2011 às 14:57

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: