Engenharia de Software

Engenharia de Software II
Profa. Dra. Ana Paula Gonçalves Serra

Prof. Dr. José Antonio Fonseca
Visão Geral da UML

Modelo de Caso de Uso
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca
Sumário
 Introdução
 Visão Histórica
 Tipos de Elementos Básicos
 Tipos de Relações
 Tipos de Diagramas Principais
 Mecanismos Comuns do UML
 Objetivos da UML 2.0
2
Introdução (I)
 UML : Unified Modeling Language
– Linguagem para especificação, construção, visualização e
documentação de artefatos de um sistema.
– Standard da OMG (Object Management Group)
– Adotado por empresas e instituições de todo o mundo
– Existem mais de 50 ferramentas comerciais e acadêmicas para
modelagem com UML.
3
Introdução (II)
 UML – Características principais
– Semântica e notação para tratar um grande número de tópicos
atuais de modelagem
– Semântica para tratar tópicos de modelagem futura
» tecnologia de componentes, computação distribuída,

frameworks e Internet.
– Mecanismos de extensão que permitem que futuras aproximações

e notações possam usar UML.
– Semântica e sintaxe para facilitar a troca de modelos entre

ferramentas distintas.
4
Introdução (III)
 UML – Objetivos na sua concepção
– Definição de uma linguagem de modelagem padrão
» Independente da linguagem de programação, ferramentas CASE e

processo de desenvolvimento.
» Para diferentes projetos, diferentes metodologias, mas a mesma

linguagem de modelagem
– Independente das ferramentas de modelagem
» Apesar de sugerir algumas ideias na apresentação, não aborda todos

os requisitos necessários, por não ser esse o seu objetivo.
– Simplicidade
– Coerência na unificação de elementos de outras notações (Booch, OMT,

OOSE, …)
5
Visão Histórica
2000- 2004 UML2.0
2001 Industrialização
UML1.4
Jan1997 UML1.0
Normalização
Jun1996 UML0.9 UML Partners
Unificação
Out1995 Unified Method0.8
Booch’93 OMT-2
Fragmentação
Outros
OOSE Booch’91 OMT-1 Métodos
6
Tipos de Elementos Básicos (I)
 Estrutura de Conceitos
– Conjunto variado de notações, as quais podem ser aplicados em diferentes
domínios de problemas e a diferentes níveis de abstração.
– (1) “coisas” ou elementos básicos através dos quais se definem os modelos.
– (2) relações, que relacionam elementos
– (3) diagramas, que definem regras de agrupamento de elementos
7
Tipos de Elementos Básicos (II)
 Principais elementos da estrutura

– Classes, Objetos, Interfaces, Casos de Uso, Atores, Colaborações, Componentes,
Artefatos e Nós.
– Elementos de especificação de comportamento (estados e atividades)
– Elementos de agrupamento (pacotes e fragmentos)
– Anotações e restrições
Classe
Objeto
Pacote Estado
Nó
Caso de Uso Atividade Anotação
Componente
Ator
8
Tipos de Relações
 Relações
– Sintaxe e semântica bem definidas
– Permitem o estabelecimento de interdependências entre os elementos básicos vistos
anteriormente.
 Tipos
– Associação
– Dependência
– Realização
– Generalização
– Agregação
9
Tipos de Diagramas Principais (I)
 Diagramas
– Possibilidade de agrupar elementos básicos e as suas relações de
uma forma lógica ou que estruturalmente faça sentido.
– “Nenhum modelo é suficiente por si só. Qualquer sistema não-trivial é
melhor representado através de um pequeno número de modelos
razoavelmente independentes”
– Três categorias de diagramas : Comportamento, Interação e Estrutura.
10
Tipos de Diagramas Principais (II)
 Diagramas de Comportamento
– Demonstram os aspectos comportamentais e de reação do sistema ou da lógica
de negócio do projeto.
» Atividade, Estados, Casos de Uso e todos os de interação.
 Diagramas de Interação
– Sub-conjunto de diagramas de comportamento que enfatizam a interação entre
os objetos.
» Comunicação, Interação entre objetos e Sequência.
 Diagramas de Estrutura
