Marco Mendes´s Blog

A modelagem de casos de uso lida com a formalização, documentação e comunicação de partes dos requisitos funcionais de sistemas computacionais e de processos de negócio. Contrariamente ao senso comum, a escrita de um modelo de casos de uso não é uma tarefa trivial e requer muita atenção devido a detalhes que não são óbvios para o analista de requisitos iniciante.

Trabalho aqui um exemplo de como escrever e como não escrever casos de uso, composto de erros comuns a analistas iniciantes e um refinamento sucessivo para a correção destes erros e produção um descritivo maduro de casos de uso. O exemplo é composto de 7 passos, refinados incrementalmente em níveis crescentes de maturidade.

Escolhemos como exemplo um processo didático de saque de dinheiro em uma máquina 24 horas, chamada aqui de máquina ATM (Automatic Teller Machine). Neste processo de negócio, podemos identificar um caso de uso de sistemas chamado “Sacar Dinheiro”, ativado por um ator primário chamado Correntista.

A nossa primeira tentativa de descrever este caso de uso segue abaixo:

Caso de Uso - Sacar Dinheiro - Versão 1

Ator Primário: Correntista
Objetivo: Permitir ao correntista de um banco conveniado ao banco ATM realizar o saque de dinheiro em espécie.

Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O correntista insere a senha e o valor a ser retirado.
3. O correntista retira o dinheiro da máquina 24 horas.

Embora este processo atinja o fim esperado (dinheiro em espécie na mão do correntista), ele não descreve a interação entre o ator primário e o sistema sob desenho. O objetivo primário de um caso de uso é descrever a interação entre atores e o sistema sob desenho. Em uma metáfora com um jogo de ping-pong, a bola na versào 1 fica o tempo todo em um lado da mesa. Não existe conversação, não existe diálogo e portanto não existe captura dos processos de negócio que devem ser conduzidos pelo sistema.

A nossa segunda tentativa de descrever este caso de uso corrige este problema.

Caso de Uso - Sacar Dinheiro - Versão 2

…
Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação do cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema valida a senha e o saldo do correntista.
5. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
6. O correntista retira o dinheiro da máquina 24 horas.

A versão 2 é uma clara evolução. Existe um diálogo entre o ator e o sistema sob desenho. Alguns erros, entretanto, ainda persistem. Observemos, por exemplo, o passo (2). Como estamos projetando o sistema da máquina 24 horas, devemos nos lembrar que está fora do escopo (por pura impossibilidade) do nosso sistema realizar validações como por exemplo “Cartão Bloqueado ou Cancelado”. Isso é realizado pelo sistema do banco real (instituição de crédito), que se apresenta então como um ator secundário no contexto do nosso sistema. Isso seria identificado no mundo real através da definição da fronteira ou limite do nosso desenho. O erro aqui, portanto, foi ignorar a existência do ator secundário Banco Instituição de Crédito na descrição. Isso nos leva a terceira versão da nossa descrição.

Caso de Uso - Sacar Dinheiro - Versão 3

Ator Primário: Correntista
Ator Secundário: Instituição de Crédito
Objetivo: Permitir ao correntista de uma instituição de crédito conveniada ao banco ATM realizar o saque de dinheiro em espécie.

Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação física do cartão e solicita à Instituição de Crédito realizar a validação da expiração ou restrições associadas ao cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema solicita à Instituição de Crédito que valide a senha e o saldo do correntista.
5. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
6. O correntista retira o dinheiro da máquina 24 horas.

A terceira versão captura nos passos 2 e 6 as interações com atores secundários, ausentes na versão 2. Mais uma vez, entretanto, erros ainda existem na descrição. Um caso de uso deve capturar todos os processos de negócio realizados, sem no entanto entrar no mérito de como estes processos serão implementados. Em outras palavras, os casos de uso capturam as interações (O QUÊ), sem se preocupar com a implementação destas interações (COMO). Na versão 3, não capturamos processos básicos de um saque bancário, como por exemplo a validação da existência de dinheiro disponível na dispensadora de dinheiro, as restrições de saques diários, restrições de horários e o débito em conta corrente ao final da operação. Isso nos leva a uma quarta versão da nossa descrição.

Caso de Uso - Sacar Dinheiro - Versão 4

