ScriptFácil.com - Sua fonte de scripts
uml
09/02/2005 - Por João Carlos da Silva Junior UML – Diagrama use case Nota dos usuários: Sem avaliação Visualizações: 4122 visualizações.
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:
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
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
