UML: The Unified Modeling Language /

Use Cases

Professora: Aline Vasconcelos

IF Fluminense

apires@[Link]
Roteiro
◼ UML: uma definição
◼ Requisitos Funcionais e Não-Funcionais
◼ Stakeholders
◼ Glossário
◼ Casos de Uso
◼ Atores
◼ Cenários
◼ Diagramas de Casos de Uso
◼ Descrição de Casos de Uso
◼ Relacionamentos entre Casos de Uso e entre
Atores 2
UML: uma definição

◼ UML representa uma Linguagem de Modelagem e não um

Método. Trata-se de uma linguagem visual (diagramática).

◼ Método = procedimento formal para a realização de uma

tarefa
◼ Métodos consistem, pelo menos em princípio, de um
processo e de uma linguagem de modelagem.
◼ A linguagem de modelagem é a notação (principalmente
gráfica) utilizada por métodos para expressar projetos.
◼ O processo é a sugestão dos passos a serem seguidos na
elaboração de um projeto.
3
UML: diagramas (1/3)
◼ Apresenta nove diagramas para a modelagem de sistemas orientados a
objetos, sendo que, em cada um deles, uma diferente perspectiva do sistema é
enfocada.
◼ OS DIAGRAMAS ESTÁTICOS:
– Diagrama de Classes: reflete os tipos de objetos (classes) que
compõem o domínio de problema e o domínio da solução, com sua
estrutura e relacionamentos.
– Diagrama de Objetos: gráfico de instâncias, incluindo objetos com
seus valores de dados (atributos). Representa uma instância do
diagrama de classe, como uma foto de determinados objetos do
sistema em algum momento no tempo. É utilizado para
exemplificar o diagrama de classes.
– Diagrama de Caso de Uso (Use Case): reflete um modo de
descrever a visão externa do sistema e suas interações com o
mundo exterior, representando uma visão de alto nível de
funcionalidade intencional mediante o recebimento de um tipo de
requisição do usuário. Na modelagem de casos de uso, o sistema
é visto como uma caixa-preta que oferece respostas aos usuários
sem enfocar de que forma o atendimento a essas requisições é
implementado internamente. 4
UML: diagramas (2/3)
◼ OS DIAGRAMAS DINÂMICOS:
– Diagramas de Interação: enfatizam interações entre objetos
através da troca de mensagens. Refletem a estrutura dinâmica de
um sistema orientado a objetos. As interações, ou seja, seqüências
de troca de mensagens entre objetos, visam a realização de um
propósito específico, tal como a realização de um caso de uso. Há
dois tipos de diagramas de interação: Diagrama de Seqüência –
enfatiza o aspecto temporal nas trocas de mensagens; Diagrama
de Colaboração – representação espacial, gráfica de uma
colaboração entre objetos.
– Diagrama de Estado: mostra as seqüências de estados pelos
quais um objeto ou interação passa ao longo de sua vida em
resposta a estímulos recebidos (eventos).
– Diagrama de Atividades:descreve uma seqüência de atividades
para a realização de um processo, sendo úteis para a modelagem
de workflows. Representa uma variante do Diagrama de Estados,
no qual a maioria, se não todos os estados, são atividades.

5
UML: diagramas (3/3)
◼ OS DIAGRAMAS FÍSICOS:
- Diagramas de Componente: mostra os vários componentes em
um sistema e duas dependências. Um componente representa,
neste caso, um módulo físico do código.

- Diagramas de Utilização ou Implantação (deployment

diagrams): mostra as relações físicas entre componentes de
software e hardware no sistema implementado.

6
Requisitos (1/2):
◼ Requisitos:
– (1) Uma condição ou capacidade necessária para um usuário
resolver um problema ou alcançar um objetivo.
– (2) Uma condição ou uma capacidade que deve ser alcançada ou
estar presente em um sistema para satisfazer um contrato, padrão,
especificação ou outro documento formalmente imposto.

◼ O documento que descreve todos os requisitos de um software,

usualmente num formato ou linguagem inteligível pelo cliente, é a
Descrição de Requisitos.
◼ O documento que especifica estes requisitos, utilizando um formato
mais apropriado para a implementação, é a Especificação de
Requisitos.
◼ Geralmente, ambos os documentos (descrição e especificação de
requisitos) descrevem o que o software proposto deve fazer sem se
preocupar em como deve ser feito.

7
Requisitos (2/2):
◼ Requisitos Funcionais:
– Descrevem uma interação entre o sistema e seu meio ambiente.
– Funcionalidades do sistema conforme percebidas pelos atores externos
(usuários).

