Aula 01 Pratica Analise de Sistemas

I
Departamento de Engenharia
das Tecnologias de Informação
E
Análise de Sistemas
- Diagramas de Casos de Uso -
Aula Prática
Análise de Sistemas
I Análise de Sistemas
E Sumário
 Objectivo dos diagramas de casos de uso
 Actores
 Casos de uso
 Associações entre casos de uso e actores
 Relação “extend” entre casos de uso
 Relação “include” entre casos de uso
 Relação de generalização entre casos de uso
 Relação de generalização entre actores
 Exemplos
 Exercícios
Diagramas de Casos de Uso 2

E Objectivo
 O objectivo de um diagrama de casos de uso é mostrar para
que serve o sistema (sem mostrar como está organizado
internamente), com base na identificação e descrição de
actores e casos de uso
 O diagrama de casos de uso é geralmente elaborado na fase
de captura e especificação de requisitos para especificar o
comportamento pretendido do sistema que está a ser
desenvolvido, ignorando a forma como esse comportamento
é implementado
 O diagrama de casos de uso descreve o contexto do sistema
(os actores), os requisitos funcionais do sistema
(funcionalidades disponibilizadas aos actores) e,
possivelmente, alguns requisitos não funcionais (os que têm
a ver com casos de uso particulares)

E Elementos
 O diagrama de casos de uso de um sistema contém:
– linha rectangular que define a fronteira do sistema
– actores (fora do sistema)
– casos de uso (dentro do sistema)
– associações de interacção entre actores e casos de uso
– opcionalmente,
• relações de dependência “extend” e “include” entre casos de uso
• relações de generalização entre casos de uso
• relações de generalização entre actores
O diagrama de casos de uso geralmente é acompanhado de
descrições textuais de actores e casos de uso

E Actores
 Um actor representa um conjunto coerente de papéis que utilizadores
de casos de uso desempenham quando interagem com esses casos de uso
[Booch 98]
 Outras definições:
– Um actor é um tipo de utilizador do sistema

• pode ser uma pessoa ou outro sistema
– Um actor representa um conjunto coerente de papéis que alguém ou
alguma coisa (um dispositivo de hardware, outro sistema, etc.) do
ambiente envolvente pode desempenhar em relação ao sistema
 Actor diferente de Recurso 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
 Um actor é uma classe (de objectos externos ao sistema)
 A mesma pessoa ou coisa pode corresponder a vários actores

E Exemplos e notações de Actores
 Actores em relação a um negócio de restauração:
– Fornecedor
– Cliente
Actores em relação a um software de gestão de um
restaurante:
– Administrador do sistema
– Empregado da caixa
– Empregado de mesa
Os actores são representados por ícones ou por classes com
estereótipo «actor»
ou «actor»
Cliente Cliente

E Casos de Uso
Um caso de uso (use case) é uma descrição de um conjunto de
sequências de acções, incluindo variantes, que um sistema realiza para
produzir um resultado observável com valor para um actor [Booch 98]
 Um caso de uso corresponde a:

– uma funcionalidade do sistema
– uma situação de utilização do sistema com um determinado objectivo
– um tipo de interacção entre um ou mais actores e o sistema com um
determinado objectivo
As instâncias de um caso de uso são as ocorrências concretas do 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”)

E
Exemplos e notação de Casos de
Uso
 Exemplo de casos de uso num restaurante:
– servir almoço
– servir jantar
– comprar bens
Um caso de uso é representado por uma elipse, com o

nome do caso de uso dentro ou por baixo da elipse
Servir ou
almoço
Servir almoço

Associação entre casos de uso e
E
actores
 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

E
Exemplo de um diagrama de casos
de uso
Restaurante
Servir
almoço
Cliente
Servir
jantar
Comprar
bens
Fornecedor

E Descrição de Casos de Uso
 Numa primeira forma, pode-se especificar o comportamento de um
caso de uso descrevendo um fluxo de eventos de forma textual e
suficientemente clara e fácil de entender por uma pessoa de fora
 Convém indicar quando é que o caso de uso começa e acaba, quando é
que o caso de uso interage com os actores e que objectos são trocados,
e o fluxo básico (principal) e fluxos alternativos de comportamento
 Exemplo do restaurante (simplificado):
– Servir almoço: Um cliente vem ao restaurante e é-lhe servido almoço. O
cliente escolhe de um menu de almoços, com dois pratos do dia e vários
outros pratos de preparação rápida.
– Servir jantar: Um cliente vem ao restaurante e é-lhe servido o jantar. O
cliente 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 a
confecção dos pratos que constam do menu. Inclui-se aqui tanto o
planeamento das aquisições, como a realização das aquisições a
fornecedores do restaurante.
 Um caso de uso pode também ser descrito através de diagramas de
interacção ou outros diagramas dinâmicos

E Granularidade dos Casos de Uso
 Um caso de uso deve representar uma unidade de
funcionalidade o mais pequena possível que, uma vez
implementada, acrescenta valor (do ponto de vista dos
utilizadores) 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)