– Especificação estrutural do elementos independente do tempo.
» Classes, Estrutura Composta, Componentes, Instalação,
Objetos e Pacotes.
11
Modelo de casos de Uso
12
Casos de Uso
Caso de uso é a especificação de uma seqüência de
interações entre um sistema e os agentes externos.
É a descrição de uma execução específica do sistema,
do ponto de vista do usuário
Define parte da funcionalidade de um sistema, sem

revelar a estrutura e o comportamento internos deste
sistema.
13
Casos de Uso
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.
Há várias formas de se descrever casos de uso.

– Grau de abstração
– Formato
– Grau de detalhamento
14
Descrição de um Caso de Uso

O Cliente chega ao caixa eletrônico e insere seu cartão.
O Sistema requisita a senha do Cliente.
Após o Cliente fornecer sua senha e esta ser validada, o sistema exibe as
opções de operações possíveis.
O Cliente opta por realizar um saque.
Então o Sistema requisita o total a ser sacado.
O Sistema fornece a quantia desejada e imprime o recibo para o Cliente.
15
Casos de Uso
O grau de detalhamento a ser utilizado na descrição de um caso
de uso também pode variar.
Um caso de uso sucinto descreve as interações sem muitos

detalhes.
Um caso de uso expandido descreve as interações em detalhes.
16
Casos de Uso
O grau de abstração de um caso de uso diz respeito à existência
ou não de menção à tecnologia a ser utilizada na descrição deste
caso de uso.
Um caso de uso essencial não faz menção à tecnologia a ser

utilizada.
Um caso de uso real apresenta detalhes da tecnologia a ser

utilizada na implementação deste caso de uso.
17
Casos de Uso
Exemplo de descrição essencial :
1) Cliente fornece sua identificação.
2) Sistema identifica o usuário.
3) Sistema fornece operações disponíveis.
4) Cliente solicita o saque de uma determinada quantia.
5) Sistema fornece a quantia desejada da conta do Cliente.
6) Cliente recebe dinheiro e recibo.
18
Casos de Uso
Um caso de uso tem diversas maneiras de ser realizado.
Um cenário é a descrição de uma das maneiras pelas quais um

caso de um pode ser realizado.
Um cenário também é chamado de instância de um caso de uso.
Normalmente há diversos cenários para um mesmo um caso de

uso.
Eles são úteis durante a modelagem de interações.
19
Casos de Uso - 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.
Casos de uso representam uma seqüência de interações entre o
sistema e o ator no sentido de troca de informações entre eles.
Normalmente um agente externo inicia a seqüência de interações
com o sistema, ou um evento acontece para que o sistema
responda.
20

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

Um ator corresponde a um papel representado em relação ao sistema.
– O mesmo indivíduo pode ser o Cliente que compra mercadorias e o
Vendedor que processa vendas.
– Uma pessoa pode representar o papel de Funcionário de uma instituição
bancária que realiza a manutenção de um caixa eletrônico, mas também
pode ser o Cliente do banco que realiza o saque de uma quantia.
O nome dado a um ator deve lembrar o seu papel, ao invés de lembrar
quem o representa.
22
Casos de Uso - Relações
Casos de uso e atores não existem sozinhos.Pode haver

relacionamentos entre eles.
A UML define diversos de relacionamentos no modelo de casos de
uso:
– Comunicação
– Inclusão
– Extensão
– Generalização
23
Inclusão
Existe somente entre casos de uso.
Analogia útil: rotina.
– Em uma linguagem de programação, instruções podem ser
agrupadas em uma unidade lógica chamada rotina.
– Sempre que essas instruções devem ser executada, a rotina
correspondente é chamada.
Quando dois ou mais casos de uso incluem uma seqüência de
interações comum, esta seqüência comum pode ser descrita
em um outro caso de uso.
24
Inclusão
Caso de uso comum:
– evita a descrição de uma mesma seqüência de interações mais de uma vez
e torna a descrição dos casos de uso mais simples.
Um exemplo: considere um sistema de controle de transações bancárias.

Alguns casos de uso deste sistema são Obter Extrato, Realizar Saque e
Realizar Transferência.
– Há uma seqüência de interações em comum: a seqüência de interações
para validar a senha do cliente.
25
Inclusão
Obter Extrato <<include>>
<<include>>
Cliente
Realizar Saques Fornecer Identificação
<<include>>
Realizar Transferência
26
Extensão
Utilizado para modelar situações onde diferentes seqüências de
interações podem ser inseridas em um caso de uso.
Sejam A e B dois casos de uso.