◼ Requisitos Não-Funcionais:
– Ou restrições, descrevem uma restrição para o sistema que limita as
possíveis escolhas de solução para o problema.
– Normalmente conhecidos como Requisitos de Qualidade de uma
aplicação.
– Devem ser detalhados em uma seção da documentação do Projeto do
Software.

◼ Uma Especificação de Requisitos é importante porque:

– Estabelece uma base de concordância entre o cliente e o fornecedor sobre
o que o software fará.
– Mapeia o problema.
– Uma especificação de requisitos de alta qualidade é um pré-requisito para
um software de alta qualidade. 8
Requisitos Não-Funcionais
◼ Fatores de Qualidade de Software, segundo McCall [MCC77]:
– Corretitude: à medida que um software satisfaz sua especificação
e cumpre os objetivos visados pelo cliente.

– Confiabilidade: probabilidade da operação livre de falhas de um

programa de computador num ambiente específico durante
determinado tempo.

– Eficiência: a quantidade de recursos de computação e de código

exigida para que um programa execute sua função.

– Integridade: à medida que o acesso ao software ou a dados por

pessoas não-autorizadas pode ser controlado,

– Usabilidade: o esforço para aprender, operar, preparar a entrada e

interpretar a saída de um programa.

9
Requisitos Não-Funcionais
◼ Fatores de Qualidade de Software, segundo McCall [MCC77]:
– Manuteniblidade: o esforço exigido para localizar e reparar erros
num programa.

– Flexibilidade: o esforço exigido para modificar um programa

operacional.

– Testabilidade: o esforço exigido para testar um programa a fim de

garantir que ele execute sua função pretendida.

– Portabilidade: o esforço exigido para transferir o programa de um

ambiente de sistema de hardware e/ou software para outro.

– Reusabilidade: à medida que um programa (ou partes de um

programa) pode ser reusado em outras aplicações – relacionada
ao empacotamento e escopo das funções que o programa executa.

– Interoperabilidade: o esforço exigido para se acoplar um sistema

a outro.
10
Stakeholders
◼ Pessoas atingidas pelos resultados produzidos pelo sistema e pelo
projeto do sistema.
◼ Exemplos de Stakeholders:

– Clientes: encomendam o produto e financiam o desenvolvimento

– Usuários diretos: utilizam diretamente o produto
– Usuários indiretos: recebem resultados do software, sem operá-lo
diretamente
• Ex: Gerentes/Diretores
– Analistas ou Setores responsáveis por sistemas relacionados
– Responsáveis pelo desenvolvimento, implantação e
manutenção do software,
– etc.

11
Glossário:
◼ Um Glossário deve ser produzido ao longo da atividade de
coleta e especificação de requisitos ou durante a
modelagem do negócio.

◼ O Glossário conterá os termos utilizados pelos usuários

com sua descrição.

◼ Um documento de glossário ajuda a compreender as

funcionalidades descritas pelos casos de uso.

12
Casos de Uso:
◼ Originado a partir do método do Jacobson.
◼ Casos de Uso são utilizados para modelar os requisitos
funcionais do sistema.
◼ Casos de Uso descrevem as funcionalidades do sistema,
conforme esperadas pelos usuários, retratando um “diálogo” que
uma entidade externa, chamada Ator, realiza com o sistema.
◼ Um Caso de Uso é baseado num cenário descritivo de como o
Ator interage com o sistema. Ele identifica eventos que podem
ocorrer e descreve as respostas do sistema para estes eventos.
◼ Um Caso de Uso, em última instância, representa um fluxo de
eventos completo e com significado, descrevendo uma situação
de uso particular do sistema.
◼ Símbolo:

Função 1
13
Atores:
▪ Ator: um papel que um usuário executa em relação ao
sistema.
▪ Os atores desempenham os casos de uso. Um único ator
pode desempenhar vários casos de uso; um único caso de
uso pode ter reciprocamente vários atores desempenhando-o
ou participando.
▪ Atores podem ser vistos como participantes do caso de uso
que obtêm valor dos mesmos.
▪ Atores podem ser: humanos, outros sistemas, dispositivos
externos, etc., que interagem com o sistema.
▪ Símbolo:

Ator 1

14
Cenários:
◼ Um cenário é uma seqüência de eventos (estímulos) e respostas
que descreve uma interação entre um usuário (Ator) e um
sistema. Portanto, se você tivesse uma loja on-line baseada na
web (loja virtual), poderíamos ter um cenário de compra de
produto que diria:

O cliente navega pelo catálogo de itens de mercadoria e

