prof. msc. emerson silas dória1 análise e projeto orientados a objeto com uml e padrões parte ii...

Prof. Msc. Emerson Silas Dória 1

Análise e Projeto Orientados a Objetocom UML e Padrões

Parte II Planejamento e Elaboração


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


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


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


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


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.


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


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


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


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


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.


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


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



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


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


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.


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


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


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


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


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


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.


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.


Casos de Uso Se complexas, seqüências alternativas

podem ser expandidas para formar os seus próprios casos de uso


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


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.


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


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


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


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?


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


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


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


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


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


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


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


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. ...



Casos de Uso com Subseções


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)


Casos de Uso com Subseções Caso de uso Comprar Itens

expandidoSeqüência Típica de Eventos


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


Casos de Uso com Subseções Caso de uso Comprar Itens

expandidoSeqüência Típica de Eventos


Seção: Pagamento por Crediário

1. O cliente fornece um pagamento ...


Resposta do Sistema

Seção: Pagamento por Cheque

1. O cliente fornece um pagamento ...


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


Passos do Processo para o Sistema POST Escrever casos de uso no formato alto nível


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.


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.


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


Passos do Processo para o Sistema POST Escrever casos de uso mais importantes

no formato essencial expandido Exemplo Completo


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ória1 análise e projeto orientados a objeto com uml e padrões parte ii...

Documents