Diagrama de caso de uso UML

Prévia do material em texto

Técnicas de Programação I
Professora Dra. Edna Dias Canedo
ednacanedo@unb.br
edna.canedo@gmail.com
Departamento de Ciência da Computação
Profª Dra. Edna Dias Canedo
Metodologias que se tornaram 
populares nos anos 90:
 Grady Booch
– Método para desenvolvimento orientado a
objetos disponível em muitas versões.
– Definiu a noção de que um sistema é analisado
a partir de um número de visões, onde cada
visão é descrita por um número de modelos e
diagramas.
– Simbologia complexa de ser desenhada a mão.
Profª Dra.Edna Dias Canedo
 OMT – Técnica de Modelagem de Objetos
– Método desenvolvido pela GE (General Electric)
onde James Rumbaugh trabalhava.
– Voltado para o teste dos modelos, baseado nas
especificações dos requisitos do sistema.
– Composto pela junção dos modelos de objetos,
funcional e use-cases.
Metodologias que se tornaram 
populares nos anos 90: 
Profª Dra.Edna Dias Canedo
 OOSE/Objectory
– Métodos OOSE e o Objectory foram desenvolvidos
baseados no mesmo ponto de vista formado por
Ivar Jacobson.
– O OOSE é a visão de Jacobson de um método
orientado a objetos.
– O Objectory é usado para a construção de sistemas
tão diversos quanto eles forem.
– Ambos os métodos são baseados na utilização de
use-cases, que definem os requisitos iniciais do
sistema, vistos por um ator externo.
Metodologias que se tornaram 
populares nos anos 90: 
Profª Dra.Edna Dias Canedo
 Cada um destes métodos possui sua própria
notação (seus próprios símbolos para representar
modelos orientado a objetos), processos (que
atividades são desenvolvidas em diferentes partes
do desenvolvimento), e ferramentas (as
ferramentas CASE que suportam cada uma destas
notações e processos).
Metodologias que se tornaram 
populares nos anos 90: 
Profª Dra.Edna Dias Canedo
Necessidade de um padrão
 Diante da diversidade de conceitos, "os três
amigos", Grady Booch, James Rumbaugh e Ivar
Jacobson decidiram criar uma Linguagem de
Modelagem Unificada.
 Disponibilizaram inúmeras versões preliminares da
UML para a comunidade de desenvolvedores e a
resposta incrementou muitas novas idéias que
melhoraram ainda mais a linguagem.
Profª Dra.Edna Dias Canedo
 Surge a UML (Unified Modeling Language) em
1996 como a melhor candidata para ser linguagem
“unificadora” de notações.
 Em 1997, a UML é aprovada como padrão.
 Desde então, a UML tem tido grande aceitação
pela comunidade de desenvolvedores de sistemas.
Necessidade de um padrão
Profª Dra.Edna Dias Canedo
UML
 É uma linguagem unificada e padronizada de
modelagem visual de objetos para:
– visualização, especificação, construção e
documentação de software;
 É um padrão aberto;
 Suporta todo o ciclo de vida de um
desenvolvimento de software;
 Suporta aplicações de diversas áreas;
 É baseada nas necessidades e experiência da
comunidade de usuário.
Profª Dra.Edna Dias Canedo
 Independente de linguagem de programação;
 Independente do processo de desenvolvimento;
 UML combina o melhor de :
– Conceitos de Modelagem de Dados
(Diagrama de Entidade Relacionamento) ,
Modelagem de Negócios (workflow),
Modelagem de Objetos , Modelagem de
Componentes.
UML
Profª Dra.Edna Dias Canedo
 Um processo de desenvolvimento que utilize a
UML envolve a criação de diversos documentos.
– Estes documentos podem ser textuais ou
gráficos.
– Documentos são denominados artefatos de
software.
– São os artefatos que compõem as visões do
sistema.
UML
Profª Dra.Edna Dias Canedo
 Os artefatos gráficos produzidos durante o
desenvolvimento de um sistema de software são
definidos através da utilização dos diagramas da
UML.
UML
Profª Dra.Edna Dias Canedo
As partes que compõem a UML
 Visões: Mostram diferentes aspectos do
