2 UML DiagramasCasosUso

8/18/2019 2 UML DiagramasCasosUso

1/17

UML – Unified Modeling Language

Diagramas de Casos de Uso

José Correia, Março 2006

(http://paginas.ispgaya.pt/~jcorreia/)

José Correia UML – Diagramas de Casos de Uso 2

Objectivos

O objectivo de um diagrama de casos de uso de um sistema é mostrar

para que serve o sistema (quais são os usos possíveis do sistema),

ignorando a forma como o sistema está organizado internamente.

Mais precisamente, permite capturar o comportamento

(funcionalidades) do sistema do modo como é visto pelos utilizadores,

sem ter de especificar como é que esse comportamento éimplementado.

Os diagramas de casos de uso descrevem:

• o contexto do sistema

• as funcionalidades do sistema (os casos de uso)

• e, possivelmente, alguns requisitos não funcionais (os que têm a ver com

casos de uso particulares)


2/17


Elementos da UML

O diagrama de casos de uso de um sistema contém:

• Linha que define a fronteira do sistema – entre o sistema físico e osactores que com ele interagem

• Actores (fora do sistema)

• Casos de uso (dentro do sistema)

• Associações de interacção entre actores e casos de uso

Um diagrama de casos de uso também pode conter:

• Relações de dependência entre casos de uso

- de extensão (estereótipo «extend»)

- de inclusão (estereótipo «include»)

• Relações de generalização

- entre casos de uso ou entre actores


Exemplo


3/17


Actores

Um actor ...

... é um tipo de utilizador do sistema

... é alguém, ou alguma coisa, que interage com o sistema

pode ser qualquer coisa – humano, dispositivo de hardware, outro sistema, etc.

... é, como iremos ver, uma classe (de objectos externos ao sistema).

A mesma pessoa, ou coisa, pode corresponder a vários actores

• de acordo com Booch, “um actor representa um conjunto coerente de

papéis que utilizadores de um sistema desempenham quando interagem

com os casos de uso do sistema”

Actores ≠ Recursos do sistema

• Recursos são pessoas, máquinas, etc., que pertencem ao sistema e que

são usados para levar a cabo tarefas dentro do sistema

Professor Aluno


Cliente

ou «actor»

Cliente

Actores: Exemplos e Notação

Ex.1 – Actores em relação a um negócio de restauração:

• Fornecedor

• Cliente

Ex.2 – Actores em relação a um software de gestão de restaurantes:

• Administrador do sistema

• Empregado da caixa• Empregado de mesa

Os actores são representados por ícones, ou por classes, com

estereótipo «actor»


4/17


Casos de Uso (Use Cases)

Um caso de uso é um padrão de comportamento que

o sistema exibe e pode corresponder a:

• uma funcionalidade do sistema

• um tipo de interacção entre um ou mais actores e o sistema com um determinado

objectivo

• um processo de negócio (no contexto de um sistema de negócio)

Um caso de uso é uma sequência de acções relacionadas, incluindo

variantes, que um sistema realiza para produzir um resultado observável comvalor para um actor (que interage com esse caso de uso)

• a sequência concreta de acções pode variar de instância para instância do caso de

uso (daí se falar em “incluindo variantes”)

• as instâncias de um caso de uso são as ocorrências concretas do caso de uso

Os casos de uso descrevem o que um sistema faz e não o modo como faz

Solicitar Lista de Cursos


Servir

almoço

Servir almoço

ou

Casos de Uso: Exemplos e Notação

Exemplo de casos de uso num negócio de restauração:

• Servir almoço

• Servir jantar

• Comprar bens

Um caso de uso é representado por uma elipse, com o nome do casode uso dentro ou por baixo da elipse

Os nomes dos casos de uso podem ser dados na perspectiva do sistema ou

do actor


5/17


Exemplo

Cliente

Servir almoço

Fornecedor

Restaurante

Servir jantar

Comprar bens

Associações entre actores e casos de uso mostram que actores interagem

com que casos de uso

• são representadas, normalmente, por linhas sem qualquer adorno


Documentar Casos de Uso

O diagrama de casos de uso deve ser acompanhado de descrições

dos actores e casos de uso

Pode-se (deve-se!) especificar o comportamento de cada caso de uso

descrevendo o fluxo de eventos de forma textual

• documentação escrita do ponto de vista do actor

- indicar o que o sistema deve fornecer ao actor, quando o caso de uso éexecutado

Convém indicar:

• como é que o caso de uso começa e acaba

• o fluxo básico (principal) de eventos

• fluxos alternativos de comportamento

• fluxos excepcionais de eventos (ex: respostas a erros)


6/17


Descrição de Casos de Uso (cont.)

Exemplo do restaurante (simplificado):

• Servir almoço: um cliente vem ao restaurante e é-lhe servido almoço. Ocliente escolhe o que pretende de um menu de almoços, com dois pratosdo dia e vários outros pratos de preparação rápida.

• Servir jantar: um cliente vem ao restaurante e é-lhe servido o jantar. Ocliente pode escolher um prato de um menu bastante variado ou pode atépedir um prato com uma composição por ele indicada.

• Comprar bens: são adquiridos os ingredientes necessários para aconfecção dos pratos que constam do menu. Inclui-se aqui tanto oplaneamento das aquisições, como a realização das aquisições afornecedores do restaurante.

Um caso de uso pode também ser descrito através de diagramas deinteracção ou outros diagramas dinâmicos

- conforme iremos ver quando falarmos desses tipos de diagramas UML


Relação “ extend” entre Casos de Uso

Podem-se organizar os casos de uso em casos básicos e extensões

aos casos básicos

• uma instância do caso de uso A pode incluir (sujeito a condições

especificadas na extensão) o comportamento especificado por B

• o caso básico deve fazer sentido sozinho

• os actores interagem com o caso básico (A)

as extensões traduzem partes, ou modalidades, acrescentadas

condicionalmente (opções)

• notação: dependência com estereótipo «extend»

A B«extend»

extensãocaso básico


7/17


Exemplo:

Podem-se indicar explicitamente os pontos em que um caso de uso

básico pode ser estendido (pontos de extensão)

Na descrição textual do caso básico: ... (sobremesa) ...

Servir umasobremesa

Servir jantar

Extension pointssobremesa

«extend»

(sobremesa)

Relação “ extend” entre Casos de Uso (cont.)

Servir uma entrada

Servir jantar

Servir uma sobremesa

Servir à luz de velas

«extend»

«extend»

«extend»


Relação “ include” entre Casos de Uso

Quando vários casos de uso têm um fluxo de eventos comum, é

conveniente separar essa parte comum para um novo caso de uso

que é incluído pelos primeiros

• uma instância do caso de uso A inclui obrigatoriamente o comportamento

especificado por B

• os actores interagem com A

• ao fazer a descrição textual de A: include(B)

• notação: dependência com estereótipo «include»

A B

(parte comum a outr os

casos de uso além de A)

«include»


8/17


Servir almoço

Servir jantar

Cobrar

refeição

«include»

«include»

Relação “ include” entre Casos de Uso(cont.)

Exemplo:


Servir uma

refeição

Servir

almoço

Servir jantar

Relação de Generalização entre Casos de Uso

Relação de generalização: relação entre uma coisa mais genérica e

uma coisa mais especializada...

... que é totalmente consistente com o primeiro elemento

... e adiciona informação adicional

Significa que o caso de uso "filho" (mais especializado) herda o

comportamento, significado e actores do caso de uso "pai" (maisgenérico)

• o filho pode adicionar ou substituir comportamento do pai;

• o filho pode aparecer em qualquer contexto em que o pai pode aparecer.

Exemplo:


9/17


Relação de Generalização entre Actores

Um Cliente Empresarial é um (is a) Cliente

• analogia com hierarquia ISA no modelo Entidade-Associação

O Cliente Empresarial herda as associações (de interacção com casos deuso) do Cliente genérico

A Generalização permite simplificar e estruturar os diagramas

Cliente Cliente

Empresarial


Exemplo 1: Restaurante

«extend»

«extend»

«extend»

Servir

almoço

Cobrar

refeição

«include»

Cliente

Fornecedor

Negócio de

restauração

Servir uma

refeição

Servir jantar

Servir à luz

de velas

Servir uma

sobremesa

Servir uma

entrada

Comprar

bens


10/17


Exemplo 2: Vídeo-gravador

Utilizador

«actor»

Televisor

Vídeo-gravador

Gravação

programada

Reprodução

de vídeo-

cassete

Gravação não

programada

Gravação de

vídeo-cassete

«actor»

Antena


Granularidade dos Casos de Uso

Um caso de uso (pelo menos um caso de uso básico) deve representar uma

unidade de funcionalidade o mais pequena possível que, uma vez

implementada, acrescenta valor (do ponto de vista dos actores) ao sistema

que está a ser desenvolvido

Exemplo no multibanco:

• "introduzir cartão" não é um caso de uso porque não tem valor isoladamente;

• "levantar dinheiro" é um caso de uso porque tem valor para um actor individual (o

detentor do cartão)

Com este objectivo, pode ser necessário agrupar num único caso de uso

várias interacções com o sistema (que ocorrem até em sessões diferentes)

• isso não impede que se divida um caso de uso básico em vários casos de uso de

grão mais fino, incluídos pelo primeiro

• Exemplo numa biblioteca: o caso de uso “Empréstimo” (aquele que tem valor para

os utilizadores) pode ser dividido em “Levantamento” e “Devolução”


11/17


Repor Bebidas de

acordo com Vendas

Abrir a Máquina

Fechar a Máquina

Agente do

Fornecedor

Repor Bebidas

Retirar Dinheiro

Dono

ClienteComprar Bebida

Extension Pointencher prateleiras

Exemplo: Máquina de bebidas

Considere o seguinte diagrama de casos de uso, correspondente a uma

máquina de bebidas:

Explique o significado do diagrama anterior, descrevendo o fluxo de eventos

de forma textual.


Exemplo: Máquina de bebidas (cont.)

Resposta possível à pergunta formulada:

• Comprar Bebida: Um cliente dirige-se à máquina de bebidas, introduz o dinheiro e

selecciona a bebida pretendida entre as existentes na máquina. A máquina entrega

a bebida seleccionada e, se for caso disso, devolve o troco.

• Repor Bebidas: O agente do fornecedor repõe as bebidas à medida que estas

forem sendo consumidas. Para tal, abre a máquina, enche as prateleiras com as

bebidas em falta e fecha a máquina.

• Retirar Dinheiro: O dono do estabelecimento onde a máquina está colocada, abre amáquina, retira o dinheiro existente, deixando o suficiente para trocos, e volta a

fechar a máquina.

Quais são as funcionalidades do sistema modelizado pelo diagrama anterior?

• As funcionalidades do sistema são os casos de uso, ou seja: “Comprar Bebida”,

“Abrir a Máquina”, “Fechar a Máquina”, “Retirar Dinheiro”, “Repor Bebidas” e “Repor

Bebidas de acordo com Vendas”.


12/17


Pacotes de Casos de Uso

Num sistema complexo, podem existir demasiados casos de uso para

visualizar com clareza num único diagrama!

Uma solução: um diagrama de casos de uso inicial, com pacotes de

casos de uso, e um diagrama de casos de uso relativo a cada pacote

Se tivermos um grande número de casos de uso devemos procurar

agrupá-los em pacotes!

Critérios de agrupamento de casos de uso:

• por sub-sistemas

• por actores


Definição de

Plano de Curso

Elaboração

de Calendário

de Exames

Atribuição de

Serviço Docente

Elaboração

de Horários

Elaboração

de Relatório

de Curso

Exemplo: SI do ISPGaya

Definição de

Ficha de

Disciplina

Lançamento de

Classificações

Publicação de

Material de Apoio

Lançamento

de Sumários

Elaboração de

Relatório de

Disciplina

Inscrições

no Curso

Inscrições nas

Disciplinas

Inscrições

nas Turmas

Consulta e Descarregamento

de Material de Apoio de

Disciplinas

Consulta de

Horários

Consulta de

Classificações

Consulta de

Sumários

Aluno de

Curso

Docente de

Disciplina

Funcionário deSecretaria

Director de Curso


13/17


SIIPG - Gestão de Cursos

Director

de Curso

Definição de

Plano de Curso

Elaboração deCalendário de Exames

At ribuição de

Serviço Docente

Elaboração de

Horários

Elaboração de

Relatório de Curso

Exemplo: SIIPG


SIIPG - Gestão de Disciplinas

Docente de

Disciplina

Definição de Ficha

de Discipli na

Lançamento de

Classificações

Publicação de

Material de Apoio

Lançamento de

Sumários

Elaboração de Relatório

de Discipli na

Exemplo: SIIPG


14/17


Exemplo: SIIPG

SIIPG - Inscrições

Funcionário de

Secretaria

Inscrições no

Curso

Inscrições nas

Disciplinas

Inscrições nas

Turmas

Aluno de

Curso

submete candidaturapela Web

executa procedimento de

colocação automática, ou

trata manualmente


Exemplo: SIIPG

SIIPG - Apoio a Alunos

Aluno de Curso

Consulta e Descarregamento

de Material de Apoio de

Disciplinas

Consulta deHorários

Consulta de

Classificações

Consulta de

Sumários


15/17


Exemplo: SIIPG

Sist. de Informação do ISPGaya (SIIPG)

Aluno de Curso Apoio a

Alunos

Docente de Disciplina Gestão de

Disciplinas

Funcionário de Secretaria

Director de Curso

Inscrições

Gestão deCursos


Realizações de Casos de Uso

Um Diagrama de Casos de Uso apresenta uma visão externa do

sistema

Os Diagramas de Interacção descrevem como os casos de uso são

realizados como interacções entre associações de objectos

Há dois tipos de Diagramas de Interacção (interaction diagrams):

• Diagramas de Sequência (Sequence diagrams)

• Diagramas de Colaboração (Collaboration diagrams)


16/17


Resumo

Um Diagrama de Casos de Uso...

... descreve o comportamento de um sistema do ponto de vista do utilizador

... descreve o que um sistema faz e não como o faz

... divide as funcionalidades do sistema em transações (casos de uso) que

têm significado para os utilizadores (actores)

... é uma descrição funcional de um sistema e dos seus principais processos

... fornece uma descrição gráfica de quem irá usar o sistema e do tipo deinteracções a esperar dentro desse sistema


Resumo (cont.)

Um caso de uso contém múltiplos cenários, cada um dos quais

descreve um fluxo específico de eventos

• devemos garantir que cada caso de uso descreve um pedaço significativo

(com valor) da utilização do sistema

• ao definir casos de uso com texto, usar nomes e verbos de forma

consistente e precisa

- irá facilitar a definição de objectos e mensagens nos diagramas de interacção

Ao construir os casos de uso, pensar...

… nas tarefas que devem ser desempenhadas pelo(s) actor(es)

… em manter os casos de uso simples


17/17


Resumo (cont.)

Um diagrama de casos de uso deve...

... conter apenas casos de uso ao mesmo nível de abstracção

... incluir apenas os actores que são necessários

Quando é que um diagrama de casos de uso deve ser usado?

• na especificação do contexto do sistema

• na descrição (captura) dos requisitos de um sistema, nas fases de design,

implementação e documentação

• na modelização de testes de cenários com casos de uso

O diagrama de casos de uso é, geralmente, elaborado na fase de

análise e especificação de requisitos, por analistas e especialistas do

domínio


Referências

Estes apontamentos foram baseados em:

• “UML – Unified Modeling Language”, Curso em Tecnologia de Objectos,

FEUP, Novembro 2000

Ademar Aguiar, Gabriel David, João Pascoal Faria

• “Introduction to UML: Structural Modeling and Use Cases”, Cris Kobryn,

Novembro 2000

• “UML, Metodologias e Ferramentas CASE”, Alberto Rodrigues da Silva,Carlos Videira, Maio 2001

• “Analysis and Design with UML”

Rational Software Corporation, 1997

• Web:

- OMG UML Resources: www.omg.org/uml/

2 UML DiagramasCasosUso

Documents

Transcript of 2 UML DiagramasCasosUso