Estudo de Caso

Introdução

A técnica de modelagem de estudo de caso é usada para descrever o que um sistema

novo deveria fazer ou qual a função de um sistema já existente. O modelo de estudo de caso é
construído através de um processo interativo de discussão entre os desenvolvedores do sistema,
e os clientes (e/ou) usuários em busca de uma solução pela qual todos estejam satisfeitos.

O estudo de caso foi criado por Ivar Jacobson, em 1994, baseado em suas experiências em
desenvolvimento do sistema AXE na Ericsson, mais especificamente o OOSE e método
Objectory (Veja Histórico). O estudo de casos têm recebido bastante atenção pela comunidade
de orientação a objetos, e têm, da mesma forma, afetado os métodos usados na orientação a
objetos.

Os componentes primários do modelo de estudo de caso são: os casos, os atores, e os

sistemas moldados. O limites do sistema são definidos pela funcionalidade proposta ao sistema.
A funcionalidade é representada por um número de estudo de casos, e cada estudo de caso
especifica uma funcionalidade completa.quando a funcionalidade está completa, o estudo de
caso deve manobrar a função inteira, desde o início, feito por um ator externo, até que ele tenha
alcançado a funcionalidade desejada no início. Um estudo de caso deve sempre retornar um
valor para o ator, de acordo com o que este ator definiu para o sistema.

O ator é qualquer entidade externa ao sistema que tenha interação com o sistema.
Normalmente, é uma pessoa, um usuário do sistema, mas pode ser, também, outro sistema, ou
algum tipo de artifício de um hardware na necessidade de interagir com o sistema.

Na modelagem de estudo de caso, o sistema é visto como uma "caixa preta" que supre o
estudo de caso. Como o sistema faz isso, como os estudo de caso são implementados, ou como
eles trabalham internamente, não é o mais importante. Na verdade, quando uma modelagem de
estudo de caso é feita no início do projeto, os desenvolvedores não tem idéia de como os casos
de uso são implementados.

Tópicos:

Objetivos

Diagramas de estudo de caso

Sistemas

Atores

Estudo de Caso
 Objetivos

Portanto, o importante é saber quais são os propósitos iniciais para o estudo de caso:

• Decidir e descrever as funcionalidades exigidas pelo sistema, resultado de um acordo

entre o cliente (e/ou usuários finais) e os desenvolvedores de software que estão
trabalhando no projeto;
• Dar uma visão clara e consistente do que o sistema deve fazer, para tanto o caso de
uso é utilizado durante todo o processo para comunicar todos os desenvolvedores os
objetivos principais exigidos pelo sistema, e para suprir as bases de uma modelagem
gráfica futura do sistema, de acordo com esses objetivos;
• Garantir uma base para que testes de verificação do sistema sejam feitos. Certificar
que os objetivo iniciais ainda sejam o foco principal do desenvolvimento do sistema.
• Providenciar uma habilidade para traçar a funcionalidade requeridas dentro das
classes e das operações do sistema. Simplificar mudanças, extensões para o sistema
(manutenção), e então, traçar o estudo de caso alterado na interface gráfica e na
implementação.

Todo este trabalho de criação de modelos de estudo de casos envolve a especificação do

sistema, conhecimento dos atores e dos usos de casos, descrevendo os usos de caso, e definido o
relacionamento entre os casos, e por fim, a validação do modelo.

O modelo de estudo de casos consiste de diagramas mostrando os atores, os casos e os

relacionamentos. Esses diagramas dão uma visão geral do modelo. Mas as principais descrições
são tipicamente textuais. Modelos visuais não podem suprir toda a informação necessária para
um modelo de estudo de caso, dessa forma, ambos, diagramas e textos são usados.

O cliente, e o usuário devem estar interessados porque o estudo de caso especifica a

funcionalidade do sistema e descreve como o sistema poderá ser usado. É de grande utilidade
quando o consumidor participa ativamente do processo de criação de estudo de caso, porque o
modelo acaba por se adaptar em detalhes aos desejos, e necessidades do usuário.

O modelo de estudo de caso representa a visão do caso de uso do sistema. Esta visão é
muito importante, pois influencia todas as outras visões do sistema. Tanto a arquitetura lógica
quanto a física são afetadas pelo estudo de caso, pois as funções especificadas no estudo de caso
são implementadas nessas arquiteturas.

A modelagem de estudo de caso não apenas captura as necessidades de um novo sistema,

mas também é usada para a geração de novos sistemas a serem desenvolvidos. Quando uma
nova geração (versão) do sistema é desenvolvida, uma nova funcionalidade é acrescentada para a
extensão do modelo do caso de uso basta adicionar novos atores ou casos, ou modificando as
especificações de casos já existentes. No entando, deve se tomar cuidado quando se modifica um
caso de uso para uma extensão para que a funcionalidade inicial não seja prejudicada.
 Diagramas de estudo de casos

