sábado, fevereiro 20, 2010

Template para Use Cases

Ha muito tempo fui projetista de sistemas. Porem, agora isso nao faco mais.

Hoje, quando olho para o M. sofrendo com codigos-fonte sem Javadoc, sem casos de uso definidos, sem "facades" representando os limites do sistema, com "actions" contendo regras de negocio e com "beans" incluindo validacoes e outras coisas, bem, fico muito P. da vida com a "desvirtuacao" do Scrum nos projetos, ou melhor dizendo COM A FALTA DE PROJETO DE SOFTWARE.

Atualmente, meu unico envolvimento com programacao propriamente dita eh na implementacao do meu "pluginzinho" Mizura, que eh um conector robusto para integrar coisas como o Enterprise Architect e o Atlassia Jira, fazendo com que as usecases dos projetistas sejam refletidas de forma transparente como issues na gerencia de projetos.

Bem, como estou praticamente sozinho (again!) em mais este movimento Open Source, estou usando o "estilo cowboy", progamando e criando a arquitetura e classes do projeto conforme as necessidades vao surgindo.

É o tipico Scrum, onde o Product Backlog aparece a cada novo Sprint :)

Ora, todavia surgem momentos em que as regras de negocio ficam complexas (mesmo) e, por isso, o velho e bom projeto de software volta a tona.

Assim, o Mizura tambem possui um projeto "pseudo detalhado" das coisas; ou, em outras palavras, um projeto de software quando as coisas ficam complicadas mesmo!

Uma das coisas (bem) complicadas no Mizura eh o processo de sincronizacao dos elementos (por exemplo, Usecases e Issues); justamnte o "core" do meu plugin.

Para tando, visto que tenho 17 opcoes de sincronizacao distribuidas em 3 formas de operacao, acredito piamente que preciso projetar bem esse aspecto.

Nesse contexto, alem de tentar usar a APIs como o  Google Collect para simplificar o processo, estou montando os casos de uso desses cenarios.

Mas pasmem, percebi que, embora eu tenha mais de 12 anos de experiencia nisso, e o 3PUP esteja em construcao, nao padronizei meus casos de uso ainda.

Seguindo as premissas do Alistair Cockburn e adequando as coisas para o ambiente tupiniquim de desenvolvimento, estou adotando o seguinte padrao de casos de uso:

Template para caso de uso

Objetivo:
Frase curta, resumindo a meta/o porque desse caso de uso existir

Ator principal, envolvidos e expectativas:
Lista numerada, que identifica o ator principal, seguido do seu objetivo com este caso de uso.

Pre-condicoes:
Lista numerada, que identifica todas as pre-condicoes necessarias para que este caso de uso possa ser realizado.

Eventos de disparo:
Lista numerada, que identifica todos os eventos que podem iniciar este caso de uso.

Fluxo principal:
Lista numerada, no formato ATOR ACAO OBJETO , mostrando a acao realizada no desenvolvimento do caso de uso.

Fluxos alternativos:
Lista numerada, a partir do ponto do fluxo principal, no formato ATOR ACAO OBJETO, mostrando a acao alternativa realizada no desenvolvimento do caso de uso. Caso nao existam, use o termo "1. Nada consta."

Pos-Condicoes:
Lista numerada, mostrando as condicoes esperadas do caso de uso. Sempre deve existir pelo menos uma pos-condicao, que é justamente o resultado principal (o objetivo) do caso de uso.

Em caso de excecoes:
Lista numerada, no formato , mostrando o que o ator envolvido deve fazer no cenario onde o caso de uso nao pode ser realizado (por exemplo, se o software der problemas, ocorrer falta de luz, queda de rede, etc.).Caso nao seja planejado, use o termo "1. Nada consta."

Exemplo de caso de uso

Como exemplo, mostro este do Mizura:

Caso de uso:
UC0019 - Usuario sincronizar elementos da origem para o destino

Objetivo:
Elementos do repositorio no lado direito (destino) serem sincronizados com informacoes contidas no repositorio do lado esquerdo (origem)

Ator principal, envolvidos e expectativas:
1. Usuario, ter as informacoes sincronizadas da origem para o destino.

Pre-condicoes:
1. Repositorios estarem disponiveis

Eventos de disparo:
1. Usuario solicitar sincronizacao dos elementos UML com issues

Fluxo principal:
1. O usuario indica o repositorio de origem a ser sincronizado
2. O usuario indica o repositorio de destino a ser sincronizado
3. O usuario invoca a sincronizacao "origem para destino" (left_to_right)
3. INCLUDE Usecase UC0020
4. Fim
Fluxo alternativo:
1. Nada consta

Pos-Condicoes:
1. Nada consta

Obviamente, cada caso é um caso (de uso, hehehe) e assim, meu template pode nao ser adequado para todas as situacoes.

Entretanto, este formato esta de acordo com o 3PUP e tambem segue as premissas da FDD, e vai permitir que eu possa estimar isso as "famosas" Feature Points (ou FEP), - semelhantes as Use Case Points (UUCP) -  que podem ser traduzidas em horas-homem e, finalmente, em R$.

Abraço a todos e mais um Redlabel (o quinto) nesta sexta feira a noite.