O documento discute diagramas UML de casos de uso. Resume os principais pontos como: (1) UML é uma linguagem para modelagem de software que inclui diagramas estáticos, dinâmicos e funcionais; (2) Diagramas de casos de uso descrevem o que um sistema faz e incluem casos de uso, atores e o sistema; (3) Casos de uso representam funcionalidades do sistema enquanto atores representam entidades externas que interagem com o sistema.

1. DIAGRAMAS UML
Diagramas de Caso de Uso (Use Case)

2. AGENDA
 Revisão UML
 Definição
 Motivação
 Objetivo
 Diagramas
 Diagrama de Caso de Uso
 Conceitos
 Componentes
 Associações
 Exemplos
 Exercício
2

3. UML - UNIFIED MODELING
LANGUAGE
 Uma linguagem para visualização, especificação,
construção e documentação de artefatos de um software
em desenvolvimento.
 Notação independente de processos
3

4. UML - UNIFIED MODELING
LANGUAGE
 Motivação
 Enumerar as etapas mais importantes do software
 Facilitar a especificação dos requisitos do software
 Padronização para facilitar a comunicação entre os
Analistas de Requisitos e Desenvolvedores
 Criação de modelo independente de implementação
4

5. UML - UNIFIED MODELING
LANGUAGE
5

6. UML - UNIFIED MODELING
LANGUAGE
 Objetivo
 Auxiliar na especificação
 Documentação
 Visualização lógica do desenvolvimento
 Disponibilizar vários tipos de diagramas para
descrição do sistema
6

7. UML - UNIFIED MODELING
LANGUAGE
 Diagramas
 Estáticos
 Dinâmicos
 Funcional
7
Diagrama de Classes
Diagrama de Objetos
Diagrama de Casos de Uso

8. UML - UNIFIED MODELING
LANGUAGE
 Diagramas
 Estáticos
 Dinâmicos
 Funcional
8
Diagrama de Estados
Diagrama de Sequencia
Diagrama de Colaboração
Diagrama de Atividades

9. UML - UNIFIED MODELING
LANGUAGE
 Diagramas
 Estáticos
 Dinâmicos
 Funcional
9
Diagrama de Componentes
Diagrama de Execução

10. UML - UNIFIED MODELING
LANGUAGE
10

11. UML - UNIFIED MODELING
LANGUAGE
 Diagramas
 Estáticos
 Dinâmicos
 Funcional
11
Diagrama de Classes
Diagrama de Objetos
Diagrama de Casos de Uso

12. CONCEITOS
 Use Case é uma técnica de modelagem utilizada
para descrever o que um sistema deverá fazer ou
o que um sistema existente já faz.
 Este modelo é construído através de um processo
de discussões entre os desenvolvedores e
usuários.
12

13. CONCEITOS
 Os componentes primários de um modelo use
case são os :
 use cases
 atores (actors)
 sistema modelado
 Nota: As fronteiras do sistema são definidas pela
funcionalidade que é tratada pelo sistema. A
funcionalidade é representada por um número de use
cases e cada um deve especificar uma funcionalidade
completa.
13
U s u á r io
P o lí t ic a d e a s s in a t u r a

14. CONCEITOS
 Um use case deve sempre entregar algum valor
para o ator, geralmente o que o mesmo está
esperando do sistema.
 O ator, de forma geral, é o homem usuário do
sistema, mas pode ser outro sistema ou algum
tipo de hardware que precise interagir com o
sistema.
14

15. CONCEITOS
 Na modelagem o sistema é tratado como uma
caixa preta, dentro do qual estão os casos de uso.
15
Sistema
U s u á r io
C o n s u lt a r p r o d u t o s
E f e t u a r V e n d a s
C a d a s t r o d e C lie n t e s
U s u á r io V e n d e d o r

16. CONCEITOS
 O modelo use case representa a visão do sistema.
Esta visão é muito importante uma vez que esta
pode afetar todas outras visões do sistema.
16

17. DIAGRAMA DE USE CASE
 Um modelo use case é descrito como um
“diagrama use case” e este modelo pode ser
dividido em um número de diagramas de use
case.
 Os diagramas de use case possuem
relacionamentos entre si como especialização,
agregação, associação, etc.
17

18. DIAGRAMA DE USE CASE
 Exemplo
18

19. PARTES COMPONENTES
 Sistema
 Parte do modelo use case, que define os limites do
sistema desenvolvido. Pode ser um negócio ou uma
máquina.
19
Sua representação gráfica é uma
caixa, onde o nome do sistema
aparece em sua parte superior.
ControleEstoque

20. PARTES COMPONENTES
 Atores
 Parte do modelo use case, que define os elementos
responsáveis pela interação com o sistema, enviando ou
recebendo mensagens.
20
Cabe notar que o ator não é a
instância, mas a classe. Não
representa a pessoa, mas o
papel que a mesma desempenha
no sistema. U s u á r io

21. PARTES COMPONENTES
 Atores
 Uma pessoa pode ser diferentes atores em um sistema
(é bom entender o conceito de ator como “papel
desempenhado”).
21
O papel de cada ator pode ser
limitado por regras (roles)
impostas pelo sistema.
Geralmente o nome do ator está
relacionado com estas regras. U s u á r io
< < a c to r > >
U s u a r io d o s is te m a

