Análise Orientada a
Objeto
com a metodologia (R)UP + UML
© Nabor C. Mendonça 2001
1
Estudo de Caso: Terminal de Venda




Um sistema para um terminal
de venda (TV)
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 TV
© Nabor C. Mendonça 2001
2
Ênfase do Estudo de Caso: Camada de
Lógica da Aplicação
Object Store
Apresentação
UPC
Quantity
Total
Tendered
Enter Item
Balance
End Sale
Foco menor
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
© Nabor C. Mendonça 2001
3
Estratégia da Disciplina


Aprendizagem e desenvolvimento iterativos
APOO aplicada ao sistema TV em duas iterações
ou ciclos de desenvolvimento:
–
Ciclo 1 Funcionalidades básicas
Introdução das habilidades de análise e design pertinentes
ao primeiro ciclo
–
Ciclo 2 Funcionalidades expandidas
Introdução de habilidades adicionais de análise e projeto
© Nabor C. Mendonça 2001
4
Definição de Requisitos
Planejamento
Elaboração
2. Criar Rel. Prel.
de Investigação
1. Definir Plano
Inicial
© Nabor C. Mendonça 2001
Construção
4. Reg. Termos
no Glossário a
5. Implementar
Protótipo
7. Definir Mod.
Conc. Inicial
8. Definir Arquit.
Inicial
a, c, d
c
b, d
3. Definir Requisitos
6. Definir Casos
de Uso
Notas
9. Def. as Demais
Fases
a. contínua
b. opcional
c. adiável
d. ordem variada
5
Definição de Requisitos



Requisitos mal-entendidos ou incorretamente
especificados representam um grande risco para o
desenvolvimento de software
Especificações bem-feitas requerem uma gama de
habilidades e técnicas, cujo estudo detalhado está
fora do escopo do curso
Foco: introdução à especificação de requisitos,
usando o sistema TV como exemplo
© Nabor C. Mendonça 2001
6
O que são Requisitos?



Descrições das necessidades ou desejos para um
produto
Usados para identificar e documentar o que é
realmente necessário, de uma forma que fique
claro para clientes e desenvolvedores
Desafio:
–
Evitar ambigüidades
–
Identificar riscos
–
Coletar e “digerir” dados de fontes variadas de
informação (documentos, entrevistas, reuniões, etc.)
© Nabor C. Mendonça 2001
7
Descrição de Requisitos

Um modelo de documento de requisitos
–
Visão geral
Sumário descrevendo o propósito geral do projeto. Pode
também ser entendido como um documento informal de
requisitos do cliente
–
Clientes
Quem encomendou ou está pagando pelo sistema
–
Objetivos
Objetivos a serem alcançados com o sistema
–
Funções
O que o sistema deve fazer
© Nabor C. Mendonça 2001
8
Funções

Devem ser documentadas e listadas em grupos
logicamente coesos
–

Primeiro passo para a escolha dos use cases
(traduzido por casos de uso)
Categorias de funções
–
Evidente
Deve ser executada, e o usuário deve estar ciente da
execução (ex.: Processar venda, Processar pagamento)
–
Escondida
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
© Nabor C. Mendonça 2001
9
Funções (2)

Funções diretamente relacionadas com o negócio
–
Requisitos funcionais
Devem ser implementadas na fase de Elaboração

Funções não diretamente relacionadas com o negócio
–
Requisitos não funcionais
Igualmente relevantes
Devem ser implementadas na fase de Construção

Exemplos de requisitos não funcionais
–
Facilidade de uso
–
Tolerância a falhas
–
Tempo de resposta
–
Metáfora de interface
–
Guardar informações no BD
© Nabor C. Mendonça 2001
10
Requisitos para o Sistema TV

Visão geral
O propósito deste projeto é criar um sistema de terminais de venda
a ser usado em lojas de varejo.

Clientes
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 acurada das vendas.
Controle automático de estoque.
© Nabor C. Mendonça 2001
11
Requisitos para o Sistema TV (2)

Processar venda
Ref #
Função
Categoria
R1.1
Registrar a venda corrente (itens de compra).
R1.2
Calcular total da venda corrente, incluindo imposto evidente
e descontos.
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 quantidades do estoque quando a venda
for confirmada.
escondida
R1.5
Registrar venda no log de vendas completadas
escondida
R1.6
Oferecer um mecanismo de armazenamento
persistente.
escondida
© Nabor C. Mendonça 2001
evidente
12
Requisitos para o Sistema TV (3)

Processar venda (cont.)
Ref #

