Comments on: Bom senso minha gente…bom senso.

By: Marcelo C. Araujo

Marcelo C. Araujo — Thu, 16 Jul 2009 01:41:57 +0000

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.

By: Benhur

Benhur — Thu, 16 Jul 2009 00:59:02 +0000

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

By: Marcelo C. Araujo

Marcelo C. Araujo — Wed, 15 Jul 2009 23:25:26 +0000

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.

By: Benhur

Benhur — Wed, 15 Jul 2009 23:08:12 +0000

http://www.infoq.com/br/articles/API-Design-Joshua-Bloch

By: Marcelo C. Araujo

Marcelo C. Araujo — Wed, 15 Jul 2009 22:36:07 +0000

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.

By: benhur

benhur — Wed, 15 Jul 2009 17:05:31 +0000

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.”