22. PARTES COMPONENTES
 Use case
 Representa a funcionalidade percebida por um ator. É
um conjunto de sequências de ações que um sistema
desenvolve para um determinado ator (papel).
22
Podem envolver comunicação
com outros atores bem como
operações dentro do sistema.
U s u á r io
CadastrarCliente

23. PARTES COMPONENTES
 Use case
 Características:
 é sempre inicializada por um ator
 sempre devolve um valor para um ator
 possui descrição completa e podem se relacionar entre si
 Como descobrir use cases:
 Que funções o ator necessita do sistema?
 O ator precisa ler, criar, modificar, destruir algum tipo de
informação do sistema?
 O ator deve ser notificado sobre eventos do sistema? O que
estes tem a ver com sua funcionalidade?
 Que tipo de i/o o sistema precisa? De onde e para onde vai?
23

24. PARTES COMPONENTES
 Use case
 A representação de um diagrama de use case contém os
diversos use cases de um sistema.
24
U s u á r io
C o n s u lt a r p r o d u t o s
E f e t u a r V e n d a s
C a d a s t r o d e C lie n t e s
U s u á r io V e n d e d o r
Sistema de Vendas

25. PARTES COMPONENTES
 Identificando atores:
 Identificando os atores, estabelecemos quais entidades
estão interessadas em interagir com o sistema. Isto pode
ser descoberto perguntando-se:
 Quem utilizará as principais funcionalidades do sistema?
 Quem precisará do sistema para tarefas diárias?
 Quem precisará manter e administrar o sistema, mantendo-
o funcional?
 Que dispositivos de hw o sistema necessitará manipular?
 Que outros sistemas este precisará manipular?
 A quem interessará os resultados que o sistema produzir?
25

26. ASSOCIAÇÕES DE CASOS DE USO
 Inclusão
 Ocorre quando há uma parte do comportamento que é
semelhante em mais de um caso de uso.
26

27. ASSOCIAÇÕES DE CASOS DE USO
 Generalização
 Ocorre quando um caso de uso possui funcionalidades
adicionais a um já existente (o conceito de herança é
valido para use-case, também).
27

28. ASSOCIAÇÕES DE CASOS DE USO
 Extensão
 Semelhante à generalização. O caso de uso estendido
pode acrescentar comportamentos para o caso de uso-
base, declarando os “pontos de extensão” e o caso de
uso de extensão pode acrescentar comportamento
adicional somente nos pontos de extensão.
28

29. EXEMPLO
 Sistema de compras
29
C o m p r a d o r
V e r p r e ç o
C o m p r a r p r o d u t o
n a c io n a l
< < in c lu d e > >
C o m p r a r p r o d u t o
I m p o r t a d o
C o n v e r t e r M o e d a
V e r p r e ç o e m R e a l
< < in c lu d e > >
< < in c lu d e > >
Ver preço em Real é comparar preços
de diversos distribuidores cujos
valores estão em moeda estrangeira, o
que necessariamente implica ainda na
conversão entre moedas.
Ver preço é comparar preços
de diversos distribuidores cujos
valores estão em moeda corrente

30. CASOS DE USO
 Casos de uso do negócio
 Representa como a aplicação responde ao cliente ou a
um evento externo. Trata o sistema como uma “caixa
preta”, ocultando suas funções internas.
 Casos de uso do sistema
 Representa a interação com o software. Esta deve
satisfazer cada situação (use case) pertencente aos
casos de uso do negócio.
 De forma geral, podem ser elaborados um conjunto de
casos de uso de sistema para cada caso de uso de
negócio identificado.
30

31. CASOS DE USO
 Casos de uso do negócio e de sistema
31
Usuário
Consultar produtos
EfetuarVendas
Cadastrar Clientes
UsuárioVendedor
Sistema de Vendas
Calcular nr de CPF
Conferir preenchimento
do formulário e inserir
no banco de dados
ValidaçãoCliente
Negócio
Sistema
Calcular Total Pedido
Preecher formulário
da nota fiscal
ValidaçãoPedido
Sistema

32. EXEMPLO – ESPAÇO FÍSICO - UFBA
 Problema:
Organização e utilização do espaço físico da UFBA
para eventos.
Salas Reservadas para mais de 1 evento no mesmo
dia.
Problema de calendário para seminários SisBic.
32

33. EXEMPLO – ESPAÇO FÍSICO UFBA
33

34. EXEMPLO – ESPAÇO FÍSICO UFBA
34

35. EXERCÍCIOS
Da entrevista com o responsável da biblioteca de uma
universidade resultou a seguinte descrição para um
novo sistema:
“A atividade da biblioteca centra-se principalmente no
empréstimo de publicações pelos alunos da
universidade. O empréstimo é registrado pelos
funcionários da biblioteca, que também consultam
diariamente os empréstimos cujos prazos foram
ultrapassados. Todo este processo é efetuado
manualmente, sendo muito ineficiente.
Espera-se que o novo sistema resolva esta situação. Os
alunos necessitam de pesquisar os livros existentes na
biblioteca. Caso um livro esteja requisitado é mostrada a
data esperada de entrega”. 35