Análise e Projeto
Orientados a Objeto
com UML e Padrões
Parte II
Planejamento e Elaboração
Prof. Msc. Emerson Silas Dória
1
Estudo de Caso: Ponto de
Venda




Um sistema para um terminal
de ponto de venda (POST)
Usado para registrar vendas e processar
pagamentos de clientes em lojas de varejo
Inclui componentes de hardware
(computador, leitora de código de barras) e
o software para rodar o sistema
Tarefa: criar o software para um POST
Prof. Msc. Emerson Silas Dória
2
Ênfase do Estudo de Caso:
Camada de Lógica da Aplicação
Object Store
Apresentação
UPC
Quantity
foco menor
Total
Tendered
Enter Item
Balance
End Sale
Make Payment
Lógica da Aplicação
-> objetos de domínio
Venda
Pagamento
foco principal
-> objetos de serviço
BD
Segurança
foco secundário
Armazenamento
SGBD
Prof. Msc. Emerson Silas Dória
3
Estratégia


Aprendizado e desenvolvimento iterativos
APOO aplicada ao sistema POST em dois
ciclos de desenvolvimento:

Ciclo 1: Funcionalidades básicas


Introdução das habilidades de análise e projeto
Ciclo 2 Funcionalidades expandidas

Introdução de habilidades adicionais de análise e
projeto
Prof. Msc. Emerson Silas Dória
4
Definição de Requisitos
Plan. &
Elaboração
Construção
Implantação
1. Definir Plano
Inicial
2. Criar Rel. Prel.
de Investigação
3. Definir Requisitos
4. Reg. Termos
no Glossário a
5. Implementar
Protótipo
6. Definir Casos
de Uso
Notas
7. Definir Mod.
Conc. Inicial c
8. Definir Arquit.
Inicial
a, c, d
9. Refinar Plano
a. contínua
b. opcional
c. adiável
d. ordem variada
b, d
Prof. Msc. Emerson Silas Dória
5
Definição de Requisitos



Especificações de requisitos corretas e
abrangentes são essenciais para um projeto
bem sucedido.
Especificações corretas requerem habilidades
e técnicas para sua construção.
Objetivo: Capacitar o analista para expressar
requisitos, utilizando artefatos da APOO.
Prof. Msc. Emerson Silas Dória
6
O que são Requisitos?



Descrição das necessidades ou dos desejos
para um produto (software)
Objetiva identificar e documentar o que é
realmente necessário, de forma clara tanto
para clientes como para desenvolvedores
Desafios:


Evitar ambigüidades
Identificar riscos
Prof. Msc. Emerson Silas Dória
Para mais detalhes
consultar: Padrão
IEEE Std 830-1993
7
Descrição de Requisitos

Alguns artefatos básicos:

Visão geral


Clientes


Objetivos a serem alcançados com o sistema
Funções


Quem encomendou ou está pagando pelo sistema
Objetivos


Sumário descrevendo o propósito geral do projeto
O que o sistema deve fazer
Atributos

Aspectos não funcionais relevantes
Prof. Msc. Emerson Silas Dória
8
Funções do Sistema


Devem ser documentadas e listadas em
grupos logicamente coesos
Categorias de funções:

Evidente


Oculta


Deve ser executada, e o usuário deve estar ciente da
execução (Ex.: Registrar Venda, Processar Pagamento)
Deve ser executada, mas de modo transparente para o
usuário (Ex.: Guardar informações no BD)
Opcional

Função não afeta os custos ou as outras funções do
sistema de maneira significativa
Prof. Msc. Emerson Silas Dória
9
Requisitos Não-Funcionais

Características não funcionais do sistema



Ex.: facilidade de uso, tolerância a falhas, tempo
de resposta.
Podem estar relacionados com todas as
funções, ou ser específicos para uma função
ou um grupo de funções
Deveriam estar presentes no documento de
requisitos
Prof. Msc. Emerson Silas Dória
10
Sistema POST

Visão geral


Clientes


O propósito deste projeto é criar um sistema para
um terminal de ponto de venda a ser usado em
lojas de varejo.
ObjectStore, Inc., uma cadeia de lojas de venda
de componentes de software reutilizáveis.
Objetivos



