Upload
internet
View
104
Download
0
Embed Size (px)
Citation preview
Prof. Msc. Emerson Silas Dória 1
Análise e Projeto Orientados a Objetocom UML e Padrões
Parte II Planejamento e Elaboração
Prof. Msc. Emerson Silas Dória 2
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
Estudo de Caso: Ponto de Venda
Prof. Msc. Emerson Silas Dória 3
Apresentação
Lógica da Aplicação
Armazenamento
SGBD
Object Store
Enter Item End Sale
UPC
Make Payment
Total
Quantity
Tendered Balance
Venda Pagamento
BD Segurança
foco principal-> objetos de domínio
-> objetos de serviço foco secundário
foco menor
Ênfase do Estudo de Caso: Camada de Lógica da Aplicação
Prof. Msc. Emerson Silas Dória 4
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 5
Definição de Requisitos
a. contínuab. opcionalc. adiáveld. ordem variada
Notas
2. Criar Rel. Prel. de Investigação
3. Definir Requisitos
9. Refinar Plano7. Definir Mod. Conc. Inicial c
4. Reg. Termos no Glossário a
6. Definir Casos de Uso
1. Definir PlanoInicial
5. ImplementarProtótipo
b, d
8. Definir Arquit.Inicial a, c, d
ConstruçãoPlan. &Elaboração
Implantação
Prof. Msc. Emerson Silas Dória 6
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 7
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
Para mais detalhes consultar: Padrão IEEE Std 830-1993
Prof. Msc. Emerson Silas Dória 8
Descrição de Requisitos Alguns artefatos básicos:
Visão geral Sumário descrevendo o propósito geral do projeto
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
Atributos Aspectos não funcionais relevantes
Prof. Msc. Emerson Silas Dória 9
Funções do Sistema Devem ser documentadas e listadas em
grupos logicamente coesos Categorias de funções:
Evidente Deve ser executada, e o usuário deve estar ciente
da execução (Ex.: Registrar Venda, Processar Pagamento)
Oculta 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 10
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 11
Sistema POST Visão geral
O propósito deste projeto é criar um sistema para um terminal de ponto 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 apurada das vendas. Controle automático de estoque.
Prof. Msc. Emerson Silas Dória 12
Sistema POSTFunções Básicas
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.
Evidente
R1.7 Oferecer um mecanismo de armazenamento persistente.
Oculta
Ref # Função Categoria
Prof. Msc. Emerson Silas Dória 13
Sistema POSTFunções Básicas
R1.8 Oferecer mecanismos para comunicação entre processos e entre sistemas.
Oculta
R1.9 Mostrar descrição e preço do item de compra registrado.
Evidente
Ref # Função Categoria
Prof. Msc. Emerson Silas Dória 14
Sistema POSTFunções de Pagamento
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
Ref # Função Categoria
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 15
Sistema POSTRequisitos Não Funcionais
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.
Atributo Detalhes e Restrições de Contorno
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 16
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 17
Casos de Uso
a. contínuab. opcionalc. adiáveld. ordem variada
Notas
2. Criar Rel. Prel. de Investigação
3. Definir Requisitos
9. Refinar Plano7. Definir Mod. Conc. Inicial c
4. Reg. Termos no Glossário a
6. Definir Casos de Uso
1. Definir PlanoInicial
5. ImplementarProtótipo
b, d
8. Definir Arquit.Inicial a, c, d
ConstruçãoPlan. &Elaboração
Implantação
Prof. Msc. Emerson Silas Dória 18
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 19
Exemplo de um caso de uso de alto-nível:
Casos de Uso
Caso de uso:Atores:Tipo:Descrição:
Comprar ItensCliente, OperadorPrimá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 20
Exemplo de um caso de uso expandido:
Casos de Uso
Caso de uso:Atores:Finalidade:Visão Geral:
Comprar Itens com DinheiroCliente, OperadorCapturar 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ênciasCruzadas:
Primário e Essencial
Funções: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1
Prof. Msc. Emerson Silas Dória 21
Casos de UsoSeqüê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. Após processar o último item, o Operador indica ao POST que a entrada de itens terminou.
5. Calcula e mostra o valor total da venda.
6. O Operador informa o total ao Cliente.
1. Este caso de uso começa quando um Cliente chega no caixa (equipado com um POST) com itens que deseja comprar.
Prof. Msc. Emerson Silas Dória 22
Casos de UsoSeqüência Típica de EventosAção do Ator
Resposta do Sistema
8. O Operador registra o valor recebido em dinheiro.
9. Mostra o troco devido e emite um recibo.
10. O Operador deposita o dinheiro e retira o troco devido. O Operador entrega o troco e o recibo ao Cliente.
11. Registra a venda no log de vendas completadas
12. O Cliente sai com os itens comprados.
7. O Cliente entrega um pagamento em dinheiro, possivelmente maior do que o valor total.
Seqüências Alternativas• Linha 7: Cliente não tem dinheiro suficiente. Cancelar transação.
Prof. Msc. Emerson Silas Dória 23
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 24
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 25
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 26
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 27
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 28
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 eventos1. Identificar os eventos externos aos quais o
sistema deve responder2. Relacionar os eventos a atores e casos de
uso
Prof. Msc. Emerson Silas Dória 29
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 30
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 31
Diagramas de Casos de Uso Ilustram um conjunto de casos de uso e
atores para um sistema, os atores e os relacionamentos entre eles.
Caixa
POST
Comprar Itens
Cliente
Log In
Reembolsar Itenscomprados
Prof. Msc. Emerson Silas Dória 32
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 33
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
Comprar Itens
ClienteReembolsar Itens
comprados
Caixa
POST
Comprar Itens
Cliente
Log In
Reembolsar Itenscomprados
Figura 1 Figura 2
Prof. Msc. Emerson Silas Dória 34
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 35
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 36
Formatos de Casos de Uso Trecho do caso de uso essencial
Comprar Itens
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. ...
Seqüência Típica de EventosAção do Ator
Prof. Msc. Emerson Silas Dória 37
Formatos de Casos de Uso Trecho do caso de uso real
Comprar Itens
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. ...
Seqüência Típica de EventosAção do Ator
Prof. Msc. Emerson Silas Dória 38
Casos de Uso com Subseções
Seqüência Típica de EventosAção do Ator
Resposta do Sistema1. Este caso de uso começa quando um Cliente chega no caixa (equipado com um POST) com itens que deseja comprar
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...
Seção: Principal
Caso de uso Comprar Itens expandido
2. (passos intermediários excluídos)
Prof. Msc. Emerson Silas Dória 39
Casos de Uso com Subseções Caso de uso Comprar Itens
expandidoSeqüência Típica de Eventos
Ação do Ator Resposta do Sistema
Seção: Pagamento com Dinheiro
1. O cliente fornece um pagamento em dinheiro – “valor fornecido” – possivelmente maior que o total da venda.2. O Operador registra o valor fornecido
4. O Operador deposita o valor recebido e retira o troco.
O Operador dá o troco ao Cliente.
3. Mostra o troco a devolver ao Cliente
Prof. Msc. Emerson Silas Dória 40
Casos de Uso com Subseções Caso de uso Comprar Itens
expandidoSeqüência Típica de Eventos
Ação do Ator Resposta do Sistema
Seção: Pagamento por Crediário
1. O cliente fornece um pagamento ...
Seqüência Típica de EventosAção do Ator
Resposta do Sistema
Seção: Pagamento por Cheque
1. O cliente fornece um pagamento ...
Prof. Msc. Emerson Silas Dória 41
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 42
Passos do Processo para o Sistema POST Escrever casos de uso no formato alto nível
Caso de uso:Atores:Tipo:Descrição:
Comprar ItensCliente (Iniciador), OperadorPrimá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.
Caso de uso:Atores:Tipo:Descrição:
InicializarGerentePrimá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 43
Passos do Processo para o Sistema POST Desenhar
Diagrama de Casos de Uso
Operador
POST
Comprar Itens
Cliente
Log In
ReembolsarItens Comp.
Gerente
Administrador do Sistema
Iniciar
GerenciarUsuários
ETC
Prof. Msc. Emerson Silas Dória 44
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 45
Diagrama da UML Consulte na página
www2.unoeste.br/~emerson documentos específicos com os detalhes sintáticos da UML.