Академический Документы
Профессиональный Документы
Культура Документы
Relatório Técnico
RT.2012.CCO/SI.01.00
Abril – 2012
Índice
1. Objetivo do Documento ..............................................................................................3
RT.2012.CCO/SI.01.00 Page 2
1. Objetivo do Documento
Este documento tem por objetivo servir como guia aos alunos dos cursos de Ciência da
Computação e Sistemas de Informação da Universidade Salvador (UNIFACS) para a
elaboração de um modelo de casos de uso.
Existem bons livros disponíveis aqui no Brasil que tratam sobre o tema de elaboração
de modelos de casos de uso. No entanto, uma razão que me levou a escrever este
relatório técnico foi o fato que muitos desses livros acabam dando maior ênfase à
notação que deve ser utilizada no diagrama de casos de uso e não orientam na
elaboração de modelos de casos de uso. Certamente, essa notação é importante para
qualquer projetista, mas, igualmente importante, é entender como aplicar essa
notação na modelagem de um domínio de problema.
Em vista do comentado acima, este relatório não tem como objetivo ser uma
referência completa sobre a notação de modelos de casos de uso, definida pela UML
(Linguagem de Modelagem Unificada), e nem como referência para aprender todos os
conceitos básicos relacionados. Este documento tem como objetivo apresentar
diretrizes que orientem, principalmente a iniciantes da modelagem orientada a
objetos, na elaboração de modelos de casos de uso, mostrando passo a passo, como
aplicar os diferentes conceitos em um caso prático.
RT.2012.CCO/SI.01.00 Page 3
2. Conceitos Básicos
RT.2012.CCO/SI.01.00 Page 4
departamento de uma empresa. Um ator representa os papéis que o usuário do
sistema pode desempenhar.
• Quando existe um comportamento comum para vários casos de uso. Neste caso,
esse comportamento pode ser separado e modelado como um caso de uso de inclusão
associado aos vários casos de uso que contêm este comportamento.
RT.2012.CCO/SI.01.00 Page 5
Figura 3. Representação de um caso de uso de inclusão.
A representação é uma linha tracejada do caso de uso estendido para o caso de uso de
base, acrescida do estereótipo <<extend>>, como descrito na Figura 4.
Nas próximas seções são apresentadas diversas diretrizes para elaborar um modelo de
casos de uso e para documentar os elementos do diagrama de casos de uso.
• Identificar atores
RT.2012.CCO/SI.01.00 Page 7
• Descrever atores
O primeiro passo a ser realizado é definir a fronteira (alcance do sistema). Uma vez
definida a fronteira, é importante pensar primeiro nos atores. A idéia por trás de casos
de uso é decidir para que o sistema será usado antes de decidir o que o sistema irá
fazer. Se alguém modela o sistema pensando primeiro nos casos de uso e depois nos
atores, está com um problema sério, pois quer dizer que ainda não entendeu a
filosofia de modelo de casos de uso. Vale a pena lembrar que um modelo de casos de
uso deve ser modelado a partir da perspectiva do usuário e não do desenvolvedor.
Portanto, se vamos colocar o usuário no centro de nossas preocupações, então os
atores devem ter prioridade número um nas nossas atividades. Uma vez identificados
os atores, os mesmos precisam ser documentados, isto é, deve ser elaborada uma
breve descrição sobre o que representa cada um deles. Logo após, devem ser
identificados os casos de uso, que são as metas ou serviços do sistema utilizados pelos
usuários. Elabora-se uma descrição sucinta de cada caso de uso, de forma a deixar
claro o objetivo do mesmo. A seguir, são definidas as associações entre atores e casos
de uso e elabora-se o diagrama de casos de uso. Depois deve ser elaborada a descrição
passo a passo de cada caso de uso, considerando os diversos cenários possíveis para
esse processo de negócio, e por último, é realizado um refinamento tanto do diagrama
como da documentação associada.
RT.2012.CCO/SI.01.00 Page 8
d) Que pessoas, órgãos, empresas, sistemas ou grupos de usuários receberão
informações do sistema?
Observação: existem atores que não iniciam nenhum caso de uso, mas são “tocados”
por casos de uso, isto é, simplesmente recebem informações do sistema.
Podem ser utilizadas algumas perguntas básicas com a finalidade de obter os principais
casos de uso:
Observação: uma vez identificados os casos de uso, eles devem ser trazidos para
análise da equipe de desenvolvimento, somente depois devem ser especificados
detalhadamente.
Os casos de uso podem ser descritos com diferentes níveis de detalhamento, isto
depende da metodologia adotada pela equipe de desenvolvimento. Na fase de análise,
quando o objetivo é estudar o sistema para descobrir as necessidades do cliente, usa-
se a descrição essencial de caso de uso, que consiste na definição do nome do caso de
uso, uma breve descrição do objetivo do mesmo e citar os atores primários. No
entanto, na fase de projeto, quando a meta é produzir uma solução implementada de
um sistema para o cliente, deverá ser realizada a descrição detalhada do caso de uso,
também conhecido como caso de uso expandido, onde inclui a especificação dos
diferentes fluxos possíveis dentro desse contexto.
Cada caso de uso deve ser descrito de forma a contemplar todos os cenários possíveis.
Geralmente, estes cenários são organizados em três grupos:
RT.2012.CCO/SI.01.00 Page 9
Quando existir mais de um cenário que possa ser candidato do fluxo básico ou
principal, o analista deve escolher o mais utilizado ou aquele que melhor retrata o caso
de uso, deixando os outros como alternativos.
Um caso de uso deve descrever o que deve ser feito e quem faz, mas nunca deve ser
descrito o como. Deve-se evitar descrever qualquer processo interno do sistema (ex.
deve-se armazenar os dados do pagamento do empréstimo na tabela Pagamento do
banco de dados).
(opcional) Ator primário: indicar o nome ou nomes de atores que iniciam o caso de
uso.
RT.2012.CCO/SI.01.00 Page 10
Fluxos alternativos: colocar um título para cada fluxo alternativo. Enumerar os passos,
indicar o número do passo do fluxo principal ou outro fluxo do qual é derivada e
especificar onde continua, se retorna ao fluxo principal ou se o caso de uso é
encerrado.
Fluxos de exceção: colocar um título para cada fluxo de exceção. Enumerar os passos,
indicar o número do passo do fluxo principal ou outro fluxo do qual é derivada e
especificar onde continua, se retorna ao fluxo principal, alternativo ou se o caso de uso
é encerrado.
Extensões: citar os casos de uso que estendem o caso de uso que está sendo
especificado.
Inclusões: citar os casos de uso que são incluídos pelo caso de uso que está sendo
especificado.
Revisar a especificação de um caso de uso não é uma tarefa trivial, pois requer de um
certo esforço e de muita concentração. Um aspecto importante a ressaltar é que duas
pessoas que descrevem um caso de uso do mesmo processo de negócio,
provavelmente especificarão uma seqüência de passos diferentes, pois cada pessoa
tem a sua própria lógica. Porém, todo caso de uso tem passos obrigatórios. Esses
passos envolvem as informações que de alguma forma passam dos atores para o
sistema, e do sistema para os atores, sem os quais o caso de uso não faz sentido ou
não pode prosseguir. Esses passos devem constar em qualquer caso de uso expandido
(descrição detalhada do caso de uso), e a falta deles faz com que o caso de uso esteja
incorretamente descrito.
Os casos de uso devem ser descritos de forma simples o bastante para que os usuários
entendam e verifiquem, mas preciso o bastante para que os analistas e projetistas
possam utilizar como modelo base para a construção do sistema.
RT.2012.CCO/SI.01.00 Page 11
Em relação à revisão da consistência da especificação de um caso de uso, recomenda-
se realizar as seguintes perguntas:
• O caso de uso especifica a informação que o ator precisa saber para atingir seu
objetivo?
• O caso de uso especifica a informação que o sistema precisa possuir para atender o
objetivo da solicitação do ator?
RT.2012.CCO/SI.01.00 Page 12
Esta afirmação costuma ser o erro mais freqüente entre os profissionais iniciantes na
modelagem de casos de uso. Um requisito funcional nem sempre corresponde a um
caso de uso. Acontece que um caso de uso representa um processo de negócio, isto é,
um conjunto de ações com início, meio e fim. Porém, um requisito funcional nem
sempre se refere a um processo de negócio, muitas vezes o requisito funcional é
simplesmente uma única ação. A seguir são especificados dois requisitos funcionais
referentes à compra de passagens pela Internet:
- Requisito 2: O sistema deve permitir que o usuário possa selecionar o vôo desejado.
Fluxo Principal:
RT.2012.CCO/SI.01.00 Page 13
ERRO 8: Na especificação de um caso de uso deve ser detalhado o processamento
interno do sistema.
Os casos de uso devem mostrar o que é feito e por quem é feito, mas nunca o como.
Um erro freqüente é especificar detalhes de implementação na especificação de um
caso de uso (ex. citar o nome do banco de dados ou da tabela onde serão
armazenados os dados referentes ao processo de negócio modelado). O projetista
deve-se lembrar que a descrição ou especificação de um caso de uso não deve mudar
quando mudam os detalhes de implementação, pois o caso de uso representa o
processo de negócio, portanto, ele somente pode mudar quando existe alguma
alteração ou mudança no próprio processo de negócio.
RT.2012.CCO/SI.01.00 Page 14
sistema, mas não como será feita esta autenticação, pois amanhã ou depois esta
autenticação pode mudar (ex. reconhecimento de voz), mas o caso de uso não deve
mudar por causa desta alteração. A autenticação no sistema ou identificação do
usuário no sistema geralmente recomenda-se colocar como uma pré-condição do caso
de uso.
Uma pré-condição é uma restrição que precisa ser verdadeira ANTES que inicie o caso
de uso. Portanto, a mesma não deve ser verificada dentro da especificação do caso de
uso.
Para cada fluxo alternativo ou fluxo de exceção deve ser especificado como esse fluxo
começa (indicar o passo do fluxo principal ou de outro fluxo da onde vem), quais ações
são tomadas e como o caso de uso continua.
10. Exemplo
RT.2012.CCO/SI.01.00 Page 15
disponibilidade de passagens”, dentro do contexto de um Sistema de Compras de
Passagens Aéreas via Web. Na Figura 7, apresenta-se o diagrama de casos de uso
correspondente.
Fluxo Principal:
- quantidade de adultos;
- quantidade de crianças.
RT.2012.CCO/SI.01.00 Page 16
4. Sistema seleciona os voos disponíveis correspondentes ao critério de busca (RN03).
5. Sistema calcula valor da passagem dos voos disponíveis que satisfazem os dados
informados .
6. Sistema exibe voos disponíveis (data e número do vôo, hora de saída e chegada,
escalas e/ou conexões, preço e taxas de embarque);
Fluxos alternativos:
Fluxo de exceção:
RT.2012.CCO/SI.01.00 Page 17
E2. Data de ida maior à data atual
E2.2. O Sistema mostra a seguinte mensagem "A data de ida deve ser maior à
data atual"
E3.1. No passo 5 do fluxo principal o sistema identifica que não existem voos
diponíveis para o critério de busca informado pelo cliente.
Inclusões: Nenhuma
BIBLIOGRAFIA RECOMENDADA
BEZERRA, Eduardo, Princípios de Análise e Projeto de Sistemas com UML. 2ª. ed. Rio de
Janeiro: Campus, 2006.
DOUG, R.; KENDALL S. Applying Use Case Driven Object Modeling with UML. Addison-
Wesley. 2001.
RT.2012.CCO/SI.01.00 Page 18
GEDES, G. TA. A. UML: Uma Abordagem Prática. Novatec. 2004
RT.2012.CCO/SI.01.00 Page 19