sistema que está sendo modelado.
– A visão não é um gráfico, mas uma abstração
consistindo em uma série de diagramas.
– Definindo um número de visões, cada uma
mostrará aspectos particulares do sistema,
dando enfoque a ângulos e níveis de
abstrações diferentes
Uma figura completa do sistema poderá
ser construída.
Profª Dra.Edna Dias Canedo
 Modelos de Elementos: 
– Os conceitos usados nos diagramas são
modelos de elementos que representam
definições comuns da orientação a objetos
como:
 as classes, objetos, mensagem,
relacionamentos entre classes incluindo
associações, dependências e heranças.
As partes que compõem a UML
Profª Dra.Edna Dias Canedo
 Diagramas:
– Gráficos que descrevem o conteúdo em uma
visão. UML possui nove tipo de diagramas
que são usados em combinação para prover
todas as visões do sistema.
As partes que compõem a UML
Profª Dra.Edna Dias Canedo
Visões
 Os diagramas que compõem as visões contém os modelos
de elementos do sistema. As visões que compõem um
sistema são:
Profª Dra.Edna Dias Canedo
 Visão "use-case":
– Descreve a funcionalidade do sistema
desempenhada pelos atores externos do
sistema (usuários).
– A visão use-case é central, seu conteúdo é
base do desenvolvimento das outras visões
do sistema. É montada sobre os diagramas de
use-case e eventualmente diagramas de
atividade.
Visões
Profª Dra.Edna Dias Canedo
 Visão Lógica:
– Descreve como a funcionalidade do sistema
será implementada.
– É feita principalmente pelos analistas e
desenvolvedores. Em contraste com a visão
use-case, a visão lógica observa e estuda o
sistema internamente.
Visões
Profª Dra.Edna Dias Canedo
– Descreve e especifica a estrutura estática do
sistema (classes, objetos, e relacionamentos) e
as colaborações dinâmicas quando os objetos
enviarem mensagens uns para os outros para
realizarem as funções do sistema.
Visões
Profª Dra.Edna Dias Canedo
 Visão de Componentes:
– É uma descrição da implementação dos
módulos e suas dependências. É executado
por desenvolvedores, consiste nos
componentes dos diagramas.
Visões
Profª Dra.Edna Dias Canedo
 Visão de concorrência:
– Trata a divisão do sistema em processos e
processadores.
– Propriedade não funcional do sistema.
– É suportada pelos diagramas dinâmicos:
estado, seqüência, colaboração e atividade, e
pelos diagramas de implementação, que são
os diagramas de componente e execução.
Visões
Profª Dra.Edna Dias Canedo
 Visão de Organização:
– Mostra a organização física do sistema, os
computadores, os periféricos e como eles se
conectam entre si.
– Visão executada pelos desenvolvedores,
integradores e testadores. É representada
pelo diagrama de execução.
Visões
Profª Dra.Edna Dias Canedo
Modelos de Elementos
 São representados por:
– Classes
– Objetos: Em UML um objeto é mostrado como uma classe
só que seu nome (do objeto) é sublinhado, e o nome do
objeto pode ser mostrado opcionalmente precedido do
nome da classe.
Profª Dra.Edna Dias Canedo
– Estados: Objetos possuem um estado,
normalmente determinado pelos valores de
seus atributos e ligações com outros objetos.
Em sua notação, pode conter três
compartimentos.
– 1) nome do estado;
– 2) Opcional, os atributos do objeto em
questão podem ser listados e
atualizados.
Modelos de Elementos
Profª Dra.Edna Dias Canedo
– 3) Opcional, onde eventos e ações
podem ser listadas. Três eventos
padrões podem ser mostrados: entrar,
sair e fazer .
Modelos de Elementos
Profª Dra.Edna Dias Canedo
– Pacotes: é um mecanismo de agrupamento,
onde todos os modelos de elementos podem
ser agrupados.
 Em UML, um pacote é definido como: "Um
mecanismo de propósito geral para organizar
elementos semanticamente relacionadosem
grupos.“
 Possui vários modelos de elementos, e isto