E
Relação “extend” entre casos de
uso (1)
 Para tornar as descrições dos casos de uso mais
compreensíveis, podem-se organizar os casos de uso em
casos básicos e extensões aos casos básicos, que traduzem
partes ou modalidades acrescentadas condicionalmente
(opções)
 Notação: dependência com estereótipo «extend»
«extend»
A B
extensão caso básico
– uma instância do caso de uso B pode incluir (sujeito a condições

especificadas na extensão) o comportamento especificado por A
– o caso básico deve fazer sentido sozinho
– os actores interagem com o caso básico

E
Relação “extend” entre casos de
uso (2)
 Exemplo:
Servir jantar
«extend» «extend»
Servir uma «extend» Servir à luz de
entrada velas
Servir uma
sobremesa
Podem-se indicar explicitamente os pontos em que um caso

de uso básico pode ser estendido (pontos de extensão)
Servir jantar
«extend» Servir uma
Extension points
sobremesa (sobremesa) sobremesa
 Na descrição textual do caso básico: .... (sobremesa). ...

E
Relação “include” entre casos de
uso (1)
 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
 Notação: dependência com estereótipo «include»
«include»
A B
(parte comum a outros casos
de uso além de A)
– uma instância do caso de uso A também inclui o comportamento

especificado por B
– os actores interagem com A
– na descrição textual de A: include (B).

E
Relação “include” entre casos de
uso (2)
 Exemplo
Servir almoço
«include»
Pagar
refeição
«include»
Servir jantar

E
Relação de generalização entre
casos de uso
 Relação de generalização: entre uma coisa mais genérica e
uma coisa mais especializada
 Notação: mesmo que generalização entre classes
 Aqui significa que o caso de uso "filho" (mais especializado)

herda o comportamento, significado e actores do caso de uso
"pai" (mais genérico)
– O filho pode adicionar ou substituir comportamento do pai
– O filho pode aparecer em qualquer contexto em que o pai pode
aparecer
Servir
 Exemplo: almoço
Servir uma
refeição
Servir
jantar
E
Relação de generalização entre
actores
 Exemplo:
Cliente
Cliente
empresarial
– Um cliente empresarial é um (is a) cliente

– O cliente empresarial herda as associações (de interacção com
casos de uso) do cliente genérico

E Exemplo - Restaurante
Restaurante
Servir
almoço
Servir uma Pagar
refeição «include» refeição
Cliente Servir
jantar «extend»
«extend»
«extend»
Servir uma Servir à luz
entrada de velas
Servir uma
sobremesa
Comprar
bens Fornecedor

E Exemplo – Video Gravador
Video-gravador
Reprodução
de video-
cassete
«actor»
Gravação não
Televisor
programada
Utilizador
Gravação de «actor»
video-cassete Antena
Gravação
programada

E Exercícios
 Máquina de Bebidas Petsi & Cola-Cola
– A empresa Petsi & Cola-Cola concebeu um sistema para gerir as máquinas
de venda dos seus produtos. Pretende que a máquina tenha o
comportamento seguinte para cada função:
• O cliente dirige-se à máquina para comprar um produto previamente enlatado,
sendo esta a situação mais normal. Contudo, existem máquinas que poderão
vender o produto também em copo.
• Quando o processo de venda está consumado a máquina deverá expelir o
respectivo produto entregando-o ao cliente.
• O representante da Petsi & Cola-Cola é o responsável pela reposição de stocks.
• Para poder repôr os stocks, o sistema inicia o processo de abertura da
máquina, e termina com o fecho da máquina.
• Após a reposição de stocks a máquina entrega um relatório de abastecimento
ao representante.
• Prevê-se que a reposição de stocks possa ser feita em função do nível de
vendas para cada produto, podendo assim eliminar-se os produtos que não são
vendidos nuns locais em favor dos que são mais solicitados, rentabilizando a
utilização da máquina.
• A entidade que detém a gestão comercial da máquina, pode abrir a máquina
no sentido de extrair as receitas das vendas efectuadas. A máquina por fim é
fechada, após a emissão de um relatório de receitas a ser entregue à entidade
respectiva.

E Exercícios