– Um relacionamento de extensão de A para B indica que um ou mais dos
cenários de B podem incluir o comportamento especificado por A.
– Neste caso, diz-se que B estende A.
– O caso de uso A é chamado de estendido e o caso de uso B de extensor.
27
Extensão
Cada uma das diferentes seqüências representa um comportamento
opcional, que só ocorre sob certas condições ou cuja realização
depende da escolha do ator.
Quando um ator opta por executar a seqüência de interações
definida no extensor, este é executado.
– Após a sua execução, o fluxo de interações volta ao caso de uso
estendido, recomeçando logo após o ponto em que o extensor foi
inserido.
Importante: não necessariamente o comportamento definido pelo

caso de uso extensor é realizado.
28
Extensão - Exemplo
Considere um processador de textos. Considere que um dos casos
de uso deste sistema seja Editar Documento.
No cenário típico deste caso de uso, o ator abre o documento,

modifica-o, salva as modificações e fecha o documento.
Mas, em outro cenário, o ator pode desejar que o sistema faça uma
verificação ortográfica no documento.
Em outro, o ele pode querer realizar a substituição de um fragmento

de texto por outro.
29
Extensão
Interações de Substituir Texto:
1.Em qualquer momento durante Editar Documento, o ator pode optar por substituir um
fragmento de texto por outro.
2.O ator fornece o texto a ser substituído e o texto substituto.
3.O ator define os parâmetros de substituição (substituir somente palavras completas
ou ocorrências dentro de palavras; substituir no documento todo ou somente na
parte selecionada; ignorar ou considerar letras maiúsculas e minúsculas).
4.O sistema substitui todas as ocorrências encontradas no texto.
30
Extensão
<<extend>>
Substituir
<<extend>>
Editar Documento
Autor
Corrigir
31
Generalização
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.
32
Generalização entre Casos de Uso
Na generalização entre casos de uso, sejam A e B dois casos de uso.
Quando B herda de A, as seqüências de comportamento de A valem também para

B.
Quando for necessário, B pode redefinir as seqüências de comportamento de A.
Além disso, B participa em qualquer relacionamento no qual A participa.
Vantagem: comportamento do caso de uso original é reutilizado pelos casos

de uso herdeiros.
Somente o comportamento que não faz sentido ou é diferente para um herdeiro

precisa ser redefinido.
33
Generalização entre Casos de Uso
Realizar Pagamento
Cliente
Realizar pagamento em dinheiro

Realizar pagamento com cartão
34
Generalização entre atores

A generalização entre atores significa que o herdeiro possui o mesmo
comportamento que o ator do qual ele herda.
Além disso, o ator herdeiro pode participar em casos de uso em que
o ator do qual ele herda não participa.
Um exemplo: considere uma biblioteca na qual pode haver alunos e
professores como usuários.
– Ambos podem realizar empréstimos de títulos de livros e reservas de
exemplares.
– No entanto, somente o professor pode requisitar a compra de livros à
biblioteca.
35
Generalização entre Atores
Reservar Livro
Aluno
Devolver livro
Solicitar Compra de Livro

Professor
36
Diagrama de Casos de Uso
Representa graficamente os atores, casos de uso e

relacionamentos entre os elementos.
Tem o objetivo de ilustrar em um nível alto de abstração quais

elementos externos interagem com que funcionalidades do
sistema.
Uma espécie de “diagrama de contexto”.

– Apresenta os elementos externos de um sistema e as maneiras
segundo as quais eles as utilizam.
37
Diagrama de Casos de Uso - Notação
Os relacionamentos de inclusão, extensão e herança são

representados por uma seta direcionada de um caso de uso para
outro.
 A seta (tracejada) de um relacionamento de inclusão recebe o
estereótipo <<inclui>>.
 A seta (tracejada) de um relacionamento de inclusão recebe o
estereótipo <<estende>>.
 A seta (sólida) de um relacionamento de herança não recebe
estereótipo.
38
Identificação de Atores
Os atores e os casos de uso são identificados a partir de
informações coletadas na fase de levantamento de requisitos do
sistema.
– Durante esta fase, os analistas devem identificar as atividades do
negócio relevantes ao sistema a ser construído.
Não há uma regra geral que indique quantos casos de uso são
necessários para descrever um sistema.
A quantidade de casos de uso a ser utilizada depende da