adiciona os itens desejados ao seu carrinho de compras. O
cliente encerra a compra, visualizando o carrinho, informando
o endereço de entrega, o número do cartão de crédito e
confirmando a venda. O sistema procede à autorização do
cartão de crédito, totaliza a venda e informa o valor total ao
cliente e confirma a venda imediatamente, enviando um e-mail
ao cliente logo a seguir.

15
Cenários na Descrição de Casos de Uso:

Comprar Produto
Cliente

Compra de um Produto:
1. O cliente navega pelo catálogo e seleciona itens a serem comprados.
2. O cliente vai para o checkout.
3. O cliente preenche o formulário da remessa, com: nome, data de
nascimento, identidade, endereço e opção de entrega.
4. O sistema apresenta a informação total do faturamento incluindo a
remessa, os preços e os impostos.
5. O cliente preenche a informação de cartão de crédito.
6. O sistema valida o número do cartão e autoriza a compra.
7. O cliente confirma imediatamente a venda
8. O sistema envia uma confirmação para o cliente por e-mail.

16
Cenários na Descrição de Casos de Uso:

Comprar Produto
Cliente

Fluxo Alternativo 1:Falha na Autorização do Cartão de Crédito

No item 6, o sistema falha na autorização da compra por crédito. Permite ao
cliente re-submeter a informação do cartão de crédito e tentar
novamente.

Fluxo Alternativo 2: Compra por Cliente Regular

No item 3, o cliente informa seu código de cliente regular. O sistema
apresenta os dados do cliente, o número do cartão de crédito do cliente
e os dados da compra. O cliente pode aceitar ou escrever por cima das
informações apresentadas. Se cliente altera cartão, continua no passo 6,
senão, continua no passo 7.

17
Diagrama de Casos de Uso: exemplo 1
SISTEMA DE CONTROLE DE BIBLIOTECA

Registrar Título
Reservar Item

Remover Título

Remover Reserva
Bibliotecário

Registrar Item

Emprestar Item

Remover Item

Devolver Item
Registrar Usuário
Remover Usuário
18
Diagrama de Casos de Uso: exemplo 1

Consultar Títulos
Usuário da
Biblioteca

19
Descrição de Casos de Uso: Possíveis Seções em uma
Descrição

◼ Caso de Uso: nome do caso de uso.

◼ Ator que inicia o Caso de Uso: ator responsável por

disparar o evento que dá início ao caso de uso.
Se for um caso de uso de inclusão ou de extensão, serão
definidos, nesta seção, os casos de uso que iniciam este
caso de uso em questão.

◼ Objetivos: descreve, em linhas gerais, o que o caso de

uso faz. Que funcionalidade o mesmo provê para o ator
(usuário do sistema). Em alguns casos, ao invés de
objetivos tem-se uma seção de Descrição, a qual contém
uma mini-descrição e um resumo dos objetivos do caso
de uso.
20
Descrição de Casos de Uso: Possíveis Seções em uma
Descrição

◼ Pré-condições: condições que devem ser satisfeitas antes do

caso de uso ser executado. Representa o estado em que um
outro caso de uso deve deixar o sistema para que o caso de
uso em questão possa ser iniciado. Pré-condições não devem
ser validadas dentro do fluxo execução do caso de uso.

◼ Fluxo de Eventos:
– Fluxo Principal: seqüência de eventos descrevendo o cenário
básico ou principal do caso de uso. A seqüência de eventos traduz
um diálogo entre os atores participantes do caso de uso e o
sistema.

– Fluxos Alternativos: seqüências de eventos alternativas. Podem

representar alguma variação em relação ao fluxo básico de
eventos, uma condição de erro no fluxo básico ou uma seqüência
de eventos diferente, ou seja, um outro cenário que esteja
relacionado aos objetivos e funcionalidade provida pelo caso de
uso.
21
Descrição de Casos de Uso: Possíveis Seções em uma
Descrição

◼ Subfluxos: partes (conjunto de eventos) do fluxo de eventos

que são extraídas, descritas em outro lugar (abaixo do fluxo
principal) com um nome e referenciadas no fluxo principal e/ou
em fluxos alternativos.

◼ Exceções: alguma condição diferente do normal, do esperado,

que possa levar o sistema a falhar. Representa também uma
situação de erro, como as que podem ser representadas em um
fluxo alternativo.

◼ Pontos de Extensão: representam locais em um fluxo de

eventos onde um comportamento adicional pode ser inserido. O
comportamento pode ser inserido tanto através de um fluxo
alternativo como através de um caso de uso de extensão. Para
casos de uso de extensão, este comportamento adicional e a
condição para sua inserção são especificados no caso de uso
de extensão.
22
Descrição de Casos de Uso: Possíveis Seções em uma
Descrição

