Diagrama de Casos de Uso: Principais desafios na elaborao

Este artigo compartilha os principais desafios e dificuldades que programadores ou

analistas de sistemas, que possuem um perfil mais tcnico, enfrentam na elaborao ou
compreenso de um diagrama de caso de uso.
2

Gostei (10) (0)

Artigo no estilo Mentoring (saiba mais)

Mentoring: apresentao do cenrio

Este artigo recomendado para todos os membros envolvidos no desenvolvimento de software que possuem interao com casos de uso. A proposta
no fazer um passo a passo sobre como fazer um diagrama de caso de uso, mas sim, compartilhar os principais desafios e dificuldades que
programadores ou analistas de sistemas, que possuem um perfil mais tcnico, enfrentam na elaborao ou compreenso deste diagrama.

Um projeto considerado bem sucedido quando ele entregue para o seu usurio final e este no encontra divergncias entre o que se pediu
e o que foi feito. E entregar exatamente o solicitado um processo complicado, pois exige muito mais do que o conhecimento de uma
linguagem de programao.

necessrio entender o negcio do cliente e saber transpor de forma clara e objetiva todas as funcionalidades solicitadas. Dentro de um
projeto de software, isto feito na fase de anlise de sistemas e as funcionalidades so descritas, na maioria das vezes, seguindo os padres
definidos por uma linguagem de modelagem unificada, a UML, atravs de diagramas de casos de uso.

Todo profissional deve estar sempre preparado para encarar desafios, dificuldades e super-los com sucesso. Isso acontece em qualquer rea
e o que todo chefe espera de seus funcionrios. Em TI isso no seria diferente. muito comum em nosso ramo ouvirmos que o prazo para a
criao de um projeto apertado e que o oramento curto, porm temos que entreg-lo com sucesso, dentro do prazo estabelecido e com
qualidade.

E para que isso acontea, os profissionais precisam desdobrar-se e por muitas vezes executar atividades das quais no tiveram tempo hbil
para se preparar ou ainda no tem conhecimento suficiente para execut-los. Um exemplo clssico quando programadores ou analistas com
perfis mais tcnicos so selecionados para entrevistar os usurios e descrever todas as funcionalidades em casos de uso na fase de anlise do
projeto.

Neste contexto, esse artigo apresenta as principais dificuldades encontradas por estes profissionais na elaborao de um caso de uso e
sugestes de como resolver os principais problemas, mitigando os riscos de no ter todas as funcionalidades descritas seguindo as melhores
prticas abordadas pela UML (ler BOX 1).

BOX 1. UML

A UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) uma linguagem visual utilizada para modelar sistemas
computacionais. Essa linguagem se tornou, nos ltimos anos, a linguagem-padro de modelagem de software adotada internacionalmente
pela indstria de Engenharia de Software.

Deve ficar bem claro que a UML no uma linguagem de programao, e que o seu objetivo auxiliar os engenheiros de software a definir
as caractersticas do software, tais como seus requisitos, seu comportamento, sua estrutura lgica, a dinmica de seus processos e at mesmo
suas necessidades fsicas em relao ao equipamento sobre o qual o sistema dever ser implantado.

Todas essas caractersticas so definidas por meio da UML antes do software comear a ser realmente desenvolvido.
A UML possui diversos diagramas com o objetivo de fornecer mltiplas vises do sistema, analisando-o e modelando-o sob diversos
aspectos. Cada diagrama da UML analisa o sistema, ou parte dele, sob uma determina viso. Alguns diagramas enfocam o sistema de forma
mais comportamental, apresentando uma viso das funcionalidades do sistema, como o objetivo do diagrama de casos de uso, ao passo que
outros oferecem uma viso de uma camada mais profunda do software, apresentando um enfoque mais tcnico.

O desenvolvimento de software, independente da metodologia adotada, possui as fases de anlise, desenho (design), codificao, testes e
implantao. Cada uma destas fases tem uma importncia crucial, e para atingir os objetivos do projeto, todas devem ser criteriosamente
elaboradas, seja utilizando uma abordagem mais rica em documentao, como, por exemplo, o UP (Unified Process) ou metodologias mais
geis como o SCRUM.

Em TI, costuma-se priorizar as atividades de design e codificao. Isso acontece pelo perfil do profissional que atua na rea, formada
principalmente por tcnicos, que dedicam boa parte do seu tempo em estudos e pesquisas em linguagens de programao e tem um interesse
muito maior por bits e bytes do que por documentao.