…
Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação física do cartão e solicita à Instituição de Crédito realizar a validação da expiração ou restrições associadas ao cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema solicita à Instituição de Crédito que valide a senha, o saldo do correntista e o limite diário de saque.
5. O sistema verifica a disponibilidade de dinheiro na máquina 24 horas, os limites diários de saque suportados e avalia as restrições de limite de saque em horários e dias especiais.
6. O sistema solicita à Instituição de Crédito que realize o débito do saque na conta corrente do Correntista.
7. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
8. O correntista retira o dinheiro da máquina 24 horas.

Embora esta versão 4 seja já razoável, muitos analistas de requisitos terminam o trabalho de escrita de casos de uso neste ponto. Estes analistas se esquecem que a ausência dos fluxos alternativos ou de exceção subestima a complexidades dos sistemas computacionais e gera desvios nos cronogramas de projeto. Portanto, é fundamental identificarmos os pontos de extensão deste fluxo. Não devemos, entretanto, realizar este processo verticalmente, mas primordialmente em amplitude para em um segundo momento realizarmos a escrita de cada ponto de extensão. Isso nos leva a versão 5, agora com os fluxos alternativos/exceção.

Caso de Uso - Sacar Dinheiro - Versão 5

…
Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação física do cartão e solicita à Instituição de Crédito realizar a validação da expiração ou restrições associadas ao cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema solicita à Instituição de Crédito que valide a senha, o saldo do correntista e o limite diário de saque.
5. O sistema verifica a disponibilidade de dinheiro na máquina 24 horas, os limites diários de saque suportados e avalia as restrições de limite de saque em horários e dias especiais.
6. O sistema solicita à Instituição de Crédito que realize o débito do saque na conta corrente do Correntista.
7. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
8. O correntista retira o dinheiro da máquina 24 horas.

Pontos de Extensão

Ativado do Passo 2 - Cartão Inválido
Ativado do Passo 2 - Cartão Bloqueado ou Expirado
Ativado do Passo 2 - Cartão Não Suportado pela Máquina 24 horas
Ativado do Passo 4 - Senha Inválida
Ativado do Passo 4 - Saldo Insuficiente
Ativado do Passo 4 - Limite Diário na Instituição de Crédito Ultrapassado
Ativado do Passo 5 - Limite de Saque do Banco 24 horas Ultrapassado
Ativado do Passo 5 - Limite de Saque no Horário Ultrapassado
Ativado em Qualquer Passo - Cancelamento da Operação pelo Correntista

Outros pontos de extensão podem existir, naturalmente. O exemplo procura mostrar o fato que um brainstorming destes fluxos alternativos deve ser feito para que estes pontos de extensão sejam capturados.

Dentro da evolução da descrição, devemos também realizar o detalhamento de cada ponto de extensão. Um exemplo para o fluxo Senha Inválida é colocado abaixo.

Caso de Uso - Sacar Dinheiro - Versão 6
…
Fluxo Alternativo - Senha Inválida
4a. Se o número de tentativas inválidas for igual a 1:
4a1. O sistema exibe a mensagem “Senha Inválida”.
4a2. O sistema retorna ao passo 3.

4b. Se o número de tentativas inválidas for igual a 2:
4b1 O sistema exibe a mensagem “Senha Inválida - O cartão será retido se três tentativas inválidas forem realizadas”.
4b2 O sistema retorna ao passo 3.

4c. Se o número de tentativas inválidas for igual a 3:
4c1. O sistema retém o cartão
4c2. O sistema exibe a mensagem “Senha Inválida - Cartão Retido. Procure a sua agência bancária para devolução do cartão”.
4c3 O sistema termina a operação.

Este trabalho, como citado, deve ser realizado para cada ponto de extensão da descrição do caso de uso.

Finalmente, devemos lembrar sempre que o modelo de caso de uso captura apenas interações entre os atores primários e o sistema sob desenho. Informações complementares como regras de negócio, interfaces gráficas, desenho detalhado ou persistência não são capturados na descrição. Estas informações podem (e devem complementar) a descrição de um caso de uso, sem entretanto interferir na legiblidade da leitura dos fluxos. A versão 7 (e última) deste artigo mostra como isso poderia ser realizado para regras de negócio simples do nosso exemplo de caso.