complexidade do sistema.
39
Identificação de atores
As fontes e os destinos das informações a serem processadas são

atores em potencial.
– Ator é todo elemento externo que interage com o sistema.
O analista deve identificar:

– As áreas da empresa que serão afetadas ou que utilizarão o sistema.
– fontes de informações a serem processadas e os destinos das

informações geradas pelo sistema.
40
Identificação de atores
Perguntas:
– Que órgãos, empresas ou pessoas irão utilizar o sistema?
– Que outros sistemas irão se comunicar com o sistema a ser construído?
– Alguém deve ser informado de alguma ocorrência no sistema?
– Quem está interessado em um certo requisito funcional do sistema?
O desenvolvedor deve ainda continuar a pensar sobre atores quando
passar para a identificação dos casos de uso.
41
Identificação de Casos de Uso
A partir da lista (inicial) de atores, deve-se passar à

identificação dos casos de uso.
42
Casos de Uso
Perguntas úteis:
 Quais são as necessidades e objetivos de cada ator em relação
ao sistema?
 Que informações o sistema deve produzir?
 O sistema deve realizar alguma ação que ocorre regularmente
no tempo?
 Para cada requisito funcional, existe um (ou mais) caso(s) de
uso para atendê-lo?
 Importante: Um sistema de software não existe para cadastrar
informações, nem para gerenciar os seus usuários.
– O objetivo principal é produzir algo de valor para o ambiente no qual ele
está implantado.
43
Construção do diagrama de casos

de uso
Os diagramas de casos de uso devem servir para dar suporte à
parte escrita do modelo, fornecendo uma visão de alto nível.
Quanto mais fácil for a leitura do diagrama representando casos
de uso, melhor.
Se o sistema sendo modelado não for tão complexo, pode ser
criado um único DCU.
Este diagrama permite dar uma visão global e de alto nível do
sistema.
44
Construção do diagrama de casos

de uso
Em sistemas complexos, representar todos os casos de uso do sistema
em um único diagrama pode torna-lo ilegível.
Alternativa: criar vários diagramas, de acordo com as necessidades de

visualização.
– Diagrama exibindo um caso de uso e seus relacionamentos;
– Diagrama exibindo todos os casos de uso para um ator;
– Diagrama exibindo todos os casos de uso a serem implementados em um ciclo de

desenvolvimento.
45
Documentação dos atores
Uma breve descrição para cada ator deve ser adicionada ao modelo
de casos de uso.
O nome de um ator deve lembrar o papel desempenhado pelo mesmo

no sistema.
46
Documentação dos Casos de Uso
A UML não define uma estruturação específica a ser

utilizada na descrição do formato expandido de um
caso de uso.
Sendo assim, adotaremos a forma de descrição contida

no arquivo UseCases.doc
47
Estudo de Caso- Supermercado

O Supermercado XYKZ deseja modernizar a forma com que seus clientes efetuam as compras.
Para que isso ocorra pretende disponibilizar terminais de consultas aos preços, por todo o supermercado.
Assim, o cliente poderá, a qualquer momento, consultar o preço de um produto.
O gerente do supermercado recebe novos produtos e os cadastra no sistema.
Concluído o cadastro dos produtos, o gerente autoriza os funcionários a colocarem estes produtos nas prateleiras.
O gerente a qualquer momento pode disponibilizar produtos em promoção. O gerente cadastra os preços
promocionais e solicita ao locutor que faça o anuncio dos produtos que estão em oferta.
Outra tarefa do gerente é realizar a troca dos produtos para os clientes. Ao realizar a troca, o gerente verifica se há
ainda produtos disponível para que a mesma possa ser efetuada. Caso não haja produtos disponíveis o gerente
efetua a devolução do dinheiro do cliente.
Todas as compras dos clientes são registradas pelo funcionário caixa.
Caso o caixa registre o produto duas vezes ou o cliente desista de levá-lo, então é feito o estorno deste produto.
Concluído o registro de todos os produtos o caixa registra o pagamento do cliente.
48
Gerenciar Troca Troca por Dinheiro
<<include>>
Manter Produto
Troca por Produto
Gerente <<include>>
Gerenciar promoções
<<include>> <<include>>
<<include>>
Gerenciar Registros de Vendas Estornar produto
Gerenciar Estoque <<include>>
<<include>>
Registrar pagamento Caixa