Função
Categoria
R1.7
Oferecer mecanismos para comunicação entreprocessos e entre-sistemas.
escondida
R1.8
Mostrar descrição e preço do item de compra
registrado.
evidente
Processar pagamento
Ref #
Função
Categoria
R2.1
Processar pagamento com dinheiro, capturando
quantia oferecida e calculando troco devido.
evidente
R2.2
Processar pagamento com cartão de crédito,
capturando dados do cartão via uma leitora de
cartões ou digitação manual, e autorizando o
pagamento junto a um serviço de autorização de
crédito (externo à loja) via modem.
evidente
© Nabor C. Mendonça 2001
13
Requisitos para o Sistema TV (4)

Processar pagamento (cont.)
Ref #
Função
Categoria
R2.3
Processar pagamento 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 com cartão de crédito junto
ao sistema de contas a receber, uma vez que o
serviço de autorização de crédito deve à loja as
quantias referentes a esses pagamentos.
escondida
© Nabor C. Mendonça 2001
14
Requisitos para o Sistema TV (5)

Requisitos não funcionais valendo para Processar
Venda e Processar Pagamento
Requisito Não Funcional
Comentários
tempo de resposta
Durante o registro de um item de compra, a
descrição e o preço do produto aparecerão em até 5
segundos.
metáfora de interface
Janelas e caixas de diálogo baseadas na metáfora
de formulários.
Maximizar facilidade de navegação via teclado ao
invés de via mouse.
tolerância a falha
Deve registrar pagamentos com cartão de crédito
autorizados junto ao sistema de contas a receber
dentro de 24 horas, mesmo se houver falha de
energia ou nos equipamentos.
plataformas de S.O.
Microsoft Windows XP.
© Nabor C. Mendonça 2001
15
Documentos Derivados Importantes

Glossário (*)

Casos de uso (*)

Modelo conceitual (*)
(*) Explorados no restante da disciplina
© Nabor C. Mendonça 2001
16
Caso de Uso
Planejamento
Elaboração
2. Criar Rel. Prel.
de Investigação
1. Definir Plano
Inicial
© Nabor C. Mendonça 2001
Construção
4. Reg. Termos
no Glossário a
5. Implementar
Protótipo
7. Definir Mod.
Conc. Inicial
8. Definir Arquit.
Inicial
a, c, d
c
b, d
3. Definir Requisitos
6. Definir Use
Cases
Notas
9. Def. Detalhes
das Fases
a. contínua
b. opcional
c. adiável
d. ordem variada
17
Caso de Uso (2)


Como Definir um Caso de Uso?
–
Denominar casos de uso com expressões
começando sempre por um verbo
–
O foco deve ser em casos de uso no nível de
processos elementares de negócio (“elementary
business processes” (EBP))
“Elementary Business Process”
–
O termo EBP é definido como:
Uma função – sub-funções relacionadas -- executada por um
ator em um lugar e em um dado momento, diretamente
relacionada com o negócio. A função não pode ser nem muito
pequena, e nem grande demais. Como regra de bolso, poucos
passos (de cinco a dez), durando de minutos a no máximo
uma hora.
© Nabor C. Mendonça 2001
18
Caso de Uso (3)

Com Relação ao Estudo de Caso
–
Log In de um caixa em um terminal é um exemplo de
uma função que não é diretamente relacionada com
o negócio Vendas, logo não pode ser um caso de
uso EBP
–
Pagar com Cartão de Crédito é um caso de uso
demasiadamente pequeno para ser um EBP
–
O caso de uso Pagar  que generaliza (<<is_a>>) os
casos de uso Pagar com Dinheiro, Pagar com Cartão
de Crédito e Pagar com Cheque  ainda é pequeno
(poucos minutos).
© Nabor C. Mendonça 2001
19
Caso de Uso (4)
–


Um bom candidato a caso de uso EBP para o
Sistema TV é o caso de uso Processar Vendas de
um carrinho de compras, que inclui o caso de uso
Pagar
Deve ficar claro então que um caso de uso EBP
deve ter tamanho suficiente para ser
recursivamente decomposto, se for conveniente,
em subcasos de uso
Casos de uso EBP são o foco da fase de
Elaboração do processo UP
© Nabor C. Mendonça 2001
20
Caso de Uso (5)

Processo para Descobrir Atores, Necessidades
dos Atores, e Casos de Uso EBP
P1. Determinar as fronteiras do sistema
P2. Identificar os atores primários  aqueles que
solicitam diretamente serviços do sistema – ou
executam funções do sistema -- para realizar o
negócio
P3. Para cada ator primário, identificar seus casos de
uso
P4. Distinguir os casos de uso EBP
© Nabor C. Mendonça 2001
21
Caso de Uso (6)

