Você está na página 1de 59

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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


Caso de Uso Atividade Anotação
Componente
Ator

8
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

Modelo de casos de Uso

12
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

Casos de Uso - Atores


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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

Casos de Uso - Atores


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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

Inclusão

Obter Extrato <<include>>

<<include>>

Cliente
Realizar Saques Fornecer Identificação

<<include>>

Realizar Transferência

26
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

Extensão

<<extend>>

Substituir

<<extend>>

Editar Documento
Autor

Corrigir

31
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

Generalização entre Casos de Uso

Realizar Pagamento
Cliente

Realizar pagamento em dinheiro


Realizar pagamento com cartão

34
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

Generalização entre Atores

Reservar Livro

Aluno
Devolver livro

Solicitar Compra de Livro


Professor

36
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

Identificação de Casos de Uso

A partir da lista (inicial) de atores, deve-se passar à


identificação dos casos de uso.

42
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

 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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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
Sistemas de Informação – Engenharia de Software II – Profa. Dra. Ana Paula e Prof. Dr. Fonseca

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