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.
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
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
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
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
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