Estudo de Caso
–
Atores Primários
Caixa, Gerente, …
–
Atores Secundários
Cliente, …
© Nabor C. Mendonça 2001
22
Caso de Uso (9)


Níveis de detalhe:
–
Expandido  o mais elaborado. Todos os passos são escritos
em detalhes, segundo o padrão definido em www.usecases.org
– template. O caso de uso Processar Vendas será descrito
seguindo esse formato
–
De alto nível  alguns parágrafos informais
Casos de Uso e o Processo UP
–
Casos de uso EBP são tratados nas fases de Planejamento e
Elaboração
O nível de detalhe é sempre expandido
–
Casos de uso ñ-EBP são tratados na fase de Construção
–
As iterações da Etapa de Elaboração do Processo UP podem
ainda refinar casos de uso EBP. Refinamentos sucessivos
estão na essência do UP
© Nabor C. Mendonça 2001
23
Caso de Uso (10)

Casos de Uso expandidos
–
Diagrama UML de Caso de Uso
Decomposição em subcasos de uso
Visão geral do caso de uso raiz
–
Texto complementar segundo o padrão
www.usecases.org – template
Colunado
Colunas Ator Sistema
Passos seqüênciais
Português estruiturado
© Nabor C. Mendonça 2001
24
Casos de Uso e Funções

Todas as funções do sistema identificadas na
especificação dos requisitos devem ser
contempladas nos casos de uso
–
Seção Referência
© Nabor C. Mendonça 2001
25
Caso de Uso e Outros Artefatos

Casos de Uso e Outros Artefatos
–
Casos de uso são as fontes de informação para
Encontrar conceitos ou entidades para o modelo conceitual
Encontrar as operações e consultas de sistema, que darão
origem aos métodos que fazem a interface do sistema com o
mundo externo
© Nabor C. Mendonça 2001
26
Caso de Uso e Outros Artefatos (2)
© Nabor C. Mendonça 2001
27
Casos de Uso para o Sistema TV
Ator Primário
Casos de Uso
Caixa
Processar vendas;
Log in;
Log out;
...
Gerente
Iniciar terminal (start up)
Encerrar terminal (shut down)
…
…
…
© Nabor C. Mendonça 2001
28
Sistema TV (2)
Caso de Uso
EBP?
Nível de Detalhe
Processar Vendas
Sim
Expandido
Log In
Não
Alto Nível
Log Out
Não
Alto Nível
Iniciar Terminal
Não
Alto Nível
Encerrar Terminal
Não
Alto Nível
…
…
…
© Nabor C. Mendonça 2001
29
Sistema TV (3)

Diagrama parcial para o sistema TV
TV
Processar
Venda
Caixa
Cliente
Log In
Log Out
© Nabor C. Mendonça 2001
30
Sistema TV (4)

Exemplo de um caso de uso de alto-nível (Fase de
Planejamento)
Caso de uso:
Atores:
Descrição:

Português simples ou não estruturado
–

Processar Venda
Caixa
Um Cliente chega no caixa com itens para comprar. O
Caixa registra os itens e coleta o pagamento. Ao final,
o Cliente sai com os itens.
Semelhante a user stories em processos ágeis
Lembre-se: um caso de uso EBP, como é o caso,
em alguma iteração da Fase de Elaboração terá
que ser expandido
© Nabor C. Mendonça 2001
31
Sistema TV (5)

Caso de uso expandido
–
Um diagrama de caso de uso ajuda a dar uma visão
geral
Processar
Venda
Uma
Iteração
<<include>>
<<include>>
<<include>>
Registrar
Item
<<include>>
Atualizar
Total
© Nabor C. Mendonça 2001
Arquivar
Arquivar
a Venda
A
Venda
Pagar
(Dinheiro)
<<extend>>
Anular
Item
<<extend>>
Anular
Venda
32
Sistema TV (6)

Exemplo de um caso de uso expandido
–
Colunado
–
Português estruturado
Caso de uso:
Atores:
Propósito:
Descrição:
Referencia:
Processar venda (1ª. Iteração)
Caixa
Capturar uma venda e seu pagamento em dinheiro.
Um Cliente chega no caixa com itens para comprar. O
Caixa registra os itens e coleta um pagamento com
dinheiro. Ao final, o Cliente sai com os itens.
Funções: R1.1, R1.2, R1.3, R1.5, R1.8, R2.1
Típica Seqüência de Eventos
Ação do Ator
Resposta do Sistema
1. Este caso de uso começa
quando um Cliente chega no
caixa com itens para comprar.
© Nabor C. Mendonça 2001
33
Sistema TV (7)

