Comentários em: O Anti-Pattern “Caso de Uso – UML – Codificação – Teste” http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/ O blog da ASPERCOM Treinamentos www.aspercom.com.br Sun, 14 Mar 2010 13:54:53 +0000 http://wordpress.org/?v=2.0.10 por: Rodrigo Yoshima http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/#comment-6736 Thu, 20 Aug 2009 16:50:19 +0000 http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/#comment-6736 Sim! A grande maioria dos projetos que desenvolvo uso a UML. Mesmo que seja o UMLasSketch do Fowler (rascunhando com UML). Casos de Uso não aplico em todas as aplicações. Uso mais para algumas funcionalidades que muitas vezes não estão claras nem para o usuário. Mas a grande verdade é que faz um bom tempo que não mantenho muitos artefatos UML em minha configuração. Sim! A grande maioria dos projetos que desenvolvo uso a UML. Mesmo que seja o UMLasSketch do Fowler (rascunhando com UML).

Casos de Uso não aplico em todas as aplicações. Uso mais para algumas funcionalidades que muitas vezes não estão claras nem para o usuário.

Mas a grande verdade é que faz um bom tempo que não mantenho muitos artefatos UML em minha configuração.

]]> por: Guilherme http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/#comment-6697 Tue, 18 Aug 2009 15:02:37 +0000 http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/#comment-6697 Ola rodrigo, gostaria de saber se você usa UML, Caso de Uso ? Você disse “Se a funcionalidade é simples e a expectativa do usuário está clara, documentos de Casos de Uso e modelos UML podem ser descartados.” e concordo com você. beleza, mas em casos complexos vc usa? Obrigado! Ola rodrigo,
gostaria de saber se você usa UML, Caso de Uso ?
Você disse “Se a funcionalidade é simples e a expectativa do usuário está clara, documentos de Casos de Uso e modelos UML podem ser descartados.” e concordo com você. beleza, mas em casos complexos vc usa?

Obrigado!

]]> por: Iterações pra que te quero! at Mergulhando no Caos http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/#comment-1005 Fri, 03 Oct 2008 00:41:52 +0000 http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/#comment-1005 [...] Bom, na verdade não. Como podemos observar a partir de alguns relatos bem recentes, desenvolvimento de software em cascata ainda é realidade em muitos lugares. Pode parecer uma realidade bem distante para você, mas é algo bem próximo para essas pessoas. Tão próximo e tão incômodo que elas tomaram o tempo de sentar-se e escrever sobre o assunto. O pessoal do 1up4Developers até dedicou um site inteiro a isso. Eles deviam estar verdadeiramente sofrendo quando começaram isso. [...] […] Bom, na verdade não. Como podemos observar a partir de alguns relatos bem recentes, desenvolvimento de software em cascata ainda é realidade em muitos lugares. Pode parecer uma realidade bem distante para você, mas é algo bem próximo para essas pessoas. Tão próximo e tão incômodo que elas tomaram o tempo de sentar-se e escrever sobre o assunto. O pessoal do 1up4Developers até dedicou um site inteiro a isso. Eles deviam estar verdadeiramente sofrendo quando começaram isso. […]

]]> por: Walter http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/#comment-428 Tue, 19 Aug 2008 11:01:31 +0000 http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/#comment-428 Entedi a visão e concordo. Coisas como CRUD, e outras na qual se possa criar um padrão bem definido para o sistema inteiro, não merecem mais do que uma modelagem e/ou descrição genérica. Sds, Entedi a visão e concordo. Coisas como CRUD, e outras na qual se possa criar um padrão bem definido para o sistema inteiro, não merecem mais do que uma modelagem e/ou descrição genérica.
Sds,

]]> por: Rodrigo Yoshima http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/#comment-409 Mon, 18 Aug 2008 12:40:08 +0000 http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/#comment-409 Fala Walter, bom, creio que qualquer sistema tem funcionalidades simples como relatórios básicos, cadastros básicos (os famosos CRUDS) e etc... Já parou para pensar que os casos de uso CRUD que escrevem por aí são muito semelhantes entre sí? Pra quê essa ambiquidade? Geralmente algumas funcionalidades simples que não representam muita importância para os usuários são aqueles cuja expectativa está clara. Imagine um sistema de vendas. Existe "Emitir Pedido" que é um caso de uso que concentra 80% da complexidade do sistema onde a expectativa é alta. Ee existe o "Cadastro de Tipo de Cliente", um CRUD idiota. É aquele tipo de caso de uso que os usuários não tem expectativa. OK? Fala Walter, bom, creio que qualquer sistema tem funcionalidades simples como relatórios básicos, cadastros básicos (os famosos CRUDS) e etc… Já parou para pensar que os casos de uso CRUD que escrevem por aí são muito semelhantes entre sí? Pra quê essa ambiquidade?