Redução do tempo de espera dos clientes nos
caixas.
Análise rápida e apurada das vendas.
Controle automático de estoque.
Prof. Msc. Emerson Silas Dória
11
Sistema POST
Funções Básicas
Ref #
Função
Categoria
R1.1
Registrar a venda corrente (itens de compra).
Evidente
R1.2
Calcular o total da venda corrente, incluindo
imposto e descontos.
Evidente
R1.3
Capturar informação do código de barras dos
itens de compra (UPC), via uma leitora de código
de barras ou digitação manual.
Evidente
R1.4
Reduzir as quantidades em estoque quando uma
venda é confirmada.
Oculta
R1.5
Registrar as venda realizadas.
Oculta
R1.6
O operador do caixa deve digitar um ID e senha
para usar o sistema.
R1.7
Oferecer um mecanismo de armazenamento
persistente.
Prof. Msc. Emerson Silas Dória
Evidente
Oculta
12
Sistema POST
Funções Básicas
Ref #
Função
R1.8
Oferecer mecanismos para comunicação entre
processos e entre sistemas.
R1.9
Mostrar descrição e preço do item de compra
registrado.
Prof. Msc. Emerson Silas Dória
Categoria
Oculta
Evidente
13
Sistema POST
Funções de Pagamento
Ref #
Função
Categoria
R2.1
Processar pagamentos em dinheiro, capturando
quantia recebida e calculando o troco.
Evidente
R2.2
Processar pagamentos com cartão de crédito,
capturando dados do cartão via uma leitora de
cartões ou digitação manual, e autorizar o
pagamento junto a um serviço de autorização de
crédito (externo à loja) via modem.
Evidente
R2.3
Processar pagamentos com cheque, capturando
dados de identificação do cliente via digitação
manual, e autorizando o pagamento junto a um
serviço de autorização de cheque (externo à loja)
via modem.
Evidente
R2.4
Registrar pagamentos de prestações para o
sistema de contas a receber, uma vez que o
serviço de autorização de créditos (operadoras de
cartão) deve à loja o valor a ser pago.
Oculta
Prof. Msc. Emerson Silas Dória
14
Sistema POST
Requisitos Não Funcionais
Atributo
Detalhes e Restrições de Contorno
Tempo de Resposta
(restrição de limites) Durante o registro de um item
de compra, a descrição e o preço do produto
aparecerão em até 5 segundos.
Interface
(detalhe) Janelas e caixas de diálogo baseadas na
metáfora de formulários.
(detalhe) Maximizar facilidade de navegação via
teclado ao invés de via mouse.
Tolerância a Falha
(restrição de limites) Deve registrar os pagamentos
autorizados com cartão de crédito junto ao sistema
de contas a receber dentro de 24 horas, mesmo se
houver falha de energia ou nos equipamentos.
Plataformas de S.O.
(detalhe) Microsoft Windows 95/98/2000/NT.
Prof. Msc. Emerson Silas Dória
15
Outros Artefatos Importantes







Equipes de Trabalho
Grupos Afetados
Pré-suposições
Dependências
Glossário *
Casos de Uso *
Modelo Conceitual Inicial *
* serão apresentados posteriormente
Prof. Msc. Emerson Silas Dória
16
Casos de Uso
Plan. &
Elaboração
Construção
Implantação
1. Definir Plano
Inicial
2. Criar Rel. Prel.
de Investigação
3. Definir Requisitos
4. Reg. Termos
no Glossário a
5. Implementar
Protótipo
6. Definir Casos
de Uso
7. Definir Mod.
Conc. Inicial c
8. Definir Arquit.
Inicial
a, c, d
b, d
9. Refinar Plano
Prof. Msc. Emerson Silas Dória
Notas
a. contínua
b. opcional
c. adiável
d. ordem variada
17
Casos de Uso


Descrições narrativas de processos do
domínio da aplicação
Documentam a seqüência de eventos
de um ator (um agente externo)
usando o sistema para completar, do
início ao fim, um determinado processo
Prof. Msc. Emerson Silas Dória
18
Casos de Uso