Caso de Uso - Sacar Dinheiro - Versão 7 (Final)
…
Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação física do cartão e solicita à Instituição de Crédito realizar a validação da expiração ou restrições associadas ao cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema solicita à Instituição de Crédito que valide a senha, o saldo do correntista e o limite diário de saque.
5. O sistema verifica a disponibilidade de dinheiro na máquina 24 horas, os limites diários de saque suportados e avalia as restrições de limite de saque em horários e dias especiais.
6. O sistema solicita à Instituição de Crédito que realize o débito do saque na conta corrente do Correntista.
7. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
8. O correntista retira o dinheiro da máquina 24 horas.

Pontos de Extensão

Fluxo Alternativo - Senha Inválida
4a. Se o número de tentativas inválidas for igual a 1:
4a1. O sistema exibe a mensagem “Senha Inválida”.
4a2. O sistema retorna ao passo 3.

4b. Se o número de tentativas inválidas for igual a 2:
4b1 O sistema exibe a mensagem “Senha Inválida - O cartão será retido se três tentativas inválidas forem realizadas”.
4b2 O sistema retorna ao passo 3.

4c. Se o número de tentativas inválidas for igual a 3:
4c1. O sistema retém o cartão
4c2. O sistema exibe a mensagem “Senha Inválida - Cartão Retido. Procure a sua agência bancária para devolução do cartão”.
4c3 O sistema termina a operação.

… Outros Pontos de Extensão

Regras de Negócio
…
RN006 - Se correntista não possui cheque especial, verificar se o saldo em conta corrente é maior que o valor a ser sacado.
RN007 - Se correntista possui cheque especial, verificar se o saldo em conta corrente é maior que o valor a ser sacado mais o valor do limite de crédito.

… Outras regras de negócio

O resumo deste pequeno artigo mostra ao leitor que o processo de escrita de casos de uso é complexo e cheio de nuances. Para os interessados, sugerimos o excelente “Escrevendo Casos de Uso - Allistair Cockburn”, que descreve em bastante profundidade como escrever e como não escrever casos de uso.

O arquiteto de software é ainda um papel recente na comunidade Brasileira de software. Por consequência, muita confusão ainda existe sobre o que este papel realiza dentro de um desenvolvimento de software. Diferentemente do senso comum, um arquiteto não é um desenvolvedor sênior que evoluiu em sua carreira. Um desenvolvedor é especialista e tático. Um arquiteto de software é um generalista em sua essência e primordialmente estratégico. Isso não significa, entretanto, que o arquiteto vive em uma torre de marfim, criando decisões desconectadas da realidade. Um arquiteto deve trabalhar em intensa e forte colaboração com a equipe, apoiando o time na investigação dos pontos de relevância técnica de um projeto. Um arquiteto deve atuar como um coach, realizando a identificação dos mecanismos arquiteturais relevantes, motivando o time para a investigação e resolução destes mecanismos e apoiando o time do início ao fim do projeto.

Um arquiteto deve possuir as seguintes características:

• Possuir liderança técnica
• Ser hábil negociador
• Possuir conhecimentos de desenho e programação
• Possuir Conhecimentos do domínio da aplicação
• Ser capaz de tomar decisões e conduzir times de projetos.

Um arquiteto de software deve conhecer também outras disciplinas (ex: Gerência de Projetos) ou domínios (Hardware, Dados ou Segurança), além da pura implementação J2EE ou .NET.

Para lidar com toda a complexidade de TI temos um outro papel, chamado de arquiteto de sistemas. Podemos definir os macro-conhecimentos técnicos de um arquiteto de sistemas nos seguintes domínios:

Arquiteto de Software - Apoio no desenvolvimento de softwares em tecnologias como J2EE, .NET ou CORBA. Um arquiteto de software é responsável pela arquitetura executável que suporte os requisitos não-funcionais de um sistema bem como os requisitos funcionais mais críticos.
Arquiteto de Hardware e Redes - Apoio na definição de topologias físicas de redes e máquinas, operação destas máquinas e manutenção de acordos de níveis de serviço - SLAs .
Arquiteto de Comunicação/Dados - Apoio nos processos de comunicação e troca de informações tais como EDI, EAI, B2C, B2B, SOA e ESB, entre outros padrões.
Arquiteto de Segurança - Apoio nos procesos de segurança, tais como autenticação, autorização, transporte, single sign-on, criptografia, entre outros.
Arquiteto de Processos - Apoio na definição e estruturação de processos de negócio em BPEL e na coreografia de processos de negócios em ambientes SOA/ESB.
Além disso, um arquiteto também deve possuir excelente capacidade de conduzir debates e realizar comparações entre as arquiteturas candidatas dos problemas do dia a dia. A paciência e a capacidade de apoiar os times de projetos também é muito bem-vinda dentro do perfil de um arquiteto, como ressaltado anteriormente.

