Artigos Canal Mais Artigo Engenharia de Software 10 - UML – Casos de Uso

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

Requisitos

UML – Casos de Uso

Entendendo os casos de uso na prática – um estudo de caso – Parte I

 

De que se trata o artigo:

Este artigo apresenta o caso de uso de uma maneira prática. Será desenvolvido um estudo de caso, passando por todas as fases da modelagem dos requisitos quanto aos casos de uso.

Para que serve:

Fornecer aos desenvolvedores ou estudantes da área de sistemas uma linha de entendimento com o intuito de orientá-los a escrever seus próprios casos de uso.

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 na prática, por meio do desenvolvimento de um estudo de caso. Nessa primeira parte detalharemos o problema, os requisitos e extrairemos os casos de uso necessários à implementação. Escreveremos os primeiros cenários, com seus respectivos protótipos, preparando o sistema para se tornar funcional.

O problema

No artigo anterior, explicamos o caso de uso como uma das principais ferramentas para capturar os requisitos do sistema. Neste usaremos os conceitos apresentados para desenvolver um estudo de caso. É preciso ressaltar que os modelos de documentos aqui apresentados são oriundos da experiência da autora como analista de sistemas, servindo apenas como exemplo para os profissionais da área. E que os requisitos descritos têm objetivo somente como exercício, não representando, na prática, as necessidades de um sistema deste tipo.

Suponha que um analista XYZ tenha aberto uma consultoria e, dentre os primeiros clientes, surja o dono de uma pequena papelaria, com uma única filial, desejando informatizar sua empresa.

O analista marca algumas reuniões e após estabelecer o escopo do sistema, dá início ao levantamento dos requisitos. De posse desses requisitos, seu trabalho é modelá-los, de tal forma que represente a expectativa desse cliente. Para essa modelagem, ele utiliza os casos de uso, pois pretende fazer uso da tecnologia de orientação a objetos. Os casos de uso e seus protótipos são apresentados para o cliente, que sugere alterações. Esse processo perdura ciclicamente até que o cliente dê sua aprovação para o analista.

Então, o projeto estará pronto para uma nova etapa, no qual as classes serão identificadas e o sistema começará a ser implementado.

Vamos acompanhar como ficou essa fase inicial da modelagem.

O levantamento de requisitos

O analista XYZ, após cada reunião elaborou uma ata que foi devidamente encaminhada para o cliente, a fim de validar com o mesmo o entendimento dos requisitos. Na Tabela 1 vemos o exemplo de uma dessas atas, representando a primeira reunião ocorrida.

 

ATA DE REUNIÃO

Data da reunião:      10/10/2008

Participantes:          XYZ – analista de sistemas

                              MNO – diretor da Papelaria ABC

Assunto:                 Levantamento de requisitos

  1. O sr. MNO apresentou ao sr. XYZ a papelaria ABC, que tem cerca de 800 m2, com seções arrumadas por tipo de item: cadernos e fichários, pastas, papéis para impressão etc.
  2. A papelaria conta com vendedores que atendem ao público, recebendo comissão pelas vendas efetuadas. A comissão tem variação de acordo com a época do ano. No período de janeiro a março, a comissão é de 7% sobre as vendas. Nos outros meses é de 5%. Além disso, todo vendedor possui um salário fixo. Não há cotas a serem alcançadas.
  3. Após escolher os produtos, com a ajuda ou não de um vendedor, o cliente deve se dirigir a um deles para tirar o pedido de venda. Esse pedido conterá todos os produtos e liberará para o caixa apenas o pagamento. Só existe um caixa na papelaria, responsável apenas pelo recebimento do pagamento.
  4. Se um cliente tiver dúvidas sobre a existência de um produto ou sobre o preço do mesmo, poderá consultar um dos vendedores, que fará a pesquisa no sistema.
  5. Todos os produtos recebem um código que não está associado ao código de barras. São coladas etiquetas com esses códigos em todos os produtos. Da mesma forma, em cada prateleira há uma etiqueta com o nome dos produtos, seu código e o preço atualizado. Assim, nos produtos não há etiqueta de preço.
  6. O sr. MNO solicitou que além do sistema que registrará as vendas, seja disponibilizado um módulo para controlar o estoque.

(...)

...
Quer ler esse conteúdo completo? Tenha acesso completo