Cliente Consultar preço
49
Descrição de Caso de Uso

Dados Principais
 Nome
 Atores
 Pré-condições
 Pós-condições
 Fluxo de eventos (cenário primário)
 Pontos de extensões
 Casos de uso usados
 Cenários secundários
 Vide arquivo Word (Casos de Uso.rtf)
50
Locadora de DVD via Web

 Este software tem o objetivo de disponibilizar a locação de DVDs, via Internet, a clientes já
cadastrados ou novos.
 O software deve prever o cadastramento de usuários locadores, com seus dados pessoais,
principalmente, os dados de endereço, que são tão importantes para a entrega como para a
recuperação de produtos alugados.
 O software atenderá a todas as cidades onde o cliente contratante tiver depósito de DVD. Serão
disponibilizados somente DVD´s da cidade onde o cliente locador reside, visando à entrega.
 O cliente locador deve informar o modelo de seu equipamento de DVD, a fim de se avaliar se ele
é ou não adequado a reproduzir o filme.
 O cliente locador terá, no máximo, cinco dias para a devolução de um DVD alugado, sendo que
esse período dependerá do tipo de DVD, que pode ser: desde lançamento até DVDs antigos. O
processo de fidelizar o cliente locador leva em consideração tanto o número de locações quanto
as devoluções pontuais.
51
Locadora de DVD via Web
 A não devolução de um DVD no prazo estipulado implica pagamento de multa.
 O cliente locador pode designar, desde que apresente a documentação

necessária, beneficiários capazes de efetivar um aluguel de DVD.
 As entregas serão feitas somente dentro da cidade em que o locador reside.
 Os administradores do site poderão, controlar Programa de Fidelidade,

Programa de Promoções, Preços e Marketing.
 Os pagamentos serão feitos antecipadamente, pelo cartão de crédito ou boleto

bancário.
52
Exemplo - Descrição do Sistema

 O sistema a ser desenvolvido é o Sistema para Reciclagem de Itens para garrafas, latas e
engradados retornáveis.
 O cliente insere os itens a serem devolvidos, através de entradas apropriadas. O sistema
avalia, para cada item, qual tipo foi devolvido, através das suas dimensões.
 O sistema pode não aceitar um item, se as suas dimensões não corresponderem às dos
tipos cadastrados.
 Neste caso, o cliente é alertado através da iluminação da mensagem ITEM NÃO VÁLIDO no
painel, e deve retirar o item.
 Se o item for válido, o sistema atualiza o número de itens daquele tipo.
 Quando o cliente terminar de depositar o último item, ele deve pressionar o botão de
pedido de recibo.
 O sistema imprime a data, a identificação, a quantidade e o valor unitário de cada tipo de
item, e o valor total a ser pago pela devolução.
 O sistema é também usado pelo seu operador. Ele pode pedir, no final do dia, a impressão
relativa à devolução feita durante aquele dia.
53
 O sistema imprime quantos itens de cada tipo foram devolvidos no dia e o

número total de itens.
 Os números registrados são zerados após a impressão, para reiniciar a

contagem do novo dia.
 O operador pode, ainda, alterar o valor e as dimensões dos itens, inserir

novos itens e eliminar itens existentes.
 Se o item ficar entalado, ou se acabar o papel para a impressão do recibo,

o operador será avisado através de um alarme sonoro. Quando o operador
resolver o problema, ele deve resetar o alarme.
 No caso de item entalado, ele não será contabilizado e o cliente pode

prosseguir a operação, sem perder as informações das devoluções já
realizadas.
54
Atores
 Cliente
– coloca os itens a serem devolvidos na máquina e recebe o recibo.
 Operador
– mantém o bom funcionamento da máquina e solicita relatórios diários.
55
Casos de Uso
 Devolve item é disparado pelo cliente, quando ele quer devolver latas,