Exemplo de um caso de uso de alto-nível:
Caso de uso:
Atores:
Tipo:
Descrição:

Comprar Itens
Cliente, Operador
Primário (Será apresentado posteriormente)
Um Cliente chega no caixa, com itens que deseja
comprar. O Operador registra os itens de compra e
recebe o pagamento. Ao final, o Cliente deixa a loja
com os itens.
A UML não especifica um formato rígido para
os cabeçalhos e a estrutura de Casos de Uso

Podem ser alterados de acordo com as
necessidades de documentação
Prof. Msc. Emerson Silas Dória
19
Casos de Uso

Exemplo de um caso de uso expandido:
Caso de uso:
Atores:
Finalidade:
Visão Geral:
Comprar Itens com Dinheiro
Cliente, Operador
Capturar uma venda e seu pagamento em dinheiro.
Um Cliente chega no caixa, com itens que deseja
comprar. O Operador registra os itens de compra e
recebe um pagamento em dinheiro. Ao final, o Cliente
deixa a loja com os itens.
Tipo:
Referências
Cruzadas:
Primário e Essencial
Funções: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1
Prof. Msc. Emerson Silas Dória
20
Casos de Uso
Seqüência Típica de Eventos
Ação do Ator
1. Este caso de uso começa
quando um Cliente chega no
caixa (equipado com um POST)
com itens que deseja comprar.
2. O Operador registra o
identificador de cada item.
Se houver mais de um exemplar
do mesmo item, o Operador
também pode informar a
quantidade.
4. Após processar o último item, o
Operador indica ao POST que a
entrada de itens terminou.
6. O Operador informa o total ao
Cliente.
Resposta do Sistema
3. Determina o preço do item e
adiciona informação sobre o item
à transação de venda corrente.
Mostra a descrição e o preço do
item corrente.
5. Calcula e mostra o valor total
da venda.
Prof. Msc. Emerson Silas Dória
21
Casos de Uso
Seqüência Típica de Eventos
Ação do Ator
Resposta do Sistema
7. O Cliente entrega um
pagamento
em
dinheiro,
possivelmente maior do que o
valor total.
9. Mostra o troco devido e emite
8. O Operador registra o valor
um recibo.
recebido em dinheiro.
10. O Operador deposita o
11. Registra a venda no log de
dinheiro e retira o troco devido.
vendas completadas
O Operador entrega o troco e o
recibo ao Cliente.
12. O Cliente sai com os itens
comprados.
Seqüências Alternativas
• Linha 7: Cliente não tem dinheiro suficiente. Cancelar transação.
Prof. Msc. Emerson Silas Dória
22
Casos de Uso

Se complexas, seqüências alternativas podem
ser expandidas para formar os seus próprios
casos de uso
Prof. Msc. Emerson Silas Dória
23
Tipos de Caso de Uso

Primário
Representam os processos principais ou mais
comuns

Secundário
Representam processos menos importantes ou
mais raros

Opcional
Representam processos que podem ser ignorados
ou incluídos em futuras versões do sistema
Prof. Msc. Emerson Silas Dória
24
Atores

Entidades externas ao sistema que de
algum modo participam da história do
caso de uso


Estimulam o sistema com eventos de
entrada, ou recebem alguma coisa dele
Designados pelo papel que exercem no
caso de uso

Ex.: Cliente, Operador, etc.
Prof. Msc. Emerson Silas Dória
25
Atores

Um caso de uso possui um ator iniciador, que
gera o estímulo inicial e, possivelmente,
vários atores participantes


O ator iniciador deve ser indicado explicitamente
na descrição do caso de uso
Tipos de atores incluem:



papéis exercidos por pessoas
sistemas de computação
dispositivos elétricos e mecânicos
Prof. Msc. Emerson Silas Dória
26
Enganos com Casos de Uso

Um erro comum é representar como
casos de usos passos individuais,
operações, ou transações


Ex: Comprar Itens x Imprimir Recibo
Um caso de uso é uma descrição de
ponta a ponta, de um processo
relativamente grande, que inclui, muitos
passos ou transações
Prof. Msc. Emerson Silas Dória
27
Identificando Casos de Uso