Geralmente algumas funcionalidades simples que não representam muita importância para os usuários são aqueles cuja expectativa está clara. Imagine um sistema de vendas. Existe “Emitir Pedido” que é um caso de uso que concentra 80% da complexidade do sistema onde a expectativa é alta. Ee existe o “Cadastro de Tipo de Cliente”, um CRUD idiota. É aquele tipo de caso de uso que os usuários não tem expectativa.

OK?

]]> por: Walter http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/#comment-401 Sun, 17 Aug 2008 11:50:13 +0000 http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/#comment-401 Olá Rodrigo, a respeito do trecho: "Se a funcionalidade é simples e a expectativa do usuário está clara, documentos de Casos de Uso e modelos UML podem ser descartados." como você define que a funcionalidade é simples e a expectativa está clara ? Obrigado, Walter Olá Rodrigo,
a respeito do trecho:

“Se a funcionalidade é simples e a expectativa do usuário está clara, documentos de Casos de Uso e modelos UML podem ser descartados.”

como você define que a funcionalidade é simples e a expectativa está clara ?

Obrigado,

Walter

]]> por: Débito Técnico » Blog Archive » O ciclo ágil de um dia… MundoJava no. 29 http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/#comment-95 Mon, 23 Jun 2008 12:51:11 +0000 http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/#comment-95 [...] Um pouco atrasado mas vamos lá. Na edição “atual” da MundoJava (maio-junho) escreví sobre o ciclo ágil de um dia envolvendo as práticas do XP e da TDD. Parte deste artigo já está publicado aqui no blog no post “O Anti-Pattern Caso de Uso – UML – Codificação – Teste”. [...] […] Um pouco atrasado mas vamos lá. Na edição “atual” da MundoJava (maio-junho) escreví sobre o ciclo ágil de um dia envolvendo as práticas do XP e da TDD. Parte deste artigo já está publicado aqui no blog no post “O Anti-Pattern Caso de Uso – UML – Codificação – Teste”. […]

]]> por: Alexandre Reis http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/#comment-74 Thu, 29 May 2008 18:17:19 +0000 http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/#comment-74 Grande Rodrigo, Apesar de não estar 100% familizarizado (ou convencido) das práticas do Scrum, sou um adepto convicto da Agilidade e de XP. Poucas vezes na minha vida profissional encontrei alguém que compartilha a minha prática de falar sem meias palavras e sem medo coisas que são consideradas "senso comum". Também poucas vezes encontrei alguém que escreve tão bem. Adorei o blog, adicionei ao meu leitor de feeds e te linkei no meu blog. Assino em baixo de cada palavra tua nesse post, inclusive na resposta dos comentários e devaneios. Um abraço, Alex Grande Rodrigo,

Apesar de não estar 100% familizarizado (ou convencido) das práticas do Scrum, sou um adepto convicto da Agilidade e de XP.

Poucas vezes na minha vida profissional encontrei alguém que compartilha a minha prática de falar sem meias palavras e sem medo coisas que são consideradas “senso comum”.

Também poucas vezes encontrei alguém que escreve tão bem. Adorei o blog, adicionei ao meu leitor de feeds e te linkei no meu blog.

Assino em baixo de cada palavra tua nesse post, inclusive na resposta dos comentários e devaneios.

Um abraço,

Alex

]]> por: Rodrigo Yoshima http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/#comment-36 Wed, 07 May 2008 00:28:19 +0000 http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/#comment-36 <p>Raphael... é um anti-pattern sim. Nenhuma metodologia defende o uso de um mesmo padrão para o desenvolvimento de todas as funcionalidades.</p> <br> <p>O que você quer dizer com projetos corporativos? Todos os projetos são corporativos. Se eu escrevo uma classe de teste ou um teste de aceitação isso é documentar requisitos. Se eu desenho rascunhando um protótipo de tela em papel A4 junto com o cliente isso é um documento de requisitos. Se ele fez isso junto comigo não precisa de aprovação.</p> <br> <p>Nenhuma metodologia de desenvolvimento prega "validação de requisitos". O que existe são validações de requisitos através de software funcionando. Software funcionando é o melhor artefato para levantamento e validação de requisitos.</p> <br> <p>Não vejo a alteração de requisitos como essa mudança cataclísmica que você falou. Equipes ágeis não temem mudanças (veja o princípio da coragem do XP). E além disso, não vejo aonde a UML vai ajudar muito nessa análise que você falou. Talvez uma boa suite de testes seja mil vezes melhor para detectar quebras no código do que um modelo UML. Avaliar impacto pode levar ao "Change Prevention Anti-Pattern".</p> <br> <p>Equipes ágeis criam testes para documentar requisitos. Testes são documentos de requisitos. Isso não é criar testes sem propósitos. Existe ambiquidade entre requisitos e testes. Se você têm os testes não precisa ter os documentos de requisitos. </p> Raphael… é um anti-pattern sim. Nenhuma metodologia defende o uso de um mesmo padrão para o desenvolvimento de todas as funcionalidades.