Outro ponto que direciona estes profissionais a gostarem mais da parte tcnica a grade curricular dos cursos de tecnologia na maioria das
universidades, que possuem um grande nmero de disciplinas referentes programao e muito pouco referente metodologias, processos e
documentaes.

Porm, a fase de anlise de sistemas de fundamental importncia para o sucesso de um projeto, pois nela que ser entendido todo o
negcio do cliente e descritas todas as funcionalidades e comportamentos esperados para o sistema. Um projeto considerado bem sucedido
quando ele entregue para o seu usurio final e este no encontra divergncias entre o que se pediu e o que foi feito.

E entregar exatamente o solicitado um processo complicado, pois exige muito mais do que o conhecimento de uma linguagem de
programao.

Uma boa prtica para descrever as funcionalidades do sistema seguir os padres definidos por uma linguagem de modelagem unificada, a
UML, atravs de diagramas de casos de uso. Este diagrama utilizado principalmente para auxiliar no levantamento e anlise dos requisitos,
em que so determinadas as necessidades do usurio, e na compreenso do sistema como um todo, embora venha a ser consultado durante
todo o processo de modelagem e sirva de base para todos os outros diagramas.

O diagrama de casos de uso apresenta uma linguagem simples e de fcil compreenso para que os usurios possam ter uma ideia geral de
como o sistema ir se comportar.

Normalmente, os casos de uso so elaborados por profissionais que tem perfil de anlise de sistemas, que conseguem entrevistar os clientes,
entender todas as suas necessidades, e transpor de forma clara e objetiva, todos os cenrios propostos. Entretanto, o mundo corporativo, com
suas premissas de curto prazo e oramento apertado, muitas vezes propicia o surgimento de situaes de desvio do cenrio ideal para o
desenvolvimento de um projeto.

Tais desvios podem surpreender funcionrios, que passam a assumir papis e responsabilidades das quais no tiveram tempo hbil para se
preparar ou ainda no tem conhecimento suficiente para execut-los. Um exemplo clssico desses desvios observado quando pessoas de
vocao tcnica e aptido para a codificao de programas so deslocadas para elaborarem casos de uso na fase de Anlise do Projeto.

Pessoas das reas mais tcnicas tendem a explicar como devemos resolver um problema. Entretanto, quando estas pessoas assumem o papel
de Analista de Negcio durante a fase de anlise do projeto, elas devem, entre outras tarefas, especificar o que tem que ser feito, e deixar para
a prxima fase, a de desenho fsico, a explicao de que forma o problema ou o cenrio proposto na fase anterior ser solucionado
tecnicamente.

Outra grande dificuldade encontrada que casos de uso so subjetivos. Eles no so definidos por uma gramtica rigorosa como so nossas
linguagens de programao. No existem compiladores que analisam casos de uso e comprovam se eles esto vlidos, bem formatados e se
fazem sentido para o negcio.

Em anlise de exemplos reais, possvel observar o cenrio descrito acima, com diversas pessoas com vocao e experincia tcnica
especificando casos de uso. Em alguns exemplos, existe ainda um agravante, onde muitos possuem apenas experincia em Alta Plataforma
(Mainframe), o que cria um grau de complexidade ainda maior, por nunca terem visto nada em UML.
Geralmente, pessoas com experincia em Baixa Plataforma, se nunca elaboraram um caso de uso, pelo menos j tiveram a oportunidade de
visualizar um diagrama em UML, e neste caso, os atores, cenrios e relacionamentos no so to complexos como para as pessoas que
estavam acostumadas a trabalhar apenas com fluxogramas.

A partir de agora sero abordados alguns dos problemas mais comuns encontrados em casos de uso elaborados por pessoas tcnicas,
acompanhados de algumas dicas para soluo:

O que fazer? x Como fazer?

Um dos problemas mais comuns na elaborao de casos de uso encontrar, em sua descrio, de que forma vamos resolver um problema ou
uma ao esperada. A forma ou mtodo utilizado para resolver o problema ou para explicar como fazer deve ser considerado em uma fase
posterior do projeto.

Como podemos ter certeza ainda na fase de anlise que o que estou dizendo no como fazer a melhor alternativa? No possvel ter esta
certeza, pois nesta fase do projeto estamos ainda entendendo e detalhando o escopo, isto , o que tem que ser feito. Quando todo o escopo
estiver detalhado, ser possvel ter uma viso completa e optar pela melhor alternativa para resolver o cenrio proposto.

E para ter esta viso detalhada, preciso entender todas as funcionalidades solicitadas para o sistema. E isso que a descrio do caso de uso
tem que conter. necessrio descrever passo a passo toda a interao entre um Ator e um Sistema, sempre detalhando o que tem que ser
feito com uma viso de negcio.