Dada a dificuldade e grande desta tarefa, é muito comum que empresas formem o que chamamos de time de arquitetura, composta por um conjunto de pessoas com bom domínio de cada um dos itens acima e excelente capacidade de conduzir discussões e realizar apoio ao times de projetos.

O time de arquitetura ou arquiteto é peça fundamental para a garantia de sucesso de projetos, e tem como principais atividades:

• Identificação, análise, mitigação e contigência de riscos técnicos;
• Definição, coordenação e execução das estratégias técnicas do projetos;
• Treinamento e acompanhamento da equipe nos mecanismos arquiteturais definidos (ex: Políticas de Single Sign-On, Frameworks J2EE ou uso de protocolos como IIOP ou RMI);
• Garantia que projetos sejam repassados para operações sem maiores contratempos.
• Coletamos também um conjunto de artigos onde autores de renome descrevem o que é o arquiteto de software e o que não é o arquiteto de software.

Quem é o arquiteto de software?
http://www.bredemeyer.com/who.htm

Quem precisa de um arquiteto?
http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

O papel do arquiteto de software.
http://www-128.ibm.com/developerworks/rational/library/mar06/eeles/index.html

A arquitetura SOA (Service Oriented Architecture) é um paradigma de engenharia de software cujo objetivo primário é permitir a integração de aplicações de TI com maior flexibilidade e suportar a criação e operacionalização de novos processos de negócio com mais rapidez e eficiência. Em termos simples, SOA implica em quebrar a visão de sistemas monolíticos e de manutenção muito complexa e, então, criar uma nova visão fragmentada através da exposição de uma camada de serviços, usualmente baseados em WebServices.

Grupos de prospecção e avaliação de tendências, como o Gartner Group e o Evans Data Corp, colocam cenários bem otimistas para o SOA:

“2005 will be the year of the SOA. Mark it down. According to The Yankee Group, 75% of firms plan to invest in the technology and staffing to enable a service-oriented architecture (SOA). Gartner, 2004
“Gartner Inc.’s prediction that by 2008, 60% of enterprises will use SOA as their ‘guiding
principle’ when creating applications and processes”, Gartner, 2004.
“In a survey of more than 1000 European developers, Evans Data Corp. found that nearly
75% are currently developing or are planning to develop SOA in 2005″, Evans, Jan 2005
Do ponto de vista de negócio, os principais objetivos de SOA são:

Melhorar a eficiência dos processos de negócio já existentes. A necessidade de automatizar aplicações B2B e B2C é uma tendência forte para a consolidação de eco-sistemas empresariais. Toda empresa hoje que deseje montar cadeias de fornecedores com produtos entregues Just-In-Time necessita de uma coordenação precisa de informações e acesso real-time a serviços de terceiros e de seus clientes.
Suportar a criação de novos processos de negócio. A criação de novos processos de negócio (inovação de negócios) é um diferencial nas empresas hoje. As áreas de TI precisam prover mecanimos que permitam que novos processos sejam rapidamente construídos e distribuídos.
Suportar a integração de sistemas legados em arquiteturas de serviços. Cada onda de evolução tecnológica trouxe novos paradigmas e aplicações, como por exemplo Mainframes, aplicações cliente servidor, ERPs, aplicações Web, aplicações J2EE/.NET, entre outras. As empresas de TI precisam disponibilizar toda a inteligência de negócio destes passivos de uma forma simples e que permita novas evoluções com custo reduzido.
Em uma ótica técnica, SOA envolve a integração de sistemas em um barramento compartilhado (Enterprise Service Bus) e a exposição de cada componente destes sistemas através de uma camada de serviços expostas como WebServices. A partir destes serviços, novos processos de negócio podem ser montados (orquestrados e coreografados) em linguagens como BPEL (Business Process Execution Language) e executados em servidores de aplicação dedicados a este propósito.

Para informações sobre este complexo e vasto tema, recomendamos os sites abaixo que disponibilizam um amplo acervo sobre arquiteturas orientadas por serviço, incluindo vídeos, apresentações e documentos diversos.