Método baseado em atores
1. Identificar os atores relacionados a um sistema ou
organização
2. Para cada ator, identificar os processos que eles
iniciam ou dos quais eles participam

Método baseado em eventos
1. Identificar os eventos externos aos quais o
sistema deve responder
2. Relacionar os eventos a atores e casos de uso
Prof. Msc. Emerson Silas Dória
28
Identificando Casos de Uso

Exemplos para o sistema POST de alguns
atores possivelmente relevantes e os
processos que ele iniciam:

Operador: Login, Registrar Retirada de Dinheiro

Cliente: Comprar Itens, Devolver Itens

Digitar Senha?

Imprimir Recibo?
Prof. Msc. Emerson Silas Dória
29
Casos de Uso, Funções e
Rastreabilidade

Todas as funções do sistema identificadas na
especificação dos requisitos deveriam ser
alocadas a casos de usos

Alocação documentada através da seção
Referência

Idealmente, funções e casos de uso devem
ser rastreáveis até a implementação e teste
do sistema
Prof. Msc. Emerson Silas Dória
30
Diagramas de Casos de Uso

Ilustram um conjunto de casos de uso e
atores para um sistema, os atores e os
relacionamentos entre eles.
POST
Comprar Itens
Caixa
Cliente
Log In
Reembolsar Itens
comprados
Prof. Msc. Emerson Silas Dória
31
Sistemas e suas Fronteiras


Identificar os atores e casos de uso de um
sistema requer a definição de seu limite de
atuação
Alguns limites típicos incluem:




o software/hardware de um dispositivo ou sistema
de computação
um departamento de uma organização
uma organização inteira
Limites diferentes podem resultar em
diferentes conjuntos de atores e casos de uso
Prof. Msc. Emerson Silas Dória
32
Sistemas e suas Fronteiras

Exemplo de um diagrama de caso de uso
para o sistema POST, quando o limite de
atuação é a loja inteira (Figura 1).
Loja
POST
Comprar Itens
Comprar Itens
Caixa
Cliente
Log In
Cliente
Reembolsar Itens
comprados
Figura 1
Reembolsar Itens
comprados
Prof. Msc. Emerson Silas Dória
Figura 2
33
Formatos de Casos de Uso

Alto nível



Breve descrição de um processo, normalmente em
duas ou três frases, e deliberadamente vago sobre
decisões de projeto
Criados na fase inicial de requisitos
Expandido



Descrição passo a passo dos eventos de um
processo
Durante a fase de requisitos, apenas os casos de
uso mais importantes devem ser escritos nesse
formato
Existência da seção Seqüência Típica de Eventos
Prof. Msc. Emerson Silas Dória
34
Formatos de Casos de Uso

Essencial



Descrição de um processo em termos das suas
atividades essenciais e motivação
Expressos relativamente livres de detalhes de
implementação, decisões de projeto, e uso de
tecnologias
Real

Descrição de um processo em termos de seu
projeto real, comprometido com tecnologias de
desenvolvimento, interfaces de entrada e saída
Prof. Msc. Emerson Silas Dória
35
Formatos de Casos de Uso

Trecho do caso de uso essencial
Comprar Itens
Seqüência Típica de Eventos
Ação do Ator
Resposta do Sistema
2. O Operador registra o
identificador de cada item.
Se houver mais de um exemplar
do mesmo item, o Operador
também pode informar a
quantidade.
3. Determina o preço do item e
adiciona informação sobre o item
à transação de venda corrente.
Mostra a descrição e o preço do
item corrente.
4. ...
5. ...
Prof. Msc. Emerson Silas Dória
36
Formatos de Casos de Uso

Trecho do caso de uso real
Comprar Itens
Seqüência Típica de Eventos
Ação do Ator
Resposta do Sistema
2. Para cada item, o Operador
digita o código universal de
produto (UPC) no campo de
entrada UPC da Janela 1. Ele
então pressiona o botão “Entra
Item” com o mouse ou pressiona
a tecla <Enter>.
3. Determina o preço do item e
adiciona informação sobre o item
à transação de venda corrente.
Mostra a descrição e o preço do
item corrente na Caixa de Texto 2
da Janela 1.
4. ...
5. ...
Prof. Msc. Emerson Silas Dória
37
Casos de Uso com Subseções