Livraria Virtual
– A livraria “Armagedeon”, pretende alcançar sucesso na nova Economia Digital. Para isso vai
criar um novo sistema que, permita vender pela Internet, mas que se integre no sistema actual
da livraria.
– Após um processo de levantamento e recolha de requisitos, chegou-se à seguinte definição do
sistema virtual de vendas:
• O cibernauta poderá consultar o portfólio de produtos disponíveis, esta consulta poderá ser realizada
com a intenção de introdução de comentários relativamente ao livros em questão.
• A consulta de um livro inclui uma técnica de marketing, que pela análise das encomendas realizadas na
loja virtual aconselha livros associados ao livro em consulta, sob a rúbrica: “Quem comprou este livro
também comprou estes:”
• O cibernauta só será considerado cliente após respectivo registo.
• O cliente sempre que pretenda um livro poderá adicioná-lo ao carrinho de compras.
• O cliente poderá efectuar a encomenda pela totalidade dos items do carrinho de compras, ou
simplesmente por alguns items seleccionados.
• Aquando da realização da encomenda esta será comunicada ao departamento de aprovisionamento.
Toda a gestão de stocks e de encomendas é controlada por este departamento.
• O cliente pode anular a encomenda nas 24h seguintes sem qualquer encargo desde que ainda não tenha
recebido o comunicado o comunicado de envio da encomenda, neste caso o departamento de
aprovisionamento deverá ser o mais rapidamente possivel alertado para a situação, devendo anular a
encomenda e/ou ordem de envio.
• Todas as operações realizadas pelo cliente só são possiveis após a validação do acesso
• Quando o departamento de aprovisionamento faz o envio de encomenda comunica ao sistema virtual de
vendas, após validação de acesso
• Quando se processa o envio da encomenda o sistema virtual de vendas deve:
– Enviar mail ao cliente (como foi referido)
– Dar ordem de pagamento ao terminal de crédito (VISA, American Express,.. )
– Emitir a factura para acompanhar a encomenda
• Todas as operações realizadas pelo cliente só são possiveis após a validação do acesso
• O departamento de pesquisa de mercado, responsável pela angariação de novas obras para serem
comercializadas na loja virtual, insere-as no sistema virtual de vendas após a validação respectiva
E
 Unidade de Restauração – Pizza Rute Exercícios
– A D. Rute impressionada pelo atendimento oferecido e condições organizacionais
de algumas unidades de restauração do seu circulo de conhecimentos, decidiu criar
um sistema de serviço de atendimento, e um sistema autónomo mas complementar
de gestão de stocks.
– Sistema de Gestão do Serviço de Atendimento (Parte 1)
• Requisitos do sistema de atendimento:
– O cliente faz um pedido relativamente à refeição que pretende. Normalmente o restaurante serve
refeições à mesa, porém dispõe de um serviço de ‘take-away’ para os clientes interessados.
– O cliente pode obter um cartão de fidelização que lhe dá direito a desconto e outras promoções
ou iniciativas de marketing.
– A responsável pela pretende do sistema alguns indicadores de gestão como: taxa de utilização do
estabelecimento, número de clientes, volume de vendas, picos de actividade,...
– O responsável pela organização da cozinha consulta os novos pedidos por ordem de chegada,
contudo é possivel que esta consulta possa ser efectuada em função de um determinado tipo de
produto, por forma a optimizar a confecção culinária. Quando se decide pela confecção do prato
o sistema deverá ser informado de que o prato está em fase de confecção.
– Quando a encomenda está pronta a ser servida, o responsável deverá comunicá-lo ao sistema por
forma a que o valor seja lançado na conta do cliente.
– A encomenda pode ser servida integralmente de uma só vez, ou parcialmente.
– O cliente pode desistir da encomenda, e/ou alterá-la se esta ainda não estiver em confecção.
– O funcionário pode consultar o estado em que se encontra a encomenda.
– O cliente procede ao pagamento que poderá ser normal, ou com direito aos descontos especiais
associados ao cartão.
– Quer o responsável pela organização da cozinha, quer a gestora do estabelecimento necessitam
de validar o acesso
– Sistema de Gestão de Stocks (Parte 2)
1. Em função das necessidades de um negócio de restauração, crie o conjunto de requisitos
que julga necessários para o sistema, de forma a garantir uma boa performance
organizacional a nível da gestão de stocks e da integração com o sistema de atendimento.
2. Após o levantamento de requisitos faça a respectiva análise desenhando o Diagrama de
Use Cases.

Aula 01 Pratica Analise de Sistemas

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Aula 01 Pratica Analise de Sistemas

Caricato da

Copyright:

Formati disponibili

I

Diagramas de Casos de Uso 2

Diagramas de Casos de Uso 3

Diagramas de Casos de Uso 4

– Um actor é um tipo de utilizador do sistema

Diagramas de Casos de Uso 5

Diagramas de Casos de Uso 6

 Um caso de uso corresponde a:

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

Diagramas de Casos de Uso 7

Um caso de uso é representado por uma elipse, com o

Diagramas de Casos de Uso 8

São representadas normalmente por linhas sem

Diagramas de Casos de Uso 9

Diagramas de Casos de Uso 10

Diagramas de Casos de Uso 11

Diagramas de Casos de Uso 12

extensão caso básico

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

Diagramas de Casos de Uso 13

Podem-se indicar explicitamente os pontos em que um caso

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

Diagramas de Casos de Uso 14

– uma instância do caso de uso A também inclui o comportamento

Diagramas de Casos de Uso 15

Diagramas de Casos de Uso 16

 Aqui significa que o caso de uso "filho" (mais especializado)

– Um cliente empresarial é um (is a) cliente

Diagramas de Casos de Uso 18

Diagramas de Casos de Uso 19

Diagramas de Casos de Uso 20

Diagramas de Casos de Uso 21

Potrebbero piacerti anche