Descrever os passos dos fluxos tecnicamente

Como boa prtica na especificao de um caso de uso, no se deve descrever nos passos dos fluxos informaes tcnicas ou de interface com
o usurio.

Exemplo de um passo com informao tcnica e com detalhe de interface:

- O Sistema ir buscar no servidor SRV_PROD_005A, base de dados SCH_CORP, tabela TB_045_CLIE, os campos
CLI_ST_NOME, CLI_ST_FONE, CLI_ST_ENDE atravs do sinnimo TB_CLIENTE para apresentar no pop-up.

Exemplo do mesmo passo, descrito com viso de negcio:

- O Sistema apresenta ao Ator as informaes Nome, Telefone e Endereo do Cliente selecionado.

Como se pode verificar, existe uma grande diferena nos itens acima. Se voc tiver um conhecimento tcnico, pode pensar: com as
informaes do primeiro item (como fazer) eu consigo programar e com as do item debaixo (o que fazer), no. Porm, deve-se ter em mente
alguns pontos importantes para a fase de anlise:

Quem deve validar o caso de uso uma pessoa que tem conhecimento do negcio e na maior parte das vezes ela no faz ideia o que um
banco de dados;

Se um sistema novo estiver sendo criado, com o escopo ainda sendo detalhado, no possvel saber quais tabelas ou campos devem ser
criados;

Um detalhamento excessivo de interface visual durante a fase de anlise pode limitar o design do sistema. Especificar detalhes visuais se
faz necessrio somente para o entendimento do comportamento do sistema.

Caso informaes tcnicas estejam disponveis durante a descrio do caso de uso, possvel criar uma seo Direcionamento Tcnico e
informar nesta seo os servidores, tabelas, campos ou outras informaes tcnicas que facilitaro o entendimento do analista de sistema
quando o mesmo estiver fazendo o desenho lgico e/ou fsico da aplicao.

Utilizar a Extends do caso de uso exatamente como a herana na programao orientada a objetos
Na orientao a objeto, quando se diz que uma classe herda de outra, isto significa que ela passa a ter tambm as funcionalidades e
comportamentos desta classe herdada. Entretanto, para casos de uso, o conceito de extends um pouco diferente. Ele usado para mostrar
que um caso de uso pode adicionar a funcionalidade de outro caso de uso em determinadas circunstncias.

Podemos dizer que ao estender outro caso de uso, ele poder acionar uma funcionalidade deste caso de uso herdado em algum momento de
sua funcionalidade original. Por exemplo, o caso de Uso Efetuar Login de um sistema pode incluir a opo Registrar nova conta, mas s
quando o usurio ainda no tiver uma conta (ver Figura 1).

Figura 1. Representao de Extends nos Casos de Uso.

Quando um caso de uso adiciona a funcionalidade de outro caso de uso em todas as situaes, deve-se utilizar o relacionamento include ao
invs de extends. Por exemplo, o caso de uso Processar Pedido inclui a opo Emitir Nota Fiscal. Isto significa que sempre que o caso
de uso Processar Pedido for acionado, a opo Emitir Nota Fiscal tambm ser acionada (ver Figura 2).

Figura 2. Representao de Include nos Casos de Uso.

Identificar cada caso de uso como uma classe, um programa ou sub-programa

Um problema conceitual criar uma associao que um caso de uso representa uma classe (na baixa plataforma) ou um programa / sub-
programa (na alta plataforma). O caso de uso deve representar uma funcionalidade, e esta pode derivar em um ou mais programas/classes,
conforme soluo tcnica que ser definida na fase de desenho fsico.

Desta forma, sempre que for mapear os casos de uso a serem elaborados, pense em funcionalidades. Procure abstrair o que ser necessrio
criar tecnicamente para implementar estas funcionalidades.

Caso de uso sem ator relacionado

Conceitualmente, os passos dos fluxos do caso de uso descrevem a interao entre o ator e o sistema. A questo ator gera bastante confuso,
pois passa a impresso muitas vezes errnea de que tem que ser uma pessoa. Devido a esta confuso, j foram encontrados diversos casos de
uso sem ter um ator relacionado, j que o mesmo era disparado automaticamente por um sistema e neste caso no tinha uma pessoa ou um
ator humano para associar.
Este erro bastante comum em casos de uso que descrevem cenrios que iro ocasionar no desenho fsico, programas batch, web-services,
etc. Para este cenrio, tm-se como atores os sistemas que chamam e iniciam os casos de uso. Por exemplo: o processamento batch que envia
os dados contbeis para o Banco Central acionado por um Scheduler (ver Figura 3).