Exemplo de um use case expandido (cont.)
Típica Seqüência de Eventos
Ação do Ator
2. O Caixa registra o identificador
de cada item.
Se há mais de um do mesmo
item, o Caixa também pode informar a quantidade.
4. Após processar o último item, o
Caixa indica ao TV que a entrada
de itens terminou.
6. O Caixa informa o total ao
Cliente.
© Nabor C. Mendonça 2001
Resposta do Sistema
3. Determina o preço do item e
adiciona informação sobre o item
à transação de venda em andamento.
Mostra a descrição e o preço do
item corrente. Atualiza o total.
5. Calcula e mostra o valor total
da venda.
.
34
Sistema TV (8)

Exemplo de um use case expandido (cont.)
Típica Seqüência de Eventos
Ação do Ator
Resposta do Sistema
7. O Cliente entrega um valor em
dinheiro, possivelmente maior do
que o valor total.
8. O Caixa registra o valor
recebido em dinheiro.
9. Mostra o troco devido.
Emite um recibo.
10. O Caixa deposita o dinheiro e
retira o troco devido.
O Caixa entrega o troco e o
recibo ao Cliente.
12. O Cliente sai com os itens
comprados.
11. Registra a venda no log de
vendas completadas.
© Nabor C. Mendonça 2001
.
35
Sistema TV (9)

Exemplo de um use case expandido (cont.)
Seqüências Alternativas
• Linha 2a: Registro de um identificador inválido. Mostrar erro.
• Linha 7a: Cliente não tem dinheiro suficiente. Cancelar transação.

Seqüencias alternativas devem formar um bloco
separado, com o cabeçalho Fluxo Alternativo
–
O fluxo sem erros ou exceções é chamado de Fluxo
Básico
.
© Nabor C. Mendonça 2001
36
C a s o d e U s o : L o c a r F ita s
F lu xo P rin cip al:
T ratam en to d e E xceçõ es:
1. O cliente chega ao balcão com as
fitas que deseja locar.
3a. O cliente não possui cadastro.
2. O cliente inform a seu nom e e
entrega as fitas ao funcionário.
3. O funcionário registra o nom e do
cliente e inicia a locação.
4. O funcionário registra cada um a das
fita s.
5. O funcionário finaliza a locação,
dev olv e as fitas ao cliente e lhe
inform a a data de dev olução e o v alor
total da locação.
6. O cliente v ai em bora com as fitas.
3a.1 O cliente dev e inform ar seus dado s para
cadastro.
3a.2 O funcionário registra o cadastro.
3a.3 R etorna ao flux o principal no passo 3.
3b. O cliente possui pendências no cadastro (locação
anterior não foi paga).
3b.1 O cliente paga seu débito.
3b.2 O funcionário registra a qu itação do débito,
elim inando assim a pendência.
3b.3 R etorna ao passo 3.
4a. U m a fita está reserv ada para outro cliente.
4a.1 O funcionário inform a que a fita não está
disponív el para locação.
4a.2 P rosseg ue a locação do passo 4 sem incluir
a fita reserv a d a .
4b. U m a fita está danificada.
Caso de Uso com
Exceções
4b.1 O funcionário inform a que a fita está
danificada.
4b.2 O funcionário registra que a fita está
danificada.
4b.3 O funcionário v erifica se existe outra fita
disponív el com o m esm o film e.
© Nabor C. Mendonça 2001
4b.3 S e existir, o funcionário s ubstitui a fita e
segu e no passo 4, senã o segu e do passo 4 sem
incluir a fita danificada.
37
Casos de Uso com Subseções

Caso de uso Processar venda expandido
Seção: Principal
Ação do Ator
Resposta do Sistema
1. ...
2. O Cliente escolhe o tipo de
pagamento:
a) Se pagamento com dinheiro,
veja seção Pagamento com
Dinheiro.
b) ...
Seção: Pagamento com Dinheiro
Ação do Ator
Resposta do Sistema
1. O Cliente entrega um pagamento em dinheiro ...
© Nabor C. Mendonça 2001
38
Escalonando os Casos de Uso do Sistema TV


Criando múltiplas versões de Processar Venda
Cada versão é o resultado de uma iteração da Fase
de Elaboração
–
Iteração 1: apenas pagamentos com dinheiro, sem
atualização de estoque, ...
–
Versão 2: permite todos os tipos de pagamento
–
Versão 3: versão completa, incluindo atualização de
estoque
© Nabor C. Mendonça 2001
39