significa que estes não podem ser incluídos em
outros pacotes.
Modelos de Elementos
Profª Dra.Edna Dias Canedo
– Componentes: pode ser tanto um código em
linguagem de programação como um código
executável já compilado.
Em um sistema desenvolvido em Java,
cada arquivo .java ou .class é um
componente do sistema, e será mostrado
no diagrama de componentes que os
utiliza.
Modelos de Elementos
Profª Dra.Edna Dias Canedo
Diagramas da UML
– Diagrama de Casos de Uso
– Diagrama de Classes
– Diagrama de Interação
 Diagrama de Seqüência
 Diagrama de Colaboração
– Diagrama de Estado
 Diagrama de Atividades
– Diagrama de Implementação
 Diagrama de Componentes
 Diagrama de Implantação
Profª Dra.Edna Dias Canedo
 Em UML existem 9 diagramas padrões
– Views estáticas: use-case, classe, objeto,
componente, implantação/execução.
– Views dinâmicas: seqüência, colaboração,
estados, atividades.
 UML não diz que modelos devem ser construídos.
Diagramas da UML
Profª Dra.Edna Dias Canedo
Use-Cases
 Captura a funcionalidade do ponto de vista do
usuário;
 Desenvolvido nos primeiros estágios do
desenvolvimento;
 Modelam os requisitos funcionais do sistema.
 Propósito:
– Especificar o contexto do sistema;
– Capturar os requisitos do sistema;
– Validar a arquitetura do sistema.
 Notação UML:
Manter Aula
Profª Dra.Edna Dias Canedo
Use-Cases
Emitir Relatório Manter Disciplina
Manter Material Didático Acessar Material Didático
Profª Dra.Edna Dias Canedo
Um caso de uso representa quem
faz o que (interage) com o sistema, 
sem considerar o comportamento 
interno do sistema.
Use-Cases
Profª Dra.Edna Dias Canedo
Cenários de um Caso de Uso
•Um Cenário é uma seqüência de passos que
descreve uma interação entre um usuário e um
sistema.
• De acordo com os vários papéis do ator.
•Um cenário está para um caso de uso, assim
como um objeto está para uma classe.
Profª Dra.Edna Dias Canedo
Cenário: Loja On-line (loja virtual)
Cenário: Compra de um produto on-line
1. O cliente navega pelo catálogo e seleciona itens a serem
comprados;
2. O cliente vai para o check out;
3. O cliente preenche o formulário da remessa (endereço de
entrega, opção de entrega imediata ou em três dias);
4. O sistema apresenta a informação total do faturamento
incluindo a remessa, os preços e os impostos;
5. O cliente preenche as informações de cartão de crédito;
6. O sistema autoriza a compra;
7. O sistema confirma imediatamente a venda;
8. O sistema manda uma confirmação para o cliente por e-
mail.
Profª Dra.Edna Dias Canedo
Cenários de um Caso de Uso
 Normalmente há diversos cenários para um
mesmo um caso de uso.
– A autorização do cartão de crédito pode
falhar, o que seria outro cenário.
 Um cenário é a descrição de uma das
maneiras pelas quais um caso de um pode
ser realizado.
Profª Dra.Edna Dias Canedo
Descrição do Use Case
 Cada caso de uso é definido através da
descrição narrativa das interações que ocorrem
entre o(s) elemento(s) externo(s) e o sistema.
 UML não define uma estruturação específica a 