◼ Pós-condições: retratam o estado do sistema após a execução

do caso de uso. Pós-condições podem ser omitidas quando o
resultado do caso de uso é óbvio ou quando não ocorre
nenhuma mudança de estado significativa no sistema após a
execução do caso de uso.

◼ Regras de Negócio: condições ou restrições sobre os

processos de negócio, ou seja, sobre a forma como o negócio é
executado. As Regras de Negócio devem ser checadas no fluxo
de eventos do caso de uso.

◼ Observações: detalhes a respeito do sistema que não devem

estar explícitos no fluxo de eventos do caso de uso, mas que
acrescentam informação significativa para o leitor compreender
a funcionalidade descrita pelo caso de uso ou para se
compreender o funcionamento do sistema.

23
Diagrama de Casos de Uso: exemplo 2
Sistema de Controle de Vendas

Manter Clientes

Manter Produtos

<<extend>>

Registrar Parcelas de Pagamento

Caixa Vender Produtos <<include>>

<<include>>

Registrar Entrega de Produto Atualizar Estoque de Produto

Gerente

Manter Fornecedores
24
Relacionamentos entre Casos de Uso
▪ Inclusão: (referenciado como: uses, include ou inclui)
▪ Um relacionamento de Inclusão do Caso de Uso A para o Caso de
Uso B, indica que o comportamento de B estará incluído no
comportamento de A.
▪ Principal objetivo: reutilização
▪ A associação de inclusão ocorre, principalmente, quando há uma
parte do comportamento que é semelhante em mais de um caso de
uso e não se deseja ficar copiando a descrição deste
comportamento.
Ex:

Caixa Vender Produtos <<include>>

<<include>>

Registrar Entrega de Produto Atualizar Estoque de Produto

Gerente

25
Relacionamentos entre Casos de Uso
▪ Extensão: (referenciado como: estende ou extend)
▪ Um relacionamento de extensão do Caso de Uso B para o Caso de
Uso A, indica que o comportamento de A pode ser estendido pelo
comportamento especificado em B.
▪ O caso de uso de extensão pode acrescentar comportamento ao
caso de uso base.
▪ Extensão deve ser utilizada quando se está descrevendo uma
variação em comportamento normal do caso de uso. É um
comportamento adicional.
▪ Pontos de extensão podem ser declarados no caso de uso base.
Ex:
<<extend>>

Registrar Parcelas de Pagamento

Caixa Vender Produtos

26
Relacionamentos entre Casos de Uso
▪ Generalização:
▪ Um relacionamento de generalização entre um Caso de Uso A e
Casos de Uso B e C, indica que o comportamento de A é
especializado em B e C.
▪ Os casos de uso B e C apresentam uma estrutura muito
semelhante (fluxos de eventos, regras, etc.), então, a parte em
comum é fatorada para um caso de uso de generalização ª
▪ Os casos de uso especializados B e C podem acrescentar
comportamento (passos no fluxo principal, fluxos alternativos
adicionais), sobrescrever comportamento ou acrescentar dados
de entrada e saída, regras, etc.
▪ Ex:
Emitir Boletim
Secretária

Emitir Boletim de Alunos do 2º Emitir Boletim de Alunos do 3º

Grau Grau 27
Relacionamentos entre Atores
▪ Generalização:
▪ Um relacionamento de generalização entre Atores significa que
os Atores B e C representam papéis que especializam o papel
definido pelo Ator A.
▪ O relacionamento de generalização entre atores indica que os
atores pertencem a um mesmo grupo semântico de usuários (ou
papéis) e que compartilham responsabilidades. Os atores
especializados herdam todas as características e links de
comunicação do ator da generalização. Dessa forma, todos os
casos de uso que o ator generalizado pode executar poderão ser
executados também pelos atores das especializações.
▪ Ex:
Acompanhar Desempenho de
Coordenador
Funcionários

28
Gerente Diretor
Passos para Elaborar o Modelo de Casos de Uso do
Sistema

▪ Identificar os Atores do Sistema

▪ Identificar os Casos de Uso do Sistema
▪ Identificar as Associações entre Atores e Casos de Uso
▪ Elaborar o Diagrama de Casos de Uso
▪ Dividir os casos de uso em pacotes se houver necessidade
▪ Descrever os casos de uso
▪ Verificar relacionamentos entre casos de uso: inclusão, extensão e
generalização

29
Referências
◼ [Link]
◼ [Link]
◼ Fowler, M. UML Essencial, Ed. Campus, 2000.
◼ Bittner, Kurt, Spence, Ian. Use Case Modeling. Addison-Wesley.
August, 2002.

30