Um modelo de estudo de caso é descrito em UMl como um diagrama de caso de uso, e

este modelo pode ser dividido em vários diagramas de estudo de casos. Um diagrama desses deve
conter elementos do modelo para o sistema, os atores, e os estudo de casos, e mostrar diferentes
relacionamentos como generalização, associação e dependência entre os elementos.

A descrição real de diagrama de estudo de caso normalmente contem m texto completo.

Em UML, a descrição é tratada como um documentação própria dos elementos de estudo de
caso. Essa descrição contém informações vitais para a definição nas necessidades reais da
funcionalidade. Como uma alternativa para descrever o estudo de caso em forma de texto,
pode-se desenhar o diagrama. Contudo, é importante lembrar que o estudo de caso deve ser
facilmente compreendido pelo usuário final, e uma estrutura mais formal como um diagrama
ativo, pode intimidar as pessoas a interpretá-lo.
Veja a Figura

Sistemas

Como parte da modelagem do estudo de caso, os limites do sistema desenvolvido são

definidos. (É importante que se tenha em mente que um sistema não é necessariamente um
sistema de software, pode ser uma máquina, ou um negócio). Definir os limites e a todas as
responsabilidades do sistema não é sempre fácil, pois não é sempre óbvio quais questões são
melhores automatizadas por um sistema que pode ser executado manualmente, ou por outros
sistemas.

Um sistema em um diagrama de caso de uso é descrito em uma caixa, o nome deve

aparecer acima, ou dentro da caixa.

Atores

Um ator é alguém ou algo que interage com o sistema, é quem o que usa o sistema. Por
"interagir com o sistema" queremos dizer que o ator manda e recebe mensagens para e do
sistema, ou seja, troca informações. Em suma, atores executam os casos de uso.

Um ator é um tipo (uma classe), e não uma instância. Ele representa um papel, não um
usuário individual do sistema. Essa troca de mensagens com o sistema é bastante similar à
programação orientação a objetos, apesar de não serem tão formalmente especificados em um
caso de uso. Um caso de uso é sempre inicializado por uma mensagem enviada por um ator, o
que chamamos de estímulo. Quando um caso de uso é executado, espera-se que ele envie
mensagens para um ou mais atores.

Atores também podem ser definidos como ativos ou passivos. Um ator ativo é aquele
inicializa o estudo de caso, enquanto que o passivo nunca inicia um estudo de caso, mas apenas
participa de outros usos de caso. Quando se identifica um ator, está se estabelecendo uma
entidade interessada em usar e interagir com o sistema.
 Um ator deve possuir a mesma associação com um ou mais casos de uso. Apesar do ator
não ter inicializado o caso de uso, o ator irá em algum momento se comunicar com um. O ator
recebe um nome que reflita seu papel no sistema.

Atores em UML

Tendo em mente que em UML existem classes com tipos <<ator>>, e que o nome da classe é
o nome do ator (como dito acima, refletindo seu papel), uma classe ator, como outra qualquer,
possui atributos e métodos, bem como documentação própria descrevendo o ator. Uma classe
ator possui padrão de representação que é o "homem palitinho", como o nome do ator abaixo
da figura.
Veja a Figura

Relacionamento entre Atores

Como atores são classes, eles tem os mesmos relacionamentos de uma classe normal. No
diagrama de caso de uso, apenas relacionamentos de generalização são usados para descrever o
comportamento normal entre atores. (Veja Gereneralização)
Veja a Figura

Estudo de Caso

Introdução

Um caso de uso representa uma funcionalidade completa, como percebida pelo ator. Um
caso de uso em UML é definido como um série de ações em seqüência que um sistema executa
que produzem um resultado de valor notável para o ator. As ações podem envolver
comunicação com vários atores (usuários ou sistemas), bem como performar cálculos e
trabalhos internos no sistema.

As características de um estudo de caso são:

• Um estudo de caso é sempre iniciado por um ator: é sempre executado em parte por
um ator. O ator deve direta ou indiretamente ordenar que o sistema utilize um estudo
de caso.
• Um estudo de caso devolve um valor ao ator: Um estudo de caso deve enviar algum
tipo de valor tangível ao usuário.
• Um estudo de caso é completo: um estudo de caso deve possuir uma descrição
completa. Um erro comum seria dividir o caso em casos menores que acabam não
completando um ao outro. Um caso de uso não está completo até que se acabe o
processamento do valor, mesmo que várias comunicações (como o uso de diálogos)
sejam necessários ao longo do processo.

