Olá prezado Leitor.

Depois de um bom recesso de Carnaval, vamos continuar falando de UML. No artigo da semana passada foi falado um pouco da história e utilização da UML. Também apresentei alguns conceitos importantes. O objetivo deste segundo artigo é falar sobre diagrama use case e a importância de um bom levantamento de dados.


Lembrando o conceito de cenário
Cenário é uma seqüência de passos que descreve uma interação entre um usuário e um sistema” No artigo da semana passada apresentei o seguinte cenário:

Fazendo macarrão
O cozinheiro procura o pacote de macarrão no armário, procura uma panela, enche a panela com água, coloca a quantidade necessária de macarrão na panela, acende a “boca” do fogão, deixa ferver por alguns minutos, após o término procura o escorredor de macarrão, coloca o macarrão para escorrer.
O cenário acima possui erros de processos. Para facilitar o entendimento, os erros estão em negrito.

O processo correto é: ..., acende a “boca” do fogão, deixar ferver, colocar a quantidade necessária de macarrão.
Meu objetivo é mostrar a vocês a importância de um bom levantamento de dados. Faz-se necessário validar os processos com especialistas de negócios, após o processo de entrevistas. Imagine se o analista de sistemas encaminhasse para o desenvolvimento a tarefa “Fazendo macarrão”. O resultado seria desastroso.

Vale a pena dizer que, o modelo pode estar correto dentro dos padrões da UML, mas não irá atender as especificações do cliente. Tão importante quanto conhecer modelagem orientada a objetos é conhecer o processo e necessidade de seu cliente.

Criando um use case
Uma prática comum entre os analistas é descrever um cenário principal como sendo uma seqüência de passos numerados e as alternativas como variações naquela seqüência. Veja o exemplo abaixo.

Cenário Principal: Fazendo Macarrão
1) Procurar pacote de macarrão no armário
2) Procurar uma panela
3) Colocar água na panela
4) Acender a “boca” do fogão
5) Ferver a água
6) Colocar o macarrão na panela com água fervente
7) Procurar um escorredor de macarrão
8) Colocar o macarrão para escorrer

Alternativa 1: Não encontrar macarrão.
No item 1, o cozinheiro não encontra o pacote de macarrão.
1.1) Cozinheiro solicita ao ajudante de cozinha a compra do macarrão

Alternativa 2: Não conseguir acender o fogão.
No item 4, o cozinheiro não consegue acender o fogão.
4.1) Cozinheiro testa outras “bocas” do fogão.
4.2) Não existe gás, cozinheiro cancela pedido.


Conceitos
Ator: É um papel que um usuário desempenha em relação ao sistema. Um ator pode desempenhar vários casos de uso; um caso de uso pode ter vários atores. Os atores não precisam ser humanos, o ator pode ser um sistema externo que necessita de alguma informação do sistema atual.

Associação entre Casos de Uso: Além das associações entre atores e casos de uso, você pode ilustrar vários tipos de associações entre casos de uso. Destacam-se três tipos de associações, que são:

• Inclusão (USES) – Ocorre quando há uma parte do comportamento que é semelhante em mais de um caso de uso. Ou seja, quando um caso de uso, “usa” o outro. Não pode ser usado se apenas um outro caso de uso o dispara. Nem justifica o uso para modelar seqüência.
  
• Generalização – Quando tem um que é semelhante a outro, mas faz um pouco mais.
  
• Extensão (EXTENDS) – Quando você estiver descrevendo uma variação em comportamento normal. Ou seja, um caso de uso, “estende” o outro, quando o segundo acrescenta novos comportamentos ao primeiro já modelado.
  

Apresentei diversos conceitos e não respondi uma pergunta essencial. Quando devemos utilizar casos de uso?
Sempre. Definir casos de uso é uma tarefa básica na elaboração e planejamento de sistemas. Uma maneira interessante de identificar casos de uso é fazer uma modelagem conceitual com usuários.

Vale a pena dizer que casos de uso, representam uma visão externa do sistema. Não espere nenhuma correlação entre eles e classes do sistema.

Notação
Um diagrama use case é composto:
Ator: é um papel que um usuário desempenha em relação ao sistema. O nome do ator deve ser um sujeito
Linha de comunicação: Não é necessário identificar a comunicação entre atores e casos de uso, mas é uma boa prática
Casos de uso: O nome do caso de uso deve ser um verbo que facilite a identificação da funcionalidade do mesmo
Veja o exemplo abaixo:



Pessoal, espero ter ajudado no entendimento dos diagramas use cases. Na próxima semana vamos falar sobre os diagramas de seqüência. Caso vocês tenham alguma sugestão de novos temas, envie um e-mail para: joao@atenacriacao.com.br
E até a próxima semana.


Por favor postem suas dúvidas em relação ao artigo no fórum