O que você quer dizer com projetos corporativos? Todos os projetos são corporativos. Se eu escrevo uma classe de teste ou um teste de aceitação isso é documentar requisitos. Se eu desenho rascunhando um protótipo de tela em papel A4 junto com o cliente isso é um documento de requisitos. Se ele fez isso junto comigo não precisa de aprovação.

Nenhuma metodologia de desenvolvimento prega “validação de requisitos”. O que existe são validações de requisitos através de software funcionando. Software funcionando é o melhor artefato para levantamento e validação de requisitos.

Não vejo a alteração de requisitos como essa mudança cataclísmica que você falou. Equipes ágeis não temem mudanças (veja o princípio da coragem do XP). E além disso, não vejo aonde a UML vai ajudar muito nessa análise que você falou. Talvez uma boa suite de testes seja mil vezes melhor para detectar quebras no código do que um modelo UML. Avaliar impacto pode levar ao “Change Prevention Anti-Pattern”.

Equipes ágeis criam testes para documentar requisitos. Testes são documentos de requisitos. Isso não é criar testes sem propósitos. Existe ambiquidade entre requisitos e testes. Se você têm os testes não precisa ter os documentos de requisitos.

]]> por: Raphael http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/#comment-34 Tue, 06 May 2008 17:41:15 +0000 http://blog.aspercom.com.br/2008/04/16/o-anti-pattern-caso-de-uso-uml-codificacao-teste/#comment-34 Acredito que o problema não seja do modelo “Casos de Uso + UML + Código + Testes” e sim da falta de comunicação. Acredito que obrigatoriamente em projetos corporativos que os requisitos devam estar documentados e preferencialmente validados pelo usuário, seja em Casos de uso ou qualquer outro documento. Uma vez capturado um requisito, e somente quando este for identificado, é importante analisar o impacto no projeto e na arquitetura do software, vejo a UML com uma boa linguagem para comunicar e permitir a avaliação de incrementos nos requisitos / funcionalidades. Quando entendida a necessidade e a modificação necessária para aquele projeto ai sim, podemos desenvolver e testar ou vice versa, criar os testes e desenvolver, vai da cultura. Lógico, não estou falando de requisitos como logos, posição de elementos na tela ou coisas deste tipo, mas sim de regras de negócio, restrições de segurança ou funcionalidade, que potencialmente impactam no modelo. Mesmo no processo ágil com micro interações, voce deve avaliar o requisito, como irá faze-lo, testar e executar (ou executar e testar), este micro "waterfall" é necessário, não faz sentido pensar em como atender um requisito se o mesmo não existe ou criar testes sem propósito. Att, Raphael Acredito que o problema não seja do modelo “Casos de Uso + UML + Código + Testes” e sim da falta de comunicação. Acredito que obrigatoriamente em projetos corporativos que os requisitos devam estar documentados e preferencialmente validados pelo usuário, seja em Casos de uso ou qualquer outro documento. Uma vez capturado um requisito, e somente quando este for identificado, é importante analisar o impacto no projeto e na arquitetura do software, vejo a UML com uma boa linguagem para comunicar e permitir a avaliação de incrementos nos requisitos / funcionalidades. Quando entendida a necessidade e a modificação necessária para aquele projeto ai sim, podemos desenvolver e testar ou vice versa, criar os testes e desenvolver, vai da cultura. Lógico, não estou falando de requisitos como logos, posição de elementos na tela ou coisas deste tipo, mas sim de regras de negócio, restrições de segurança ou funcionalidade, que potencialmente impactam no modelo.
Mesmo no processo ágil com micro interações, voce deve avaliar o requisito, como irá faze-lo, testar e executar (ou executar e testar), este micro “waterfall” é necessário, não faz sentido pensar em como atender um requisito se o mesmo não existe ou criar testes sem propósito.

Att,
Raphael

]]>