Você é chamado para fazer parte de um projeto que não vai necessariamente entregar um sistema classicão (do tipo com telinhas, usuários de carne e osso, etc). Sua função é criar uma interface java com um content management de mercado.
Ok.
Você então projeta sua solução com base em JUnit.
Testa a chamada a interface, verifica que está tudo ok e entrega o produto.
Pra não ficar só em código, você até documenta a interface gerada em uma espécie de contrato. Dizendo como ela deve ser chamada e o que se esperar dela e tal. Tudo bonitinho.
Ai alguém chega pra você e diz que sua entrega não está aderente a metodologia da casa.
Afinal, faltou criar o diagrama de caso de uso e seu respectivo documento word de descrição do mesmo.
Então você entrega o tal caso de uso e algumas semanas depois ele volta pra você num e-mail que diz: Seu caso de uso não está aderente as melhores práticas pregadas pela casa para o mesmo. O fluxo básico está usando de termos técnicos e não representa com clareza uma interação entre o ator e o sistema.
Agora me diga. Qual a utilidade de se fazer um caso de uso numa situação como essa? Onde seu trabalho se resume a produzir um serviço de comunicação com uma ferramenta, o qual será chamado por outros serviços?
Qual a utilidade de se engessar de tal forma a quantidade e qualidade da documentação que deve ser feita?
Não pegou a idéia ainda?
Imagine só. Alguém te convida pra ser padrinho de casamento. Um outro alguém te alerta que você deve ir de terno a um casamento. Gravata, sapato, tudo certinho.
Mas o casamento que te convidaram pra ser padrinho será na praia, ali na areia e tal. Sei lá, a noiva viu um assim numa revista e resolveu que o dela seria assim também!
E ai? Você vai aparecer por la de terno? Gravata no sol de meio dia? Sapato na areia?
Seu bom senso vai te dizer alguma coisa sobre isso, não?
July 15th, 2009 at 14:05
Burocracia sempre é problema, e pode desgastar um trabalho bem feito. No entanto, se você é obrigado usar UC, ele pode ser útil como ferramenta para projetar sua API, ajuda pensar, não como documentação. Afinal, como você disse o UC representa: “interação entre o ator e o sistema”. Como neste caso o domínio não é de negócio, interface java com um content management, o domínio também não será de negócio, mas ainda sim é muito útil esse método.
O Arquiteto Chefe de Java no Google e autor de Effective Java, Segunda Edição (Addison-Wesley, 2008), Joshua Bloch, disse: “Estruture os requisitos como casos de uso: eles são o padrão com o qual você vai comparar sua API.”
July 15th, 2009 at 19:36
O que eu não concordo é com um processo prescritivo que engesse o seu trabalho de modelagem (seja de documentos ou código). Cada projeto, cada requisito, tem suas características próprias. Acredito que artefatos são como ferramentas. Você utiliza aquelas que se mostram mais úteis para cada questão que se está tentando resolver.
O Scott Ambler, autor do livro “Modelagem Ágil” e defensor do “Processo Unificado”, o qual se baseia em UC, já dizia que é simplesmente uma questão de se perguntar: Por que estou criando esse artefato e pra quem o estou criando.
No caso descrito nesse post, optamos por escrever uma breve história definindo o requisito em questão e seus critérios de aceitação e posteriormente um contrato de serviço contendo suas capacidades, pré e pos condições. A história (um mero post-it numa parede) foi suficiente para focar a modelagem da solução e o contrato somado ao uso do JUnit foram suficientes para que pessoas não envolvidas com a criação desse serviço tivessem total entendimento sobre o seu propósito e pudessem avaliá-lo e cadastrá-lo no software de governança SOA que utilizam.
Descrever um caso de uso PARA o requisito que foi passado, não pareceu ser algo que agregaria valor a modelagem da solução e também não foi necessário para “passar adiante” o propósito do serviço.
July 15th, 2009 at 20:08
http://www.infoq.com/br/articles/API-Design-Joshua-Bloch
July 15th, 2009 at 20:25
Joshua Bloch: Notas sobre Design de APIs
“Estruture os requisitos como casos de uso: eles são o padrão com o qual você vai comparar sua API”.
Eu diria que é Um padrão, não O padrão
“Documentação importa. Não importa o quão boa é uma API, ela não será usada sem boa documentação. Documente todo elemento exportável da API: toda classe, metódo, campo e parâmetro.”
O tal contrato de serviço que utilizamos cumpri exatamente isso.
July 15th, 2009 at 21:59
Realmente, não é O padrão. Nenhuma técnica eh perfeita. Mais é fato que UC é uma abordagem muito útil para APIs, assim como DbC, melhor ainda em conjunto. No entanto, é necessário saber o retorno e como funciona para não usar como documentação, o Scott Ambler sabe bem disso. Se você não sabe onde o método pode ajudar, melhor não usar mesmo. []´s
July 15th, 2009 at 22:41
Já utilizei UCs para mapear requisitos e guiar a modelagem. Ainda tenho que fazer isso em alguns projetos. Não discordo do fato que UCs te ajudam a “pensar a solução”. Assim como você também não deve discordar de que essa não é a única abordagem comprovadamente eficiente. Podemos chegar a um resultado equivalente utilizando histórias/testes de aceitação. Ainda mais quando o requisito se mostra bem simples em termos de interação ator/sistema, como foi o caso descrito aqui.
Uma simples comunicação com a API de um gerenciador de conteúdo.