garrafas ou engradados. Para cada item inserido na máquina, o
sistema incrementa o contador de itens daquele tipo, para a
contabilização do cliente e do total do dia. Após a inserção do último
item, o cliente aperta o botão de pedido de recibo; o sistema gera o
recibo que contém os itens devolvidos, os valores discriminados por
tipo e o valor total a ser devolvido.
56
Casos de Uso
 Gera relatório diário é disparado pelo operador, quando ele deseja
imprimir a informação relativa aos itens devolvidos durante o dia. O
sistema imprime as quantidades dos itens, discriminados pelos tipos e
o total do dia. Os números de itens são zerados para iniciar a
contagem do novo dia.
57
Casos de Uso
 Muda item é usado pelo operador para alterar as informações

armazenadas no sistema. Podem ser alterados: o valor do item, as
dimensões do item, bem como inserir ou eliminar itens.
58
Caso de uso
 Exemplo de extensão:
– trata alarme na devolução, quando um item fica entalado
 Exemplo de inclusão:
– imprime: tanto devolve item quanto gera relatório diário tem saída impressa
(recibo ou relatório)
59

Engenharia de Software

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Engenharia de Software

Hochgeladen von

Copyright:

Verfügbare Formate

Engenharia de Software II

Profa. Dra. Ana Paula Gonçalves Serra

Visão Geral da UML

– Linguagem para especificação, construção, visualização e

documentação de artefatos de um sistema.

– Standard da OMG (Object Management Group)

– Adotado por empresas e instituições de todo o mundo

– Existem mais de 50 ferramentas comerciais e acadêmicas para

modelagem com UML.

– Semântica para tratar tópicos de modelagem futura

» tecnologia de componentes, computação distribuída,

– Mecanismos de extensão que permitem que futuras aproximações

– Semântica e sintaxe para facilitar a troca de modelos entre

» Independente da linguagem de programação, ferramentas CASE e

» Para diferentes projetos, diferentes metodologias, mas a mesma

– Independente das ferramentas de modelagem

» Apesar de sugerir algumas ideias na apresentação, não aborda todos

– Coerência na unificação de elementos de outras notações (Booch, OMT,

Jun1996 UML0.9 UML Partners

Tipos de Elementos Básicos (I)

– (1) “coisas” ou elementos básicos através dos quais se definem os modelos.

– (2) relações, que relacionam elementos

– (3) diagramas, que definem regras de agrupamento de elementos

Tipos de Elementos Básicos (II)

 Principais elementos da estrutura

– Elementos de especificação de comportamento (estados e atividades)

– Elementos de agrupamento (pacotes e fragmentos)

Tipos de Diagramas Principais (I)

– Três categorias de diagramas : Comportamento, Interação e Estrutura.

Tipos de Diagramas Principais (II)

Modelo de casos de Uso

Define parte da funcionalidade de um sistema, sem

Há várias formas de se descrever casos de uso.

Descrição de um Caso de Uso

O Sistema requisita a senha do Cliente.

O Cliente opta por realizar um saque.

Então o Sistema requisita o total a ser sacado.

O Sistema fornece a quantia desejada e imprime o recibo para o Cliente.

Um caso de uso sucinto descreve as interações sem muitos

Um caso de uso expandido descreve as interações em detalhes.

Um caso de uso essencial não faz menção à tecnologia a ser

Um caso de uso real apresenta detalhes da tecnologia a ser

1) Cliente fornece sua identificação.

2) Sistema identifica o usuário.

3) Sistema fornece operações disponíveis.

4) Cliente solicita o saque de uma determinada quantia.

5) Sistema fornece a quantia desejada da conta do Cliente.

6) Cliente recebe dinheiro e recibo.

Um cenário é a descrição de uma das maneiras pelas quais um

Um cenário também é chamado de instância de um caso de uso.

Normalmente há diversos cenários para um mesmo um caso de

Eles são úteis durante a modelagem de interações.

Casos de Uso - Atores

Casos de Uso - Atores

Casos de Uso - Atores

– O mesmo indivíduo pode ser o Cliente que compra mercadorias e o

Vendedor que processa vendas.

– Uma pessoa pode representar o papel de Funcionário de uma instituição

bancária que realiza a manutenção de um caixa eletrônico, mas também

pode ser o Cliente do banco que realiza o saque de uma quantia.

O nome dado a um ator deve lembrar o seu papel, ao invés de lembrar

Casos de Uso - Relações

Casos de uso e atores não existem sozinhos.Pode haver