ser utilizada na descrição de um caso de uso.
– A equipe de desenvolvimento deve utilizar o 
formato de descrição que lhe for realmente 
útil.
Use Case: Cadastrar aluno
Sumário: Este caso de uso inicia-se quando o aluno não possui cadastro e
tem a necessidade de cadastrar-se no CEAED.
Atores: Aluno
Pré-condições: Não se aplica a este caso.
Descrição: 1. O aluno seleciona no sistema a opção cadastro;
2. O sistema disponibiliza ao aluno o formulário de cadastro de
aluno, onde os campos com asteriscos são considerados de
caráter obrigatório: login, *senha, *nome, *sexo, RG, CPF
*endereço (descrição do endereço, descrição do
complemento, número, *bairro, *CEP), *cidade, *estado, *UF,
*telefone residencial, telefone celular, e-mail, *escolaridade,
*tipo de necessidade especial, *nome da mãe, nome do pai,
*RG do responsável, CPF do responsável, Nome do
responsável e *data de nascimento;
3. O aluno terá acesso aos botões: “Gravar” e “Fechar”;
4. Caso o aluno escolha à opção “Fechar”;
5. O sistema abortará a gravação dos dados e retornará à tela
inicial do CEAED;
6. Caso o aluno escolha à opção “Gravar”;
7. O sistema validará os dados cadastrados emitindo a
mensagem “Os dados foram cadastrados com sucesso!”, e
retornará a tela inicial do aluno, aplicando saudação ao
referente Aluno.
Alternativas: 1. No item dois, caso o aluno não preencha os campos
considerados obrigatórios, o sistema emitirá uma mensagem
de notificação, “Preencher campos obrigatórios”, e retornará
ao item dois da descrição de caso de uso;
2. Caso o aluno tenha a necessidade de alterar algum dado
antes da inserção na base de dados, este o fará apontando
o cursor do mouse em cima do campo em questão e
clicando sobre o mesmo, o sistema disponibilizará o cursor
intermitente no campo referenciado.
3. A opção “Fechar”, será realizada no ícone “X”.
4. Caso o Aluno tenha escolhido um subitem ou um botão por
engano, ele terá a opção de fechar, através do botão
“Fechar”, e o sistema sairá da opção escolhida, e retornará
para a tela anterior.
Exceção: Caso o aluno tenha preenchido os campos CEP, CPF e RG com
valores inválidos ou faltando algum campo obrigatório, o sistema
emitirá uma mensagem de “Dados incorretos”, mostrando os dados
incorretos e ou incompletos, retornará ao item dois;
O código e matrícula do aluno serão gerados automaticamente.
Profª Dra.Edna Dias Canedo
Atores
• Elemento externo que interage com o sistema;
•Externo”: atores não fazem parte do sistema.
•“interage”: um ator troca informações com o sistema.
• Representam um papel;
• Iniciam casos de uso.
Ator
Caso de 
Uso
Interação
Sistema
Usuário
Profª Dra.Edna Dias Canedo
• Categorias de atores:
•Pessoas (Empregado, Cliente, Gerente,
Almoxarife, Vendedor, etc);
•Organizações (Empresa Fornecedora, Agência
de Impostos, Administradora de Cartões, etc);
•Outros sistemas (Sistema de Cobrança, Sistema
de Estoque de Produtos, etc).
•Equipamentos (Leitora de Código de Barras,
Sensor, etc.).
Atores
Profª Dra.Edna Dias Canedo
Atores
Caixa Gestor de Estoque
Gestor de Compras Sistema Financeiro
Gerente Funcionario
Profª Dra.Edna Dias Canedo
Diagrama de Casos de Uso
 O propósito de um caso de uso é definir o
comportamento de uma classe sem revelar sua
estrutura interna.
 Cada Caso de Uso especifica um serviço que a
classe fornece a seus usuários.
 Procura identificar o que os usuários buscam
cumprir em termos de negócios e não as funções
que o sistema deve executar.
 Atores e use cases são classes.
Profª Dra.Edna Dias Canedo
Diagramas de casos de uso são criados para visualizar
os relacionamentos entre atores e casos de uso.
Diagrama de Casos de Uso
Efetuar Saque
Efetuar Depósito
Efetuar Transferência
Correntista
Solicitar Extrato
Aluno
Funcionário
Efetuar Empréstimo de Publicação
Profª Dra.Edna Dias Canedo
 É uma técnica usada para descrever e definir os
