Artigo Engenharia de Software 9 - UML – Casos de Uso

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (3)  (0)

Artigo da Revista Engenharia de Software edição 09.

Esse artigo faz parte da revista Engenharia de Software 9 edição especial. Clique aqui para ler todos os artigos desta edição

 

Requisitos

UML – Casos de Uso

Modelando os casos de uso como contrato entre usuários e desenvolvedores

De que se trata o artigo:

Este artigo aborda uma das principais ferramentas da UML — o caso de uso. Será demonstrada sua utilização como técnica para compreender e descrever requisitos, bem como a estrutura do diagrama e cenários, e as seções envolvidas. Todos os tópicos trazem exemplos e apresentam boas práticas.

Para que serve:

Fornecer aos desenvolvedores ou estudantes da área de sistemas o conhecimento básico a fim de conseguir desenhar e escrever o modelo atualmente mais importante para documentação de requisitos.

Em que situação o tema é útil:

Para quem ainda não conhece como escrever um caso de uso, ou para quem já o faz há algum tempo, mas não tem conseguido o sucesso esperado.

 

Este artigo apresentará uma das principais ferramentas oferecidas pela UML — o caso de uso, demonstrando sua utilização como uma técnica para compreender e descrever requisitos, além de um contrato poderoso entre usuários e analistas, e entre analistas e programadores. Serão apresentadas todas as seções de um caso de uso, explicando as melhores práticas em cada uma.

O que é um caso de uso?

O caso de uso é utilizado para capturar os requisitos do sistema, ou seja, o que o software deve fazer a fim de atender as necessidades das partes interessadas pelo mesmo, partes estas que são conhecidas na área de projetos como stakeholders.

A UML apresenta o diagrama de casos de uso, que permite ao analista agrupar o comportamento esperado do sistema em rotinas de limites muito bem definidos, que farão a interação com os usuários. Contudo, além do diagrama, Ivar Jacobson, o idealizador do conceito de caso de uso (use case), nos oferece a especificação dos requisitos na forma textual. Esse formato, na UML, é chamado de descrições informais, que nada mais são do que os cenários de cada caso de uso. As práticas aconselhadas para a escrita desses cenários foram delineadas por metodologistas que vêm trabalhando para aperfeiçoar essas técnicas de escrita. Entre eles estão: Kurt Bittner, Alistair Cockburn, Gunnar Overgaard e Geri Schneider.

Os principais conceitos associados ao modelo de caso de uso são: atores e casos de uso.

Um ator (actor) representa um papel executado por um usuário ou por outro sistema que interaja com o sistema modelado. O ator não vai representar a pessoa e sim o papel que essa pessoa encena. Dessa forma, pode ser que a secretária Maria possa interagir com o sistema com dois ou mais papéis, o de secretária e o de vendedora.

Um ator é representado visualmente por um ícone conhecido como stick man (homem palito), com o nome do ator abaixo ou acima do desenho. O mais comum é modelarmos abaixo. Outra representação para um ator é mostrá-lo como uma classe estereotipada «actor». Por fim, podemos associar o ator a um ícone específico que indique o tipo do mesmo, como por exemplo a figura de um computador para representar um outro sistema que interaja com o sistema modelado. A vantagem dessa representação é separarmos a identificação visual de atores humanos dos atores não-humanos. Veja esses exemplos na Figura 1.

 

Figura 1. Representações visuais possíveis para um ator

 

Um caso de uso (use case) é a especificação de um conjunto de ações executadas por um sistema, produzindo um resultado observável por um ou mais atores, e que são representadas por um cenário principal e cenários alternativos.

O principal objetivo de um caso de uso é mostrar o comportamento oferecido por um sistema (ou parte dele), sem fazer referência a sua estrutura interna. Dessa forma, podemos deduzir que é interessante para o usuário saber que seu cadastro de clientes será atualizado (ou até mesmo gravado), mas não é objetivo do caso de uso dizer que o sistema está gravando a tabela TabClientes.

Sua representação é feita por meio de uma elipse, com os títulos dos casos de uso no seu interior, ou abaixo dele. Veja exemplos na Figura 2.

 "

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?