Diagrama de Casos de Uso_ Principais desafios na elaboração

Prévia do material em texto

10/4/2014 Diagrama de Casos de Uso: Principais desafios na elaboração
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=29790 1/11
www.devmedia.com.br 
[versão para impressão]
Link original: http://www.devmedia.com.br/articles/viewcomp.asp?comp=29790
Diagrama de Casos de Uso:
Principais desafios na
elaboração
Este artigo compartilha os principais desafios e dificuldades
que programadores ou analistas de sistemas, que possuem
um perfil mais técnico, enfrentam na elaboração ou
compreensão de um diagrama de caso de uso.
Artigo no estilo Mentoring (saiba mais)
Mentoring: apresentação do cenário
Este artigo é recomendado para todos os membros envolvidos no desenvolvimento de
software que possuem interação com casos de uso. A proposta não é 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 técnico, enfrentam na elaboração ou compreensão deste
diagrama.
Um projeto é considerado bem sucedido quando ele é entregue para o seu usuário
10/4/2014 Diagrama de Casos de Uso: Principais desafios na elaboração
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=29790 2/11
final e este não encontra divergências 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 programação.
É necessário entender o negócio 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 análise de sistemas e as funcionalidades são descritas, na maioria das vezes,
seguindo os padrões definidos por uma linguagem de modelagem unificada, a UML,
através 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 funcionários. Em TI isso não seria diferente. É muito comum em nosso ramo
ouvirmos que o prazo para a criação de um projeto é apertado e que o orçamento é
curto, porém temos que entregá-lo com sucesso, dentro do prazo estabelecido e com
qualidade.
E para que isso aconteça, os profissionais precisam desdobrar-se e por muitas vezes
executar atividades das quais não tiveram tempo hábil para se preparar ou ainda não tem
conhecimento suficiente para executá-los. Um exemplo clássico é quando programadores
ou analistas com perfis mais técnicos são selecionados para entrevistar os usuários e
descrever todas as funcionalidades em casos de uso na fase de análise do projeto.
Neste contexto, esse artigo apresenta as principais dificuldades encontradas por estes
profissionais na elaboração de um caso de uso e sugestões de como resolver os
principais problemas, mitigando os riscos de não ter todas as funcionalidades descritas
seguindo as melhores práticas 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-padrão de modelagem de software adotada
internacionalmente pela indústria de Engenharia de Software.
Deve ficar bem claro que a UML não é uma linguagem de programação, e que o seu
objetivo é auxiliar os engenheiros de software a definir as características do
10/4/2014 Diagrama de Casos de Uso: Principais desafios na elaboração
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=29790 3/11
software, tais como seus requisitos, seu comportamento, sua estrutura lógica, a
dinâmica de seus processos e até mesmo suas necessidades físicas em relação ao
equipamento sobre o qual o sistema deverá ser implantado.
Todas essas características são definidas por meio da UML antes do software
começar a ser realmente desenvolvido.
A UML possui diversos diagramas com o objetivo de fornecer múltiplas visões do
sistema, analisando-o e modelando-o sob diversos aspectos. Cada diagrama da UML
analisa o sistema, ou parte dele, sob uma determina visão. Alguns diagramas
enfocam o sistema de forma mais comportamental, apresentando uma visão das
funcionalidades do sistema, como é o objetivo do diagrama de casos de uso, ao
passo que outros oferecem uma visão de uma camada mais profunda do software,
apresentando um enfoque mais técnico.
O desenvolvimento de software, independente da metodologia adotada, possui as fases
de análise, desenho (design), codificação, testes e implantação. Cada uma destas fases
tem uma importância crucial, e para atingir os objetivos do projeto, todas devem ser
criteriosamente elaboradas, seja utilizando uma abordagem mais rica em documentação,
como, por exemplo, o UP (Unified Process) ou metodologias mais ágeis como o SCRUM.
Em TI, costuma-se priorizar as atividades de design e codificação. Isso acontece pelo
perfil do profissional que atua na área, formada principalmente por técnicos, que dedicam
boa parte do seu tempo em estudos e pesquisas em linguagens de programação e tem
um interesse muito maior por bits e bytes do que por documentação.
Outro ponto que direciona estes profissionais a gostarem mais da parte técnica é a grade
curricular dos cursos de tecnologia na maioria das universidades, que possuem um
grande número de disciplinas referentes à programação e muito pouco referente à
metodologias, processos e documentações.
Porém, a fase de análise de sistemas é de fundamental importância para o sucesso de um
projeto, pois é nela que será entendido todo o negócio do cliente e descritas todas as
funcionalidades e comportamentos esperados para o sistema. Um projeto é considerado
bem sucedido quando ele é entregue para o seu usuário final e este não encontra
divergências entre o que se pediu e o que foi feito.
E entregar exatamente o solicitado é um processo complicado, pois exige muito mais do
10/4/2014 Diagrama de Casos de Uso: Principais desafios na elaboração
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=29790 4/11
que o conhecimento de uma linguagem de programação.
Uma boa prática para descrever as funcionalidades do sistema é seguir os padrões
definidos por uma linguagem de modelagem unificada, a UML, através de diagramas de
casos de uso. Este diagrama é utilizado principalmente para auxiliar no levantamento e
análise dos requisitos, em que são determinadas as necessidades do usuário, e na
compreensão 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 fácil compreensão
para que os usuários possam ter uma ideia geral de como o sistema irá se comportar.
Normalmente, os casos de uso são elaborados por profissionais que tem perfil de análise
de sistemas, que conseguem entrevistar os clientes, entender todas as suas
necessidades, e transpor de forma clara e objetiva, todos os cenários propostos.
Entretanto, o mundo corporativo, com suas premissas de curto prazo e orçamento
apertado, muitas vezes propicia o surgimento de situações de desvio do cenário ideal
para o desenvolvimento de um projeto.
Tais desvios podem surpreender funcionários, que passam a assumir papéis e
responsabilidades das quais não tiveram tempo hábil para se preparar ou ainda não tem
conhecimento suficiente para executá-los. Um exemplo clássico desses desvios é
observado quando pessoas de vocação técnica e aptidão para a codificação de programas
são deslocadas para elaborarem casos de uso na fase de Análise do Projeto.
Pessoas das áreas mais técnicas tendem a explicar comodevemos resolver um problema.
Entretanto, quando estas pessoas assumem o papel de Analista de Negócio durante a
fase de análise do projeto, elas devem, entre outras tarefas, especificar o que tem que
ser feito, e deixar para a próxima fase, a de desenho físico, a explicação de que forma o
problema ou o cenário proposto na fase anterior será solucionado tecnicamente.
Outra grande dificuldade encontrada é que casos de uso são subjetivos. Eles não são
definidos por uma gramática rigorosa como são nossas linguagens de programação. Não
existem compiladores que analisam casos de uso e comprovam se eles estão válidos,
bem formatados e se fazem sentido para o negócio.
Em análise de exemplos reais, é possível observar o cenário descrito acima, com diversas
pessoas com vocação e experiência técnica especificando casos de uso. Em alguns
exemplos, existe ainda um agravante, onde muitos possuem apenas experiência em “Alta
10/4/2014 Diagrama de Casos de Uso: Principais desafios na elaboração
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=29790 5/11
Plataforma (Mainframe)”, o que cria um grau de complexidade ainda maior, por nunca
terem visto nada em UML.
Geralmente, pessoas com experiência 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, cenários e relacionamentos não são tão complexos como para as
pessoas que estavam acostumadas a trabalhar apenas com fluxogramas.
A partir de agora serão abordados alguns dos problemas mais comuns encontrados em
casos de uso elaborados por pessoas técnicas, acompanhados de algumas dicas para
solução:
O que fazer? x Como fazer?
Um dos problemas mais comuns na elaboração de casos de uso é encontrar, em sua
descrição, de que forma vamos resolver um problema ou uma ação esperada. A forma ou
método 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 análise que o que estou dizendo no “como
fazer” é a melhor alternativa? Não é possível 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á possível ter uma visão completa e optar
pela melhor alternativa para resolver o cenário proposto.
E para ter esta visão detalhada, é preciso entender todas as funcionalidades solicitadas
para o sistema. E é isso que a descrição do caso de uso tem que conter. É necessário
descrever passo a passo toda a interação entre um “Ator” e um “Sistema”, sempre
detalhando o que tem que ser feito com uma visão de negócio.
Descrever os passos dos fluxos tecnicamente
Como boa prática na especificação de um caso de uso, não se deve descrever nos
passos dos fluxos informações técnicas ou de interface com o usuário.
Exemplo de um passo com informação técnica 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”
através do sinônimo “TB_CLIENTE” para apresentar no pop-up.
10/4/2014 Diagrama de Casos de Uso: Principais desafios na elaboração
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=29790 6/11
Exemplo do mesmo passo, descrito com visão de negócio:
- O Sistema apresenta ao “Ator” as informações “Nome”, “Telefone” e “Endereço” do
Cliente selecionado.
Como se pode verificar, existe uma grande diferença nos itens acima. Se você tiver um
conhecimento técnico, pode pensar: com as informações do primeiro item (como fazer)
eu consigo programar e com as do item debaixo (o que fazer), não. Porém, deve-se ter
em mente alguns pontos importantes para a fase de análise:
· Quem deve validar o caso de uso é uma pessoa que tem conhecimento do negócio e na
maior parte das vezes ela não faz ideia o que é um banco de dados;
· Se um sistema novo estiver sendo criado, com o escopo ainda sendo detalhado, não é
possível saber quais tabelas ou campos devem ser criados;
· Um detalhamento excessivo de interface visual durante a fase de análise pode limitar o
design do sistema. Especificar detalhes visuais se faz necessário somente para o
entendimento do comportamento do sistema.
Caso informações técnicas estejam disponíveis durante a descrição do caso de uso, é
possível criar uma seção “Direcionamento Técnico” e informar nesta seção os servidores,
tabelas, campos ou outras informações técnicas que facilitarão o entendimento do
analista de sistema quando o mesmo estiver fazendo o “desenho lógico e/ou físico” da
aplicação.
Utilizar a “Extends” do caso de uso exatamente
como a herança na programação orientada a
objetos
Na orientação a objeto, quando se diz que uma classe herda de outra, isto significa que
ela passa a ter também 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 circunstâncias.
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 opção
10/4/2014 Diagrama de Casos de Uso: Principais desafios na elaboração
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=29790 7/11
“Registrar nova conta”, mas só quando o usuário ainda não tiver uma conta (ver Figura
1).
Figura 1. Representação de “Extends” nos Casos de Uso.
Quando um caso de uso adiciona a funcionalidade de outro caso de uso em todas as
situações, deve-se utilizar o relacionamento “include” ao invés de “extends”. Por
exemplo, o caso de uso “Processar Pedido” inclui a opção “Emitir Nota Fiscal”. Isto
significa que sempre que o caso de uso “Processar Pedido” for acionado, a opção “Emitir
Nota Fiscal” também será acionada (ver Figura 2).
Figura 2. Representação de “Include” nos Casos de Uso.
Identificar cada caso de uso como uma classe,
10/4/2014 Diagrama de Casos de Uso: Principais desafios na elaboração
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=29790 8/11
um programa ou sub-programa
Um problema conceitual é criar uma associação 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 solução técnica que será definida na fase de desenho físico.
Desta forma, sempre que for mapear os casos de uso a serem elaborados, pense em
funcionalidades. Procure abstrair o que será necessário criar tecnicamente para
implementar estas funcionalidades.
Caso de uso sem ator relacionado
Conceitualmente, os passos dos fluxos do caso de uso descrevem a interação entre o
ator e o sistema. A questão ator gera bastante confusão, pois passa a impressão muitas
vezes errônea de que tem que ser uma pessoa. Devido a esta confusão, 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 não tinha uma “pessoa” ou um
“ator humano” para associar.
Este erro é bastante comum em casos de uso que descrevem cenários que irão ocasionar
no desenho físico, programas batch, web-services, etc. Para este cenário, têm-se como
atores os sistemas que chamam e iniciam os casos de uso. Por exemplo: o
processamento batch que envia os dados contábeis para o Banco Central é acionado por
um “Scheduler” (ver Figura 3).
10/4/2014 Diagrama de Casos deUso: Principais desafios na elaboração
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=29790 9/11
Figura 3. Representação de um sistema como “Ator”.
Caso de uso sem um início definido
Todo caso de uso deve ter um início, isto é, deve ter um ator que o aciona. Para facilitar
o entendimento, pode-se citar tecnicamente que o início de um caso de uso pode ser a
seleção de uma opção ou um agendamento de um processo batch, etc. Como exemplo,
tem-se:
01. Este caso de uso inicia quando o ator seleciona a opção “Incluir Cliente” da “Tela
Inicial”.
Requisitos de negócio 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 visão global
do projeto.
Para auxiliar nesta situação, uma boa dica é utilizar uma matriz de relacionamento
“Requisitos x Casos de Uso”, para não 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.
10/4/2014 Diagrama de Casos de Uso: Principais desafios na elaboração
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=29790 10/11
Atraso na data de entrega acordada para os
casos de uso
Muitas pessoas, quando têm a responsabilidade de identificar e descrever todos os casos
de uso de um projeto ou de um módulo do projeto, têm o hábito de identificar um caso
de uso e já descrevê-lo. Apesar de não ser uma prática errada, a maneira mais segura de
fazê-la é mapeando todos os casos de uso antes de especificá-los.
Desta forma, é possível identificar partes que serão reutilizadas (casos de uso que
podem ser incluídos ou estendidos) e também ter uma visibilidade da complexidade e
qual a produtividade média para descrever cada caso de uso. Com isso, é possível auxiliar
os gerentes de projeto a mitigarem o risco de possíveis atrasos nas datas acordadas.
Dar nome ao caso de uso
Muitos dos casos de uso revisados em projetos não seguem as normas pré-
estabelecidas para a nomenclatura, tais como: eles deveriam começar com um verbo
como, por exemplo, “Consultar”, “Incluir”, “Alterar”, etc.
Assim, ter um padrão 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 validações para todas
as regras e normas, o que o ajudará a revisar se algo foi esquecido ou criado de maneira
inválida.
Conclusão
Todos estes problemas e dificuldades relatados aqui demonstram que apesar de ter uma
notação simples e da sua teoria não ser extensa, elaborar casos de uso não é 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 análise, ele é o principal entregável e durante
as demais fases, ele é base tanto para a elaboração dos diagramas na fase de desenho
do projeto, como na fase de construção onde o programador entenderá qual o
comportamento deverá ser implementado e também na fase de testes, onde será
10/4/2014 Diagrama de Casos de Uso: Principais desafios na elaboração
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=29790 11/11
possível validar se todas as funcionalidades solicitadas pelo cliente, foram disponibilizadas
no sistema.
Espero que as lições aprendidas na prática e documentadas neste artigo possam ajudar
na elaboração 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 Referências
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
Especificação UML 2.0
http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF
Gilleanes T.A. Guedes, UML 2 – Uma abordagem prática, Junho, 2010.
 
Adriano Esposito
Arquiteto Empresarial e de Soluções na Hewlett-Packard Company, com mais de 15 anos de experiência
na área de TI. Bacharel em Ciência da Computação na PUC-SP, possui especialização em Gestão de TI
pela FGV-SP. Certificado em Intel [...]