DevMedia
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
Este é um post disponível para assinantes MVP
Este post também está disponível para assinantes da Engenharia de Software Magazine
ou para quem possui Créditos DevMedia.

Clique aqui para saber como acessar este post

1) Torne-se um assinante MVP e por apenas R$ 59,90 por mês você terá acesso completo a todos os posts. Assinar MVP

2) Adquira Créditos: comprando R$ 180,00 em créditos esse post custará R$ 1,20. Comprar Créditos

post favorito     comentários
Engenharia de Software 32 - Índice

Especificação de Casos de Uso - Engenharia de Software 32

Este artigo apresenta inicialmente algumas definições associadas à engenharia de requisitos e à especificação de requisitos através de casos de uso. Em seguida, são apresentados alguns exemplos reais de especificação de requisitos utilizando casos de uso. Além disso, este artigo também apresenta algumas definições importantes sobre o diagrama de casos de uso e exemplificará seu uso através de um exemplo prático.

[fechar]

Você não gostou da qualidade deste conteúdo?

(opcional) Você poderia comentar o que não lhe agradou?

Confirmo meu voto negativo

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

Engenharia de Requisitos

Especificação de Casos de Uso

Aprenda através de alguns exemplos reais

De que se trata o artigo:

Este artigo apresenta inicialmente algumas definições associadas à engenharia de requisitos e à especificação de requisitos através de casos de uso. Em seguida, são apresentados alguns exemplos reais de especificação de requisitos utilizando casos de uso. Além disso, este artigo também apresenta algumas definições importantes sobre o diagrama de casos de uso e exemplificará seu uso através de um exemplo prático.


Para que serve:

O objetivo do artigo é explicitar de forma prática como a especificação dos requisitos do software através de casos de uso podem ser efetuadas em um nível de detalhe tal que informações importantes para outras etapas do desenvolvimento como planejamento de testes, projeto e desenvolvimento não sejam omitidas.


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

O assunto abordado é útil no dia a dia do analista de requisitos na realização de suas atividades.

 

 

A engenharia de requisitos é um termo usado para descrever as atividades relacionadas à produção (levantamento, registro, validação e verificação) e gerência (controle de mudanças, gerência de configuração, rastreabilidade, gerência de qualidade dos requisitos) de requisitos. A Figura 1 representa essa definição.

 

Figura 1. Engenharia de Requisitos.

 

Mas o que podemos entender por requisitos? Existem diferentes definições encontradas na literatura técnica:

·         Um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir os seus objetivos;

·         As descrições das funções e restrições são os requisitos do sistema;

·         Um requisito é uma propriedade que o software deve exibir para resolver algum problema no mundo real;

·         Uma condição ou uma capacidade que deve ser alcançada ou estar presente em um sistema para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto...

 

Assim, podemos entender requisitos como sendo o conjunto de necessidades explicitadas pelo cliente que deverão ser atendidas para solucionar um determinado problema do negócio no qual o cliente faz parte. É importante estar atento para esta definição: embora o requisito seja definido pelo cliente, nem sempre o que o cliente quer é o que o negócio precisa. Cabe à equipe de consultores identificar a real necessidade do negócio.

Neste contexto, requisitos são importantes para:

·         Estabelecer uma base de concordância entre o cliente e o fornecedor sobre o que o software fará;

·         Fornecer uma referência para a validação do produto final;

·         Reduzir o custo de desenvolvimento (como vimos anteriormente, requisitos mal definidos causam retrabalho).

 

A atividade de identificação e especificação de requisitos do software é uma atividade bastante desafiadora. É complexo:

·         Identificar as reais necessidades do cliente;

·         Lidar com clientes;

·         Formalizar as necessidades do cliente através da especificação de requisitos de forma que esta seja de fácil entendimento para o cliente e forneça as informações requeridas pela equipe de desenvolvimento;

·         Lidar com domínios desconhecidos. Entende-se por domínio o contexto para o qual o software está sendo desenvolvido. Por exemplo: contabilidade, medicina, controle de estoque. Para ilustrar esta dificuldade, imagine-se elaborando a especificação dos requisitos de um módulo estatístico para um sistema do mercado financeiro;

·         Definir as necessidades do usuário em termos de especificações.

 

O objetivo deste artigo não é apresentar um referencial teórico sobre como lidar com cada questão envolvida nas atividades diárias de um analista de requisitos. Focaremos aqui apenas no último tópico da lista apresentada acima: “Definir as necessidades do usuário em termos de especificações”. Faremos isto de forma totalmente prática através da apresentação de um conjunto de casos de uso especificados que poderão servir de base para suas atividades como analista de requisitos.

Diagrama de Casos de Uso

Uma vez identificados e negociados, os requisitos devem ser documentados para que possam servir de base para o restante do processo de desenvolvimento.

Entre os muitos problemas que enfrentamos na documentação de requisitos, certamente, administrar o grande volume de informações gerado pelo processo de requisitos é um dos principais.

Os requisitos são documentados em um nível apropriado de detalhe. Em geral é produzido um documento de especificação de requisitos, de forma que todos os stakeholders possam entendê-lo.

O registro dos requisitos num documento próprio facilita o controle de alterações de todos os envolvidos na manutenção dos requisitos, bem como a geração de versões do documento e a facilidade de acesso por todos os envolvidos. 

Entretanto, normalmente, desempenha-se uma atividade entre o levantamento de requisitos e sua especificação, a elaboração do diagrama de casos de uso.