requisitos funcionais de um sistema.
Diagrama de Casos de Uso
Profª Dra.Edna Dias Canedo
Diagrama de Casos de Uso
Usuário
Manter Material Didático
Manter Aula
Manter Avaliação
Manter Exercícios
Professor
Manter Curso
Manter Teste de Aptidão
Administrador
Utilizar Curso Realizar Teste Aptidão
Manter Cadastro Usuário
Aluno
Use Case Visão Geral do Sistema
Profª Dra.Edna Dias Canedo
Diagrama de Casos de Uso
Use Case Manter Aula
Efetuar Login
Criar Aula
Alterar Aula
Excluir Aula
Consultar Aulas
ProfessorProfª Dra.Edna Dias Canedo
Relação “extend” entre casos de uso
A B
«extend»
caso básico extensão
•O caso de uso estendido B pode acrescentar comportamento
para o caso de uso básico A.
•o caso básico deve fazer sentido sozinho.
•os atores interagem com o caso básico (A).
•Para simplificar a descrição dos casos de uso, pode-se
organizá-los em casos básicos e extensões aos casos
básicos, que representam partes ou modalidades
acrescentadas condicionalmente (opções).
Significado
Profª Dra.Edna Dias Canedo
Relação “extend” entre casos de uso
Servir jantar
«extend»
Servir à luz de velas
Exemplos
Servir uma entrada
«extend»
«extend»
Servir uma sobremesa
Profª Dra.Edna Dias Canedo
Modificar Disciplina
Visualizar Lista de 
Disciplinas
Adicionar Disciplina
Eliminar Disciplina
«extend»
«extend»
«extend»
Visualizar Ficha de 
Disciplina
«extend»
«extend»
Relação “extend” entre casos de uso
Escritor
'Formatar Documento
Corrigir Ortografia
Editar Documento
<<extend>>
<<extend>>
Profª Dra.Edna Dias Canedo
Relação “include” entre casos de uso
• Quando vários casos de uso têm uma
subseqüência de funcionamento comum, é
conveniente separar essa parte comum para um
novo caso de uso que é incluído pelos primeiros.
• Ocorre quando há uma parte do comportamento
que é semelhante em mais de um caso de uso.
Profª Dra.Edna Dias Canedo
(parte comum a 
outros casos de uso 
além de A)
A B
«include»
Significado
Relação “include” entre casos de uso
• Uma instância do caso de utilização A inclui
obrigatoriamente o comportamento especificado por B.
• Os atores interagem com o caso de uso A.
• Na descrição textual de A: include(B).
Profª Dra.Edna Dias Canedo
Servir almoço
Pagar 
refeição
«include»
«include»
Servir jantar
Relação “include” entre casos de uso
Cliente
Efetuar Saque
Solicitar Extrato
Realizar Transferencia
Fornecer Identificação
<<include>>
<<include>>
<<include>>
Profª Dra.Edna Dias Canedo
Relação “include” entre casos de uso
Profª Dra.Edna Dias Canedo
Exemplo Extend e Includ
Profª Dra.Edna Dias Canedo
Relação “generalização” entre casos 
de uso
• Relacionamento no qual o reuso é mais
evidente.
• Este relacionamento permite que um caso de
uso (ou um ator) herde características de um
caso de uso (ator) mais genérico.
• O caso de uso (ator) herdeiro pode especializar
o comportamento do caso de uso (ator) base.
• Pode existir entre dois casos de uso ou entre
dois atores.
Profª Dra.Edna Dias Canedo
Relação “generalização” entre casos 
de uso
• A generalização entre atores significa que o
herdeiro possui o mesmo comportamento que o
ator do qual ele herda.
Profª Dra.Edna Dias Canedo
Professor
Usuário
Solicitar Compra
de Título
Reservar Livro
Devolver Livro
Realizar Pagamento
Realizar Pagamento
com Cartão de Crédito
Realizar Pagamento
com Dinheiro
Cliente
Relação “generalização” entre casos 
de uso
Profª Dra.Edna Dias Canedo
Diagrama de Atores
Usuário
Administrador ProfessorAluno
Profª Dra.Edna Dias Canedo
Exercício
1) Construa o diagrama de atores para o seu minimundo do
projeto.
2) Construa o diagrama de casos de uso do minimundo.
3) Descreva os 03 casos de uso principais do seu minimundo.