Caso de uso Comprar Itens expandido
Seção: Principal
Seqüência Típica de Eventos
Ação do Ator
Resposta do Sistema
1. Este caso de uso começa
quando um Cliente chega no
caixa (equipado com um POST)
com itens que deseja comprar
2.
(passos
intermediários
excluídos)
3. O Cliente escolhe o tipo de
pagamento:
a) Se pagamento em dinheiro,
ver seção Pagar com
Dinheiro.
b) Se pagamento pro crediário,
ver seção...
Prof. Msc. Emerson Silas Dória
38
Casos de Uso com Subseções

Caso de uso Comprar Itens expandido
Seção: Pagamento com Dinheiro
Seqüência Típica de Eventos
Ação do Ator
1. O cliente fornece um
pagamento em dinheiro – “valor
fornecido” – possivelmente maior
que o total da venda.
2. O Operador registra o valor
fornecido
Resposta do Sistema
3. Mostra o troco a devolver ao
Cliente
4. O Operador deposita o valor
recebido e retira o troco.
O Operador dá o troco ao Cliente.
Prof. Msc. Emerson Silas Dória
39
Casos de Uso com Subseções

Caso de uso Comprar Itens expandido
Seção: Pagamento por Crediário
Seqüência Típica de Eventos
Ação do Ator
1. O cliente fornece um
pagamento ...
Resposta do Sistema
Seção: Pagamento por Cheque
Seqüência Típica de Eventos
Ação do Ator
1. O cliente fornece um
pagamento ...
Resposta do Sistema
Prof. Msc. Emerson Silas Dória
40
Casos de Uso dentro de um
Processo de Software

Passos da fase de Planejamento e Elaboração
1. Após as funções do sistema terem sido descritas, defina
a fronteira de atuação do sistema e identifique atores e
casos de uso.
2. Escreva todos os casos de uso no formato alto-nível,
categorizando-os como primário, secundário ou
opcional.
3. Desenhe um diagrama de casos de uso.
4. Relacione casos de uso e ilustre seus relacionamentos
no diagrama de casos de uso. (*)
5. Escreva os casos de uso mais importantes ou críticos no
formato essencial expandido.
6. Se estritamente necessário, escreva alguns casos de uso
no formato real.
7. Ordene os casos de uso por prioridade de
desenvolvimento. (*)
* Será apresentado posteriormente
Prof. Msc. Emerson Silas Dória
41
Passos do Processo para o
Sistema POST

Escrever casos de uso no formato alto nível
Caso de uso:
Atores:
Tipo:
Descrição:
Caso de uso:
Atores:
Tipo:
Descrição:
Comprar Itens
Cliente (Iniciador), Operador
Primário
Um Cliente chega no caixa, com itens que deseja
comprar. O Operador registra os itens de compra e
recebe o pagamento. Ao final, o Cliente deixa a loja
com os itens.
Inicializar
Gerente
Primário
Um Gerente liga um POST para ser usado pelos
Operadores. O Gerente certifica-se de que a data e
hora estão corretas, após o sistema está pronto para
uso.
Prof. Msc. Emerson Silas Dória
42
Passos do Processo para o
Sistema POST

Desenhar
Diagrama
de Casos
de Uso
POST
Comprar Itens
Operador
Cliente
Log In
Reembolsar
Itens Comp.
Iniciar
Gerente
Gerenciar
Usuários
Administrador
do Sistema
Prof. Msc. Emerson Silas Dória
ETC
43
Passos do Processo para o
Sistema POST

Escrever casos de uso mais importantes no
formato essencial expandido

Exemplo Completo
Prof. Msc. Emerson Silas Dória
44
Diagrama da UML

Consulte na página
www2.unoeste.br/~emerson
documentos específicos com os
detalhes sintáticos da UML.
Prof. Msc. Emerson Silas Dória
45