estudo de casos está ligados aos atores através de associações, que são as vezes chamadas de
associações de comunicações. As associações mostram qual ator está se comunicando, incluindo
o ator que iniciou a execução de caso de uso. A associação é normalmente de um-pra-um, e
sem direção. Isso significa que uma instância de ator se comunica com outra instância de estudo
de caso, e que isso ocorre nas duas direções. Um estudo de caso recebe o nome de que caso
performa.

Um caso de uso é uma classe, não uma instância. Ele descreve a funcionalidade como um
todo, incluindo possibilidades alternativas, erros e exceções que podem ocorrer durante o
processo do estudo de caso. Um instanciamento do estudo de caso é chamado de scenario (em
português cenário), e ele representa o uso real do sistema (uma execução específica através do
sistema)
Veja a Figura

Estudo de Casos em UML

Um estudo de caso é representado em UML como ema elipse contendo o seu nome dentro
ou abaixo dela. Um caso de uso é geralmente alocado dentro dos limites do sistema, e pode
estar ligado a um ator com uma associação ou uma associação de comunicação que mostra
como usar o caso e como o ator interage com ele.
Veja Figura

Relacionamentos entre Casos de Usos

Existem 3 tipos de relacionamentos entre casos.

• Relacionamento por extensão: é um tipo de herança, onde um caso de use é uma

extensão de outro através da adição de ações do caso geral. O usa da extensão pode
incluir o comportamento da classe que está sendo herdada, dependendo das condições
de extensão;
• Uso de Relacionamento: é outro relacionamento de generalização onde um caso de
uso, porém outro estudo de caso indicando que como parte especializada do caso de uso,
o comportamento do caso de uso geral (classe mãe), também será incluído;
• Agrupamento: quando um número de casos de uso apresentam funcionalidades
semelhantes, ou de alguma forma relacionadas, eles podem ser colocados juntos num
pacote UML. Um grupo de pacotes relaciona um modelo de elementos, e pode ser
expandido ou quebrado, permitindo ao desenvolvedor visualizar um pacote de cada vez.
O pacote não possui nenhum outro significado semântico.

Descrevendo estudo de casos

Como já foi mencionado várias vezes, a descrição do estudo de casos é normalmente fetita
através de uma descrição textual. Esta é uma forma simples e consistente de especificação de
como os atores e os usos de casos (sistemas) interagem. Isso contrasta com o comportamento
externo do sistema. A terminologia da linguagem usada na descrição é a mesma da usada por
consumidores/usuários do sistema:

O texto de descrição inclui:

• Objetivos para o caso de uso: Quais são os objetivos finais do caso de uso?! O que
se quer alcançar?! O estudo de caso é orientado a objetivos, e os os objetivos de cada caso
de uso devem aparecer.
• Como o estudo de caso é inicilaizado: Que ator inicializa a execução do estudo de
caso. E em quais situações.
• A fluência das mensagens entre os atores e os casos de uso. Que mensagens ou
acontecimentos, o ator do caso de uso troca: atualizada, ou não, e ajuda em outras
decisões.
• A fluência alternativa no caso de uso: um caso de uso pode ter execuções
alternativas dependendo das condições ou exceções. É importante mencionar isso, mas é
preciso também ser cauteloso para não descrever em muitos detalhes, já que eles devem
escondem a fluência principal da ação no caso geral.
• Como um caso de uso termina com um valor para um ator: descrever quando um
caso de uso é considerado terminado e que tipo de valor ele retorna ao ator.

Lembrar-se que a descrição identifica o que é feito de relevante pelo ator externo, e não
como as coisas são feitas dentro do sistema. O texto precisa ser claro e consistente para que o
consumidor possa entender e validá-lo. Evitar sentenças complicadas que dificultem a
interpretação.

Um caso de uso pode também ser descrito através de um diagrama mostrando a seqüência
de atividades, suas ordens e as decisões opcionais que são feitas para indicar que atividade será
executada em seguida.

Como complemento para o caso de uso descrito, que contém uma completa e geral
descrição, um número real de cenários são usados para ilustrar o que acontece, com ambos, os
atores e os casos em suas respectivas instâncias definidas. É importante não esquecer que o
scenario é apenas um complemento e não um substituto para a descrição do caso.

Depois que os casos de uso são descritos, uma atividade específica revela se os
relacionamentos previamente estabelecidos descritos estão identificados. Os desenvolvedores
não tem conhecimento completo para identificar os relacionamentos cabíveis, até que todas as
classes estejam descritas, além de ser arriscado o fazer sem essas informações.

http://www.umlsusie.hpg.ig.com.br/casoUso.htm, acesso em 29/04/2005