Figura 3. Representao de um sistema como Ator.

Caso de uso sem um incio definido

Todo caso de uso deve ter um incio, isto , deve ter um ator que o aciona. Para facilitar o entendimento, pode-se citar tecnicamente que o
incio de um caso de uso pode ser a seleo de uma opo ou um agendamento de um processo batch, etc. Como exemplo, tem-se:

01. Este caso de uso inicia quando o ator seleciona a opo Incluir Cliente da Tela Inicial.

Requisitos de negcio sem caso de uso relacionado

Como saber se todos os casos de uso foram mapeados e descritos? Ser que nenhum caso de uso foi esquecido? Esta uma dificuldade para
quem precisa ter uma viso global do projeto.

Para auxiliar nesta situao, uma boa dica utilizar uma matriz de relacionamento Requisitos x Casos de Uso, para no deixar nenhum
requisito funcional sem um caso de uso associado. Alguns sistemas de mercado como, por exemplo, o Enterprise Architect da Sparx
Systems, criam esta matriz automaticamente.

Atraso na data de entrega acordada para os casos de uso

Muitas pessoas, quando tm a responsabilidade de identificar e descrever todos os casos de uso de um projeto ou de um mdulo do projeto,
tm o hbito de identificar um caso de uso e j descrev-lo. Apesar de no ser uma prtica errada, a maneira mais segura de faz-la
mapeando todos os casos de uso antes de especific-los.

Desta forma, possvel identificar partes que sero reutilizadas (casos de uso que podem ser includos ou estendidos) e tambm ter uma
visibilidade da complexidade e qual a produtividade mdia para descrever cada caso de uso. Com isso, possvel auxiliar os gerentes de
projeto a mitigarem o risco de possveis atrasos nas datas acordadas.

Dar nome ao caso de uso

Muitos dos casos de uso revisados em projetos no seguem as normas pr-estabelecidas para a nomenclatura, tais como: eles deveriam
comear com um verbo como, por exemplo, Consultar, Incluir, Alterar, etc.

Assim, ter um padro de nomes e um guia para seguir sempre importante.

Para minimizar este problema de esquecimento ou mesmo de falta de conhecimento das normas de nomenclatura, uma boa dica ter um
checklist que o analista deve usar sempre que finalizar o seu caso de uso. Este checklist deve conter validaes para todas as regras e normas,
o que o ajudar a revisar se algo foi esquecido ou criado de maneira invlida.

Concluso
Todos estes problemas e dificuldades relatados aqui demonstram que apesar de ter uma notao simples e da sua teoria no ser extensa,
elaborar casos de uso no ato trivial tanto quanto pode aparentar ser.

importante que todos os membros envolvidos no desenvolvimento de software, que utilizam UML, entendam como elaborar e como
interpretar um caso de uso, pois ele a base de todo o projeto. Durante a fase de anlise, ele o principal entregvel e durante as demais
fases, ele base tanto para a elaborao dos diagramas na fase de desenho do projeto, como na fase de construo onde o programador
entender qual o comportamento dever ser implementado e tambm na fase de testes, onde ser possvel validar se todas as funcionalidades
solicitadas pelo cliente, foram disponibilizadas no sistema.

Espero que as lies aprendidas na prtica e documentadas neste artigo possam ajudar na elaborao de casos de uso mais eficazes, que
possam ser facilmente compreendidos e que permitam aos desenvolvedores construir o produto certo na primeira vez, diminuindo o
retrabalho e conduzindo a um aumento de produtividade e qualidade da equipe, e consequentemente a um projeto de sucesso.

Links e Referncias

UML Use Case Diagrams: Guidelines

http://msdn.microsoft.com/en-us/library/dd409432.aspx

Use Case Diagrams Tutorial

http://sparxsystems.com/resources/uml2_tutorial/uml2_usecasediagram.html

Especificao UML 2.0

http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF

Gilleanes T.A. Guedes, UML 2 Uma abordagem prtica, Junho, 2010.

Adriano Esposito

Arquiteto Empresarial e de Solues na Hewlett-Packard Company, com mais de 15 anos de experincia na rea de TI. Bacharel em Cincia
da Computao na PUC-SP, possui especializao em Gesto de TI pela FGV-SP. Certificado em Intel [...]

Publicado em 2013

Leia mais em: Diagrama de Casos de Uso: Principais desafios na elaborao http://www.devmedia.com.br/diagrama-de-casos-de-uso-principais-
desafios-na-elaboracao/29790#ixzz3lWAkD8Ha