Concepção e Elaboração

Análise e Projeto Orientado a Objetos

UNIVERSIDADE ESTADUAL PAULISTAINSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA

Concepção e Elaboração

Estudo de Caso: Terminal de Ponto de Venda

Objetivo: Definir um dos estudos de caso usado na disciplina

O Sistema TPV

• Um TPV é um sistema computadorizado usado para registrar vendas e cuidar de pagamentos; é tipicamente usado em vendas a varejo. Ele inclui componentes vendas a varejo. Ele inclui componentes de hardware, tais como um computador e um leitor de código de barras, e o software para rodar o sistema.

O Sistema TPV

ClienteTerminal de Ponto de Vendas (TPV) Caixa

O Sistema TPV

• TPV tem interfaces com várias aplicações de serviço:– Aplicação de cálculo de imposto de renda– Aplicação de controle de estoque

• Devem ser tolerantes a falhas• Devem ser tolerantes a falhas• Um TPV deve dar suporte de forma incremental

a múltiplos e variados terminais e interfaces no lado do cliente.

• Um TPV é um sistema comercial que pode ser vendido a diferentes clientes, com necessidades diferentes em termos de regras de negócio.

Arquitetura

• É um sistema de informação típico e pode ser visualizado em várias camadas:

• Apresentação: interface gráfica, janelas.• Lógica da aplicação (ou do negócio) - objetos do

domínio do problema: representam os conceitos do domínio do problema que atendem aos requisitos do domínio do problema que atendem aos requisitos do sistema. Ex: venda.

• Lógica da aplicação – objetos de serviços : objetos e subsistemas de uso geral que fornecem serviços técnicos de apoio. São independentes da aplicação e podem ser reutilizados por outros sistemas.

• Armazenamento – mecanismo de armazenamento persistente. Ex: BDOO ou BD Relacional

A Análise e o projeto orientado a objetos são geralmente mais relevantes para a modelagem das camadas da lógica da modelagem das camadas da lógica da aplicação e das camadas de serviço.

Arquitetura (cont.)