Um caso de uso é uma seqüência de interações entre o ator (alguém ou algo que interage com o sistema) e o sistema, que acontece de forma atômica, na perspectiva do ator. Isso significa que quando criamos um caso de uso apenas nos preocupamos com “o que” o sistema deve fazer e não com “o como” deve fazer. Para lidar com os casos de uso, 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.

Elementos de um diagrama de caso de uso

Ao criarmos um diagrama de caso de uso, também devemos nos atentar para certas características para que o diagrama não fique errado ou confuso no momento da especificação:

·       Ator: Alguém ou algo que interage com o sistema. Um ator pode ser uma pessoa, um sistema externo ou um hardware.

·       Herança de Atores: Outra característica com atores é a possibilidade de criar heranças entre eles (o mesmo que herança de classes). Através deste conceito é possível montar uma hierarquia de atores do sistema.

·       Caso de Uso: Como já explicado, um caso de uso mapeia a interação entre o ator e o sistema. Para uma perfeita compreensão do que um caso de uso controla, é fundamental que seu nome esteja dentro do contexto do negócio. Portanto, bons nomes de casos de uso são aqueles que o próprio cliente utiliza no seu dia a dia, por exemplo, Abrir Conta, Sacar Dinheiro e etc.

·         Herança de Casos de Uso: Assim como podemos criar herança entre os atores, também podemos criar herança entre os casos de uso. Essa característica tem o mesmo objetivo que uma herança de classes em um diagrama de classe, ou seja, quando queremos atribuir novas características ao caso de uso sem perder a sua essência, criamos casos de uso (filho) que herdam do caso de uso mais abstrato (pai).

·         Reuso de Caso de Uso: Podemos reutilizar casos de uso para aproveitarmos as mesmas interações entre ator e sistema. Em um diagrama, podemos reutilizar um caso de uso de duas formas possíveis:

o    Include: Essa característica significa que o caso de uso sempre será chamado.

o    Extend: Essa característica significa que o caso de uso poderá ou não ser executado, ou seja, dependerá do resultado de uma condição de negócio para ser decidido se ele será executado.

 

Por fim, vejamos os relacionamentos possíveis entre os elementos de um modelo de casos de uso:

·         Para relacionamentos de casos de uso entre si temos: generalização, extensão e inclusão;

·         Para relacionamentos de atores entre si temos um único tipo: generalização;

·         Para relacionamentos entre atores e casos de uso temos apenas a associação.

Exemplo de um diagrama de casos de uso

Para exemplificar a elaboração de um diagrama de casos de uso, utilizaremos os requisitos funcionais apresentados na Tabela 1. É normalmente a partir desta lista de requisitos que trabalhamos no desenvolvimento do diagrama de casos de uso.

 

RF1

O software deve permitir que funcionários adicionem, consultem, removam ou alterem dados de pessoas físicas.

RF2

O software deve permitir que Funcionários acompanhem o ciclo de vida dos cursos ministrados pela organização.

RF3

O software deve apresentar ao funcionário a lista de cursos cuja data de término esteja dentro de parâmetros informados no sistema.

RF4

O software deve permitir que Funcionários visualizem as propostas de curso que estejam no estado “Proposta Criada“.

RF5

O software deve permitir que o funcionário efetue o gerenciamento (inclusão, ativação, inativação e encerramento) de contas bancárias.

RF6

O software deve permitir que o funcionário efetue a administração dos dados de bancos e suas agências.

Tabela 1. Lista dos requisitos funcionais.

A modelagem de um caso de uso partirá sempre do levantamento de requisitos com o usuário. A partir destes requisitos, será possível determinar o contexto do sistema e os atores que irão interagir com o mesmo.

Para cada ator identificado, buscam-se suas responsabilidades e o que cada um espera de comportamento do sistema. Esses comportamentos são nomeados como casos de uso.

A partir de uma primeira versão, é possível refinar esse modelo, estabelecendo os relacionamentos de generalização, inclusão e extensão.

Assim, a partir desta lista de requisitos funcionais, analisa-se requisito a requisito se a funcionalidade em questão representa algo concreto e que possa ser definido como um caso de uso (e não como parte de um outro caso de uso). Caso esse seja o caso, define-se no diagrama um caso de uso correspondente nomeando-o com uma identificação que remeta à funcionalidade contemplada por ele.

Para a lista de requisitos funcionais definida na Tabela 1, chegamos ao diagrama de casos de uso representado na Figura 2.

 

Figura 2. Diagrama de casos de uso.

Contextualização dos Exemplos

As especificações de casos de uso apresentadas neste artigo são fruto da experiência prática do autor. Eles não servem de gabarito para futuras atividades de especificação, ao invés disso, podem ser considerados um ponto de partida para que possamos ver na prática como podemos escrever casos de uso.

É importante estar atento também ao fato de que os casos de uso apresentados neste artigo refletem as características de escrita do autor. Estas características que envolvem itens como nível de detalhamento, informações contidas nos casos de uso, dentre outras, costumam mudar também de organização para organização.

Dito isto, para este artigo iremos considerar o conjunto de definições apresentado na Tabela 2 como sendo importantes na descrição de um caso de uso.

 

Objetivo:

Contém uma breve descrição do objetivo do caso de uso."

A exibição deste artigo foi interrompida

Este post está disponível para assinantes MVP.



Doutor e Mestre em Engenharia de Sistemas e Computação (COPPE/UFRJ). Diretor de Operações da Kali Software (www.kalisoftware.com). Editor Chefe das revistas Engenharia de Software Magazine, SQL Magazine e Web Mobile.

O que você achou deste post?
Publicidade
Serviços

Mais posts