• Nesta abordagem, as janelas da interface não contém código que trata da lógica ou do processamento da aplicação � a camada de interface é fina (cliente magro, camada de interface é fina (cliente magro, ou leve). As solicitações de tarefas são repassadas para outras camadas.

Estratégia de Desenvolvimento e Aprendizado Iterativos

• Primeiro ciclo: funções principais da aplicação.– É apresentado o conjunto central de tópicos

da análise, padrões de projeto OO e da da análise, padrões de projeto OO e da notação UML.

• Ciclos posteriores: expansão das funcionalidades do sistema.– Introduz-se novas idéias, notações UML e

novos padrões de projeto OO.

As fases de Concepção e Elaboração

Concepção

• Passo inicial curto, no qual explora-se as seguintes questões:– Qual é a visão e o caso de negócio para o

projeto?projeto?– Ele é viável?– Devemos construir ou comprar?– Estimativa de custo aproximada: qual a

ordem de grandeza?– Devemos continuar ou parar?

A concepção, em uma frase:Conceber o escopo do produto, a visão e o caso de negócio.

O problema principal a ser resolvido, em duas frases:O problema principal a ser resolvido, em duas frases:

Os interessados no projeto do sistema tem um consenso básico sobre

A visão do projeto? Vale a pena investir em uma investigação séria?

Compreensão dos Requisitos

(Concepção e Elaboração)

Concepção e Elaboração

• Definir Rascunho do Plano• Criar Relatório de Investigação Preliminar• Definir Requisitos• Registrar termos no Glossário• Registrar termos no Glossário• Implementar Protótipo• Definir Casos de Uso• Definir rascunho do modelo conceitual• Definir rascunho da arquitetura do sistema• Refinar plano

Entendimento dos Requisitos

• Objetivos:– Criar os artefatos da fase de engenharia de

requisitos– Identificar e categorizar as funções do – Identificar e categorizar as funções do

sistema– Identificar e categorizar os atributos do

sistema e relacioná-los com as funções

Relacionamento entre os artefatos das fases concepção e elaboração

Elaborar:

....

Especificação de Requisitos

Casos de Usoa. Todos os de alto nívelb. Alguns essenciais

Relatório deInvestigação

Preliminar

ConcepçãoElaboração

3. Definir requisitos

....

Engenharia de

Requisitos

b. Alguns essenciais expandidos

Diagrama de Casos de Uso

Esboço do modeloConceitual

Orçamento,

Cronograma

Protótipos

Glossário

Depende de

REQUISITOS

• Requisitos são uma descrição das necessidades de um produto.

• Objetivo da fase de requisitos: identificar e documentar o que realmente é necessário

• O artefato Documento de Especificação de • O artefato Documento de Especificação de Requisitos deve conter:– Descrição Geral do Sistema– Clientes– Objetivos do Sistema– Funções do Sistema– Atributos do Sistema

Funções do Sistema

• São o que o sistema deve fazer. Exemplo: autorizar o pagamento por cartão de crédito.

• As funções devem ser identificadas e listadas em agrupamentos lógicos coesos.em agrupamentos lógicos coesos.

• Geralmente devem ser escritas da forma: O sistema ... deve ... fazer <X>

• Cada função pode ser expressa em termos de um ou mais requisitos que o sistema deve atender.

Atributos do Sistema

• São qualidades não funcionais do sistema – Ex: “facilidade de uso” – que são freqüentemente confundidas com funções

• Em geral, podem ser aplicados para • Em geral, podem ser aplicados para qualquer sistema.

• São também chamados de requisitos não funcionais ou requisitos de qualidade

Atributos do Sistema

• São características ou dimensões do sistema; não são funções. Ex:– Facilidade de uso, tolerância a falhas, tempo de

resposta, custo de venda, metáfora da interface, etc.

• Podem aplicar-se a todas as funções ou ser específicos de uma função particular ou grupo de funções.

Atributos do Sistema (Cont)

• Tem associado um conjunto de detalhes do atributo, que podem ser discretos, imprecisos ou simbólicos.

• Exemplos:– tempo de resposta = psicologicamente apropriado; – tempo de resposta = psicologicamente apropriado; – metáfora da interface = (gráfica, colorida, baseada

em formulário)

Atributos do Sistema (cont)

• Podem ter também restrições de limites, que são condições de limite obrigatórias, usualmente o intervalo numérico de valores de um atributo.valores de um atributo.– Exemplo: tempo de resposta = máximo de 5

segundos

Categorias de Funções

• Forma de priorizar as funções• Identificar funções que são assumidas como

necessárias, mas que consomem tempo e recursos.recursos.

Tipos de Funções

• Evidente ou Visível (E): deve ser executada e o usuário tem conhecimento que ela foi executada.

• Oculta (O): deve ser executada, mas não é visível para o usuário. Isso vale para muitos serviços técnicos de infra-estrutura, tal como salvar a técnicos de infra-estrutura, tal como salvar a informação em um dispositivo permanente de armazenamento. São frequentemente esquecidas durante a fase de coleta de requisitos

• Enfeite/Decoração/ (D): Opcional; sua adição não afeta significativamente outras funções.

Descrição Geral

Exemplo de Requisitos: TPV

Descrição GeralO propósito deste projeto é criar um terminal de ponto de vendas (TPV) para ser usado em lojas de varejo.

Clientes

ObjectStore, Inc., uma multinacional que comercializa objetos que comercializa objetos

Objetivos

O objetivo geral é aumentar aautomatização das compras (checkout)para permitir serviços e processoscomerciais mais rápidos, melhores e maisbaratos. Tipicamente, isso inclui:baratos. Tipicamente, isso inclui:• Checkout (passagem pelo caixa) mais rápido

para o cliente• Verificação e identificação rápida do cliente• Análise rápida e precisa do crédito• Controle automático do estoque

Funções Básicas

• R1.1 – Registrar a venda em andamento (corrente), isto é, os itens comprados. (Evidente)

• R1.2 – Calcular o total da venda corrente, incluindo os cálculos de impostos e de cupons de desconto. (Evidente)de desconto. (Evidente)

• R1.3 – Capturar a informação de um item adquirido, usando o código, obtido por um leitor de código de barra, ou pela entrada manual do código do produto, usando o código universal de produto (CUP ou UPC). (Evidente)

Funções Básicas (cont.)

• R1.4 – Reduzir a quantidade em estoque quando a venda for finalizada (Oculta)

• R1.5 – Registrar as venda completadas (Oculta)• R1.6 – O Caixa deve abrir o caixa (log in) com • R1.6 – O Caixa deve abrir o caixa (log in) com

um identificador (ID) e uma senha para poder usar o sistema (Evidente)

• R1.7 – Fornecer um mecanismo de armazenamento permanente (Oculta)

Funções Básicas (cont)

• R1.8 – Fornecer mecanismos de comunicação inter-processos e inter-sistemas (Oculta)

• R1.9 – Exibir a descrição e o preço do • R1.9 – Exibir a descrição e o preço do item registrado (Evidente)

Funções de Pagamento

• R2.1 – Tratar os pagamentos em dinheiro; capturar a quantia recebida e informar o troco (Evidente).

• R2.2 – Tratar o pagamento por cartão de • R2.2 – Tratar o pagamento por cartão de crédito: captar a informação do cartão de crédito por um leitor de cartões ou uma entrada manual e autorizar o pagamento com o serviço de autorização de crédito (externo) da loja via conexão por modem (Evidente)

Funções de Pagamento (cont.)

• R2.3 – Tratar os pagamentos com cheque; capturar o CPF por entrada manual e autorizar o pagamento com o serviço de autorização de crédito da loja (externo) via conexão por modem (Evidente)(Evidente)

• R2.4 – Registrar os pagamentos por crédito no sistema de contas a receber da loja, uma vez que o serviço de autorização de crédito deve à loja a quantia oferecida como pagamento (Oculta)

Atributos (requisitos não funcionais) do Sistema em especificações de funções

• R1.9 Exibir a descrição e o preço do item registrado (Evidente) – Tempo de resposta: Max 5s � Obrigatório– Metáfora da interface:

• saída baseada em formulário � Obrigatório• saída colorida � Desejável

• R2.4 Registrar os pagamentos por crédito no sistema de contas a receber da loja (Oculta)– Tolerância a falhas: deve registrar no sistema de

contas a receber em 24h, mesmo em caso de falhas elétrica ou de hardware � Obrigatório

– Tempo de Resposta: Max 10s � Obrigatório

Outros artefatos da fase de requisitos

• Requisitos e Equipes de ligação – lista das pessoas que deveriam estar envolvidas no levantamento dos requisitos

• Grupos afetados – lista de pessoas afetadas • Grupos afetados – lista de pessoas afetadas pelo sistema (desenvolvimento ou utilização)

• Hipóteses – coisas que serão assumidas como verdadeiras.

• Riscos – problemas que podem levar ao fracasso do sistema

Outros artefatos da fase de requisitos

• Dependências – outras pessoas, sistemas e produtos, dos quais este projeto depende

• Glossário – definição de todos os termos relevantesrelevantes

• Casos de Uso – descrições narrativas dos processos do domínio.

• Esboço do modelo conceitual – um modelo de conceitos relevantes e seus relacionamentos