es i aula04n [modo de...

FCT-UNESP 16/05/2017

Prof. Dr. Rogério E. Garcia 1

Bacharelado emCiência da

Computação16/05/2017

Engenharia de Software I

Rogério Eduardo Garcia([email protected])

Aula 04

In a calm sea every man is a pilot.

BCC16/05/2017

16/05/2017 Ciência da Computação - Engenharia de Software I - Rogério Eduardo Garcia 2

Engenharia de Software I –Aula 4

Revisão

Introdução ao Método Larman Planejar e Elaborar

Construir Analisar

Revisão de conceitos de Orientação a Objetos



BCC16/05/2017


Padrão IEEE para oDocumento de Requisitos

1 Introdução

1.1 Propósito do documento de requisitos Motivações, público-alvo, ...

1.2 Escopo do produto Explicitar o que o produto faz (e o que não faz). Descrever a aplicação.

1.3 Definições, acrônimos e abreviações 1.4 Referências

Listar todos os documentos referenciados. Especificar a origem dos documentos.

1.5 Visão geral do restante do documento Estrutura/organização.

BCC16/05/2017



2 Descrição Geral

2.1 Perspectiva do Produto Relacionamento: sistema, usuário, hardware, software,

comunicação. 2.2 Funcionalidades do Produto 2.3 Características do Usuário 2.4 Restrições Gerais

Limitações de hardware, considerações sobre segurança,...

2.5 Suposições e Dependências Máquina específica, sistema operacional, ...



BCC16/05/2017



3 Requisitos Específicos

Abrangem os requisitos funcionais, não funcionais e de interface.

Os requisitos podem documentar interfaces externas, descreverfuncionalidade e desempenho do sistema, especificar requisitoslógicos de banco de dados, restrições de projeto, propriedadesemergentes do sistema e características de qualidade.

4 Apêndices

5 Índice

BCC16/05/2017


Análise de Requisitos

ANÁLISE DEREQUISITOS

Engenharia de Sistemas de Computador

Projeto de Software

Como Proceder?



BCC16/05/2017


Princípios da Análise

O domínio de informação de um problema deve serrepresentado e compreendido

Modelos que descrevam a informação, função ecomportamento do sistema devem serdesenvolvidos

Os modelos devem ser divididos em partições, demaneira que revele os detalhes em forma decamadas, preferencialmente

O processo de análise deve ter como foco ainformação essencial do (UdeI) – detalhes deimplementação ficam para a fase de Projeto

BCC16/05/2017


Princípios da Especificação

Separar funcionalidade de implementação

Uso de uma linguagem de especificação orientadaao processo

A especificação deve abranger o sistema do qual osoftware é um componente

A especificação deve abranger o sistema no qual osoftware opera



BCC16/05/2017


Princípios da Especificação (Cont.)

Uma especificação deve ser um modelo cognitivo

Uma especificação deve ser operacional

Uma especificação deve ser tolerante com a não-inteireza e ser expansível

Uma especificação deve ser localizada efracamente acoplada

BCC16/05/2017


Estabelecimento das necessidades do sistema

Estudo de viabilidade

Modelagem do sistema

Definição dos requisitos

Especif. dos requisitos

Especific.do sistema

Documento de requisitos

Relatório de viabilidade

Relatório de necessidades

Especificaçãodo projeto

Formulação dos requisitos



BCC16/05/2017


Para que tudo isso?

Obter uma descrição dos requisitos

Propor uma solução (“software”) que atendaao requisitos da melhor maneira possível

Possibilidade de avaliar não apenas aproposta, mas também as conseqüências dedecisões tomadas em tempo de projeto

BCC16/05/2017


Problema Solução

Abstrato

Concreto

Problema X Solução



BCC16/05/2017


Portanto...

É preciso planejar considerando a maneiracom que um projeto será implementado...

Orientado a Objetos

BCC16/05/2017


Mundo x Paradigma OO

Mundo Real é formado por objetos que seinteragem

Representar esses objetos em um software é maisnatural e permanente do que representar a suafuncionalidade (decomposição funcional), pois essaé mutável

A representação usando objetos facilita omapeamento do mundo real, ou seja, a criação deum modelo que o represente



BCC16/05/2017


Problema...

ESPAÇO DEPROBLEMAS

ESPAÇO DESOLUÇÕES

Gap Semântico

Mundo Real Mundo Computacional

Todo software representa um Modelo de um problema do mundo real, no Espaço de Soluções

BCC16/05/2017


Gap Semântico

Quanto menor o Gap (diferença entre espaços)mais fácil será : o desenvolvimento da aplicação

assegurar a compreensão, confiabilidade e manutençãoda aplicação

Diminuir o Gap implica em tornar o mapeamento domundo real (modelo) mais próximo da realidade

Sendo mais “natural”, o Paradigma de Orientação aObjetos tem por objetivo diminuir o gap semântico



BCC16/05/2017


Criação de Modelos

MapeamentoProcesso de Identificação de

“coisas” do mundo real para

compor o modelo

ABSTRAÇÃO Modelo Conceitual

BCC16/05/2017


Problema Solução

Abstrato

Concreto




BCC16/05/2017


BCC16/05/2017


Método Larman: Visão Geral

Tópicos eHabilidades

Padrões

DesenvolvimentoIterativo

A/POO

Notação UML

Princípios eDiretrizes

Engenharia deRequisitos



BCC16/05/2017


BCC16/05/2017


UML

História da UML início em 1994 – esforço conjunto de Booch e

Rumbaugh para combinar as notaçõesdiagramáticas de seus métodos Booch e OMT(Object Modeling Technique)

a eles juntaram-se outros colaboradores

adotada como padrão em 1997 pela OMG

continua a ser refinada… versão 2.0 em andamento (???)



BCC16/05/2017


UML

Segundo OMG: “A UML (Unified ModelingLanguage - Linguagem de Modelagem Unificada) éuma linguagem para especificar, visualizar, construire documentar os artefatos de sistemas de software,bem como para modelar negócios e outros sistemasque não sejam de software”

Notação UML - principalmente diagramática, paramodelagem de sistemas usando conceitosbaseados na metáfora de “objetos”

BCC16/05/2017


UML

A UML é a linguagem padrão para visualizar,especificar, construir e documentar osartefatos de um sistema intensamentebaseado em software

Pode ser usada com todos os processos,durante todo o ciclo de desenvolvimento, ecom diferentes tecnologias deimplementação;



BCC16/05/2017


Diagramas

Use Case Diagramas de Estrutura Estática

Diagrama de Objetos Diagramas de Classe

Diagramas de Interação Diagrama de Seqüência Diagrama de Colaboração

Statecharts Diagramas de Atividade Diagrama de Implementação

Diagrama de Componentes Diagrama de Desdobramentos (Deployment)

BCC16/05/2017


Problema Solução

Abstrato

Concreto


Diagrama deClasses

Diagrama deClasses



BCC16/05/2017



Processo Planejar e Elaborar Casos de Uso: Formatos, Tipos e Diagrama

Modelo Conceitual: Conceitos e Associações

Processo Construir (Fase Analisar) Modelo Conceitual: Agregações, Generalizações e

Tipos Associativos

Diagramas de Seqüência

Contratos de Operação

BCC16/05/2017



Auxiliar o desenvolvedor a: Aplicar princípios, diretrizes e padrões na

construção de software

Seguir um conjunto de atividades comuns deanálise e projeto, a partir de um ciclo dedesenvolvimento iterativo

Criar diagramas freqüentemente utilizados nanotação UML



BCC16/05/2017


Desenvolvimento Iterativo

Um ciclo de vida iterativo (CVI) envolve a repetiçãodos ciclos de planejamento, elaboração, construçãoe instalação

O sistema cresce pela adição de novas funções (erefinamento das existentes) em cada ciclo iterativo

Cada ciclo ataca um pequeno conjunto de requisitos

planejar

elaborarconstruir

instalar

BCC16/05/2017


Método Larman

Planejar eElaborar

Construir Instalar

Ciclo de Desenvolvimento 1


…

RefinarPlano

SincronizarArtefatos

Analisar Projetar Construir Testar



BCC16/05/2017


Método Larman

Planejar eElaborar

Construir Instalar



…

RefinarPlano



BCC16/05/2017


Método Larman: Planejar e Elaborar

Planejar e Elaborar Construir Implantar

1. DefinirPlano Inicial

2. Criar Relatório deInvestigação Preliminar

3. Definir Requisitos

4. RegistrarTermos no Glossário a

5. ImplementarProtótipo bd

6. Definir Casos de Uso(Alto Nível e Essenciais)

7. Definir ModeloConceitual Inicial c

8. Definir ArquiteturaInicial do Sistema acd

9. Aperfeiçoar (Refinar)Plano

a on

goin

gb

opci

onal

c ad

iáve

ld

orde

m v

aria

da



BCC16/05/2017


Método Larman





4. RegistrarTermos no Glossário

5. ImplementarProtótipo


7. Definir ModeloConceitual Inicial

8. Definir ArquiteturaInicial do Sistema


Engenharia de Requisitos

BCC16/05/2017


Entendimento dos Requisitos

Objetivos: Criar os artefatos da fase de engenharia de

requisitos Documento de Especificação de Requisitos

Identificar e categorizar as funções do sistema

Identificar e categorizar os atributos do sistemae relacioná-los com as funções

JÁ VISTO!!!



BCC16/05/2017


Funções do Sistema

O QUE o sistema deve fazer? ex: autorizar pagamento por cartão de crédito

funções do sistema devem ser identificadas elistadas em agrupamentos lógicos

Geralmente escritas da forma: “O sistemadeve fazer <X>”

Cada função pode ser expressa em termosde um ou mais requisitos que o sistemadeve atender

BCC16/05/2017


Tipos de Funções

Evidente ou Visível (E): deve ser executada e ousuário tem conhecimento de ela foi executada

Oculta (O): deve ser executada, mas não é visívelpara o usuário vale para muitos serviços técnicos de infra-estrutura, tais

como salvar a informação em um dispositivo permanentede armazenamento

são freqüentemente, e incorretamente, esquecidas durantea fase de especificação de requisitos



BCC16/05/2017


Tipos de Funções

Enfeite/Decoração/Luxo (D): opcional sua adição não afeta significativamente o custo

ou outras funções. ???

BCC16/05/2017


Estudo de caso - TPV

Descrição Geral: O propósito deste projeto é criar um terminal de

ponto de vendas (TPV) para ser usado em lojasde varejo

Clientes ObjectStore, Inc., uma multinacional que

comercializa objetos



BCC16/05/2017


Estudo de caso - TPV

Objetivos: O objetivo geral é aumentar a automatização

das compras (checkout) para permitir serviços eprocessos comerciais mais rápidos, melhores emais baratos. Tipicamente, isso inclui: checkout (passagem pelo caixa) mais rápido para o

cliente

análise rápida e precisa do crédito

controle automático do estoque

BCC16/05/2017


TPV - Funções Básicas

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

R1.2 – Calcular o total da venda corrente, incluindoos cálculos de impostos e de cupons de desconto(E)

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



BCC16/05/2017


Funções Básicas - TPV

R1.4 – Reduzir a quantidade em estoquequando a venda for finalizada (O)

R1.5 – Registrar as vendas completadas (O)

R1.6 – O funcionário (Caixa) deve abrir ocaixa (log in) com um Identificador (ID) e umasenha para poder usar o sistema (E)

R1.7 – Fornecer um mecanismo dearmazenamento permanente (O)

BCC16/05/2017


Funções Básicas - TPV

R1.8 – Fornecer mecanismos decomunicação inter-processos e inter-sistemas (O)

R1.9 – Exibir a descrição e o preço do itemregistrado (E)



BCC16/05/2017


Funções de Pagamento - TPV

R2.1 – Tratar os pagamentos em dinheiro:capturar a quantia recebida e informar otroco (E)

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

BCC16/05/2017


Funções de Pagamento - TPV

R2.3 – Registrar os pagamentos por créditono sistema de contas a receber da loja, umavez que o serviço de autorização de créditodeve à loja a quantia oferecida comopagamento (O)

R2.4 – Tratar os pagamentos com cheque:capturar o CPF por entrada manual eautorizar o pagamento com o serviço deautorização de crédito da loja (externo) viaconexão por modem (E)



BCC16/05/2017


Atributos do Sistema – TPV

para R1.9 (Exibir a descrição e o preço doitem registrado (E)) tempo de resposta: Max 5s Obrigatório

metáfora da interface: saída baseada em formulário Obrigatório

saída colorida Desejável

BCC16/05/2017


Atributos do Sistema – TPV

para R2.3 (Registrar os pagamentos porcrédito no sistema de contas a receber daloja (O)) tolerância a falhas: deve registrar no sistema de

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

tempo de resposta: Max 10s Obrigatório



BCC16/05/2017


Método Larman











BCC16/05/2017


Casos de Uso: descrevendo processos

Objetivos: Identificar e Escrever Casos de Uso

Elaborar Diagramas de Casos de Uso

Contrastar Casos de Uso de Alto Nível eExpandidos

Contrastar Casos de Uso Reais e Essenciais



BCC16/05/2017


Casso de Uso –Documentação

Um documento de fluxo de eventos é criado paracada caso de uso Escrito do ponto de vista do ator

Detalha o que o sistema deve fornecer quando ocaso de uso é executado

Conteúdos típicos Como o caso de uso inicia e termina Fluxo normal de eventos Fluxos alternativos de eventos Fluxos excepcionais de eventos (respostas a erros)

BCC16/05/2017


Casos de Uso

Um caso de uso é um padrão decomportamento que o sistema exibe

Cada caso de uso é uma seqüência detransações relacionadas executadas por um atore o sistema em um diálogo



BCC16/05/2017


Casos de Uso

Um caso de uso é um documento textual quedescreve a seqüência de eventos realizados por umator (um agente externo) para completar umprocesso durante o uso do sistema

Contam “histórias” de utilização do sistema

Casos de uso não são especificação de requisitos,mas ilustram e implicam requisitos dependem de que se tenha um entendimento ao menos

parcial dos requisitos do sistema

BCC16/05/2017


Atores

Um ator é uma entidade externa ao sistema queparticipa de um caso de uso de alguma forma.

Atores interagem com o sistema, estimulando-ocom eventos de entrada ou de saída

Representam o papel que desempenham no casode uso. Ex: Cliente, Caixa uma pessoa, por exemplo, pode assumir vários papéis

várias pessoas podem ser instâncias de um ator



BCC16/05/2017


Atores

Atores podem ser papéis desempenhadospor pessoas, sistemas de computadores,dispositivos elétricos e mecânicos, …

Para um caso de uso, geralmente existe umator iniciador e possivelmente vários outrosatores participantes

BCC16/05/2017


Método Larman:Formatos dos Casos de Uso

de alto nível descreve o processo sucintamente, em duas ou

três sentenças

são vagos a respeito de decisões de projeto esão úteis para a compreensão dos principaisprocessos globais

expandidos mostram mais detalhes

compreensão mais profunda dos processos erequisitos



BCC16/05/2017


Caso de Uso de Alto Nível

Caso de uso: Comprar Itens

Atores: Cliente, Caixa

Tipo: primário (a ser discutido adiante…)

Descrição: Um Cliente chega ao balcão de saída da loja com itens que deseja comprar. O Caixa registra os itens de compra e recebe o pagamento. Quando termina, o Cliente sai com os itens comprados.

Usar verbo para nomear caso de

uso

Nome de atores com letra maiúscula

BCC16/05/2017

Parte 1


Caso de Uso Expandido

Parte 2

Parte 3

Descrição similar ao Caso de uso de Alto Nível

Descrição da sequência típica de eventos

Descrição de sequênciasAlternativas de eventos



BCC16/05/2017


Caso de Uso Expandido (Parte 1 - Resumo)

(restrito a pagamento em dinheiro e sem tratar controle de estoque)

Caso de Uso: Comprar Itens com Dinheiro

Atores: Cliente (iniciador), Caixa

Finalidade: Capturar a venda e seu pagamento em dinheiro

Visão geral: Um Cliente chega ao balcão de saída da loja com itens que deseja comprar. O Caixa registra os itens de compra e recebe o pagamento. Quando termina, o Cliente sai com os itens comprados.

Tipo: primário e essencial (a ser discutido adiante…)

Referências Requisitos: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1Cruzadas:

Informar ator que inicia o processo

BCC16/05/2017



Rastreabilidade

A cláusula de referência cruzada permite conferirse todos os requisitos foram atendidos por casosde uso.

Ao final, todos os casos de uso devem poder serrastreados para a implementação e o teste.



BCC16/05/2017


Lembrando...

R1.1 – Registrar a venda em andamento … (E)

R1.2 – Calcular o total da venda corrente … (E)

R1.3 – Capturar a informação de um item adquirido,usando o código… (E)

R1.7 – Fornecer um mecanismo de armazenamentopermanente (O)

R1.9 – Exibir a descrição e o preço do itemregistrado (E)

R2.1 – Tratar os pagamentos em dinheiro… (E)

BCC16/05/2017


Caso de Uso Expandido Parte 2 - Seqüência típica de eventosAção do ator Resposta do Sistema

1. Este caso de uso começa quando o Clientechega ao TPV com itens para comprar

2. O Caixa registra o identificador de cadaitem

3. Determina o preço do item e adicionainformação sobre o item à transação de vendacorrente

Se há mais de um do mesmo item, o caixatambém entra a quantidade

A descrição e o preço do item sãoapresentados

4. Quando termina a entrada dos itens, oCaixa indica ao TPV que as entradas estãocompletas

5. Calcula e apresenta o total da venda

6. O Caixa informa o total ao cliente

7. O Cliente entrega o pagamento em dinheiro– o “pagamento em dinheiro” – possivelmentemaior que o total da venda



BCC16/05/2017


Caso de Uso Expandido Parte 2 - Seqüência típica de eventos-Cont.

Ação do ator Resposta do Sistema

8. O Caixa registra a quantidade de dinheirorecebida

9. Exibe o valor do troco a ser devolvido aocliente

10. O Caixa deposita o dinheiro recebido eretira o troco devido

11. Registra a venda completada (logs)

O Caixa entrega ao cliente o troco e o reciboimpresso

12. O Cliente sai com os itens comprados

BCC16/05/2017


Caso de Uso Expandido (Parte 3 – Seqüências Alternativas)

Descreve alternativas importantes ouexceções que podem ocorrer numaseqüência típica se forem muito complexas podem se transformar

num caso de uso

Seqüências alternativas: Linha 2: Identificador de item inválido digitado.

Indicar o erro. Linha 7: O Cliente não tem dinheiro suficiente.

Cancelar a transação de venda



BCC16/05/2017


Tipos de Casos de Uso (I)

Primários : principais processos comuns

Ex: Comprar Itens

Secundários: processos menos importantes ouraros

Ex: Requisição de estoque de produto novo

Opcionais: processos que podem não ser incluídosna solução

BCC16/05/2017


Tipos de Casos de Uso (II)

Essencial: caso de uso expandido expresso numaforma ideal, que é relativamente livre de detalhestecnológicos e de implementação decisões de projeto são postergadas

Real: descreve o processo em termos de seuprojeto atual (real) considera tecnologia, entrada e saída, interface,…

definido na fase de projeto



BCC16/05/2017


Tipos de Casos de Uso (II)

Casos de uso de alto nível são essenciais pornatureza, devido à sua forma resumida e alto nívelde abstração

O intervalo entre essencial e real deve ser vistocomo um contínuo em que o caso de uso pode sesituar em qualquer ponto

Real,muito concreto

Essencial, muito abstrato

Requisitos/Análise Projeto

BCC16/05/2017


Caso de Uso Comprar Itens: Essencial


1. Este caso de uso começa quando oCliente chega ao TPV com itens paracomprar

2. O Caixa registra o identificador decada item

3. Determina o preço do item e adicionainformação sobre o item à transação devenda corrente

Se há mais de um do mesmo item, ocaixa também entra a quantidade


4. … ….



BCC16/05/2017


Caso de Uso Comprar Itens: Real

Ação do Ator Resposta do Sistema1. Este caso de uso começa quando oCliente chega ao TPV com itens paracomprar

2. Para cada item o Caixa digita o códigouniversal do produto no campo deentrada UPC da janela. Ele entãopressiona o botão “Entrar Item” com omouse ou pressiona <Enter>

3. Mostra o preço do item e adiciona ainformação do item à transação de vendacorrente. A descrição e o preço sãomostrados na caixa de texto 2 da Janela1.

…. ...

BCC16/05/2017


Importante

Em geral, os casos de uso reais não devemser produzidos na fase de engenharia derequisitos (comprometimento prematuro comuma decisão de projeto e complexidadedesnecessária)



BCC16/05/2017


Resumo

Formato do caso de usoAlto nível

Expandido

Tipo do caso de uso (I)Primário

Opcional

Secundário

Tipo do caso de uso (II) Essencial

Real

BCC16/05/2017


Diagrama de Casos de Uso: UML Diagram

Objetivo Mostrar como o sistema a ser desenvolvido irá

interagir com o ambiente, delimitando o sistema edefinindo a funcionalidade

Importantes na organização e modelagem docomportamento do sistema



BCC16/05/2017


Diagrama de Casos de Uso

Um diagrama de caso de uso mostra orelacionamento entre os atores e os casos de usodentro de um sistema.

Um caso de uso representa uma funcionalidade dosistema. Representado por uma elipse contendo o nome do caso de

uso.

Um ator é um agente externo (um usuário ou um outrosistema) que interage com o sistema. Pode ser representado como um retângulo de classe com o

estereótipo "ator” ou pela figura de um homem estilizado.

BCC16/05/2017


Diagrama de Casos de Uso: Notação

Comprar Itens

ícone para caso de usoCaixa

ícone para ator



BCC16/05/2017


Diagrama de Casos de UsoTPV

ComprarItens

Abrir (Log in)

ReembolsarItens

Caixa Cliente

BCC16/05/2017


Diagrama de Casos de UsoTPV

ComprarItens

Abrir (Log in)

ReembolsarItens

Caixa Cliente



BCC16/05/2017


Diagrama de Casos de Uso: Notação

Relacionamentos entre casos de uso e atores: communicates: relacionamento entre atores e casos de

uso.

extends: um relacionamento extends de um caso de usoA para um caso de uso B indica que uma instância de Bpode incluir o comportamento especificado por A.

include: um relacionamento include de um caso de uso Apara um caso de uso B indica que uma instânciade B inclui o comportamento especificado por A.

BCC16/05/2017


Relacionamento <<include>> Relacionamento <<extends>>

ValidarCliente

Cliente RealizarPedido

<<include>>

CadastrarCliente

Cliente RealizarPedido

<<extends>>

Diagrama de Casos de Uso:Notação



BCC16/05/2017


Diagrama de Casos de Uso: Exemplo

Leitor

BibliotecárioBibliotecário

Sistema de Biblioteca

<<extends>>

<< extends >>

Adicionar título

Manter

Reservar

Cancelarreserva

Emprestar

Devolver

Remover/atualizar

título

Adicionar item

Adicionar leitor

<< extends >>

<< extends >>

<< extends >>

BCC16/05/2017


Identificação de casos de uso

Dois métodos: baseado nos atores oubaseado nos eventos do sistema

Baseado em atores Identificar os atores relacionados a um sistema

ou organização

Para cada ator, identificar os processos que elesiniciam ou dos quais eles participam

Exemplos: Caixa - Iniciar uso, Registrar retirada de dinheiro

Cliente – Comprar itens, Reembolsar itens



BCC16/05/2017


Identificação de casos de uso

Baseado em eventos Identificar os eventos externos aos quais um

sistema deve responder

Relacionar os eventos a atores e a casos de uso

Exemplos: Itens vendidos (ator=cliente, caso de uso=comprar

item)

Dinheiro retirado (ator=caixa, caso de uso=registrarretirada de dinheiro)

BCC16/05/2017


Importante

um caso de uso não representa um passo individual ou umaoperação ou transação de entrada. por exemplo: “imprimir orecibo” não é um caso de uso no sistema de TPV

um caso de uso é normalmente a descrição de um processorelativamente grande, com início e fim próprios, quenormalmente incluem várias transações ou operações deentrada e saída. Ex: retirar dinheiro de um caixa automático matricular-se em uma disciplina verificar ortográfica em um editor de texto …



BCC16/05/2017


Escopo do Sistema

O sistema pode ser limitado por: Hardware ou software Departamentos de uma organização Toda a organização

O limite é sempre delimitado arbitrariamente peloanalista e o cliente, mas geralmente leva em contacritérios tais como: política organizacional, limites demenor comunicação entre os subsistemas,oportunidade e tamanho do sistema

BCC16/05/2017


Exemplo

Ex: considerar toda a loja como sendo o sistema. O caixa está dentro do sistema e é um de seus recursos.

LOJA

ComprarItens

ReembolsarItens

Cliente

TPV

ComprarItens

Abrir (Log in)

ReembolsarItens

Caixa Cliente

Limite do sistema



BCC16/05/2017


Decisão e Desvio

Pontos de decisão e desvio podem ocorrer em um caso deuso Ex: no caso de uso Comprar Itens, o cliente pode pagar em

dinheiro, cartão de crédito ou cheque Dividir o caso de uso em seções Para cada caso de uso:

Parte 1 – Resumo Seção Principal

parte 2 – seqüência típica de eventos parte 3 – seqüências alternativas

Seção Pagamento com dinheiro parte 2 – seqüência típica de eventos parte 3 – seqüências alternativas

Seção Pagamento com cartão de crédito …

BCC16/05/2017


Caso de Uso Comprar ItensSeção Principal

Seqüência típica de eventosAção do ator Resposta do Sistema

1. Este caso de uso começa quando o Cliente chegaao TPV com itens para comprar

2. O Caixa registra o identificador de cada item … 3. Determina o preço do item…

4. Quando termina a entrada dos itens… 5. Calcula…


7. O Cliente escolhe o tipo de pagamento:

i. Se for pagamento em dinheiro, ver seçãoPagamento em Dinheiro

ii. Se for pagamento com cartão de crédito verseção Pagamento por Cartão de Crédito

iii. Se for pagamento por cheque, ver seçãoPagamento em Cheque

8. Registra a venda completada

9. O Caixa entrega o recibo para o Cliente

10. O Cliente sai da loja com os itens…



BCC16/05/2017


Caso de Uso Comprar ItensSeção Pagamento com Dinheiro

Seqüência típica de eventos


1. O Cliente entrega o pagamento emdinheiro, possivelmente maior que o totalda venda

2. O Caixa registra a quantidade dedinheiro recebida

3. Exibe o valor do troco a ser devolvidoao cliente

4. O Caixa deposita o dinheiro recebido eretira o troco devido

O Caixa entrega o troco ao Cliente

Seqüência alternativa:

• Linha 4: Dinheiro insuficiente na gaveta para pagar o troco. Solicita dinheiro ao supervisor

BCC16/05/2017


Planejar e Elaborar:Passos do Processo

1. Listar todas as funções (requisitos), definir os limites do sistema eidentificar atores e casos de uso.

2. Escrever todos os casos de uso no formato de alto nível, classificando-os como principais, secundários e opcionais.

3. Desenhar o diagrama de casos de uso.

4. Escrever o formato expandido dos casos de uso mais importantes,mais complexos ou mais arriscados. Os demais poderão serexpandidos quando forem tratados em fases posteriores do processode desenvolvimento.

5. Idealmente, postergar os casos de uso reais até a fase de projeto.Exceções podem ocorrer se:a) descrições concretas auxiliam grandemente a compreensão, oub) os clientes demandam que o processo seja especificado dessa

forma.



BCC16/05/2017


Exemplo – Sistema TPV

Os limites do sistema serão definidos como o sistema de hardware e software.

Atores e casos de uso:

Caixa: Abrir (Log In), Retirar dinheiro da caixa, Fechar

Cliente: Comprar Itens, Reembolsar Itens

Gerente: Iniciar e Encerrar (o sistema)

Administrador do Sistema: Adicionar novo usuário

(Passo 1. Identificar atores, casos de uso e limites do sistema.)

BCC16/05/2017



Caso de uso: Comprar Itens


Tipo: primário

Descrição: Um cliente chega ao balcão de saída da loja com itens para comprar. O caixa registra os itens de compra e recebe o pagamento. Quando termina, o cliente sai com os itens comprados.

(Passo 2. Escrever casos de uso no formato de alto nível.)



BCC16/05/2017


Caso de uso: Iniciar

Atores: Gerente

Tipo: primário

Descrição: Um Gerente liga o sistema TPV de modo a prepará-lo para o uso pelos Caixas. O Gerente confere que as datas e hora estão corretas, após o que o sistema está pronto para uso dos Caixas.

Exemplo – Sistema TPV(Passo 2. Escrever casos de uso no formato de alto nível.)

BCC16/05/2017


TPV

Comprar

Itens

Abrir

ReembolsarItens

Caixa Cliente

Administrador Do Sistema

Gerente

Adicionar novos usuários

Iniciar

etc.

(Passo 3. Desenhar um diagrama de casos de uso.)

Exemplo:Sistema TPV



BCC16/05/2017


Caso de Uso: Comprar Itens

Atores: Cliente (iniciador), Caixa’

Propósito: Captura a venda e seu pagamento em dinheiro

Visão geral: Um cliente chega a um ponto de pagamento, com vários itens que deseja comprar. O caixa registra os itens de compra e recebe o pagamento, o qual pode necessitar autorização. No final, o cliente sai com os itens comprados.

Tipo: primário e essencial

ReferênciasCruzadas: Funções: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1, R2.2, R2.3, R2.4

Casos de Uso: o caixa deve ter completado o caso de uso Abrir

(Passo 4. Escrever casos de uso essenciais expandidos.)Exemplo – Sistema TPV

BCC16/05/2017


Seção : PrincipalSeqüência Típica de Eventos

Ação do ator Resposta do sistema

1. Este caso de uso começa quando um Cli-ente chega a um ponto de pagamento equi-pado com um TPV, com vários itens quedeseja comprar.

2. O Caixa registra cada item. 3. Determina o preço do item e acrescenta informação sobre o

Se houver mais de um exemplar do item, o item à transação de vendas em andamentoCaixa também pode entrar a quantidade. A descrição e o preço do item corrente são

apresentados

4. No término da entrada de itens, o Caixa 5. Calcula e apresenta o totalindica para o TPV que a entrada de itens da venda.está completa.

6. O Caixa informa ao Cliente o total.




BCC16/05/2017


(continuação…)


7. O Cliente escolhe o tipo de pagamento:a. Se pagamento em dinheiro, ver seçãoPagar com Dinheiro.b. Se pagamento com cartão, ver seçãoPagar com Cartão de Crédito.c. Se pagamento com cheque, ver seçãoPagar com Cheque.

8. Registra a venda completada.9. Atualiza os níveis de estoque.10. Gera um recibo.

11. O Caixa dá o recibo ao Cliente.12. O Cliente sai com os itens comprados.

Seqüências alternativas

Linha 2: Entrada de Identificador de item inválido. Indicas erro.Linha 7: Cliente não pode pagar. Cancelar a transação de venda.


BCC16/05/2017


Seção: Pagar com DinheiroSeqüência Típica de Eventos

Ação do ator Resposta do sistema1. O Cliente dá um pagamento em dinheiro.O valor fornecido é possivelmente maior que ototal da venda.

2. O Caixa registra a quantia fornecida 3. Apresenta o troco devido aoCliente

4. O Caixa deposita o dinheiro recebido e retirao troco devido.

O Caixa dá o troco ao Cliente

Seqüências Alternativas

Linha 1: O Cliente não tem dinheiro suficiente. Pode cancelar a venda ou iniciar outro método de pagamento

Linha 4: A gaveta de dinheiro não contém o suficiente para pagar o troco. O Caixa solicita mais dinheiro ao supervisor ou pede ao Cliente uma quantia de dinheiro diferente ou a opção por um outro método de pagamento

Exemplo – Sistema TPV(Passo 4. Escrever casos de uso essenciais expandidos.)



BCC16/05/2017


Seção: Pagar com Cartão de CréditoSeqüência Típica de Eventos

Ação do ator Resposta do sistema1. O Cliente comunica suas 2. Gera uma solicitação de pagamento com informações de Crédito para o cartão de crédito e a envia a um Serviçopagamento com cartão de crédito de Autorização de Crédito (SAC) externo

3. O SAC autoriza o pagamento 4. Recebe uma resposta de aprovaçãode crédito do SAC.

5. Lança o pagamento com cartão de créditoe a informação da resposta de aprovação nosistema de Contas a Receber (C/R). (O SACdeve dinheiro à Loja, logo C/R deve fazer oacompanhamento)

6. Exibe a mensagem de autorização bem sucedida


Linha 3: Solicitação de crédito negada pelo SAC. Sugerir um método de pagamento diferente


BCC16/05/2017


Seção: Pagar com ChequeSeqüência Típica de Eventos


1. O Cliente preenche um chequee se identifica.

2. O Caixa registra a informação de 3. Gera uma solicitação de pagamentoidentificação e solicita autorização com cheque e a envia a um Serviço depara pagamento com cheque Autorização de Cheques externo

4. O Serviço de autorização de 5. Recebe uma resposta de aprovaçãoCheques autoriza o pagamento do Serviço de Autorização de Cheques.

6. Indica autorização bem-sucedida.


Linha 4: Solicitação de cheque negada pelo Serviço de Autorização de Cheques. Sugerir um método de pagamento diferente

Exemplo – Sistema TPV(Passo 4. Escrever casos de uso essenciais expandidos.)



BCC16/05/2017


Planejar e Elaborar: Artefatos

Relatório de Investigação Preliminar

Protótipos

Orçamento,Cronograma

Especificação de Requisitos

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

expandidos

Diagramas de Casos de Uso

Esboço do modelo conceitual

GlossárioDepende de

BCC16/05/2017












Método Larman



BCC16/05/2017












Método Larman

BCC16/05/2017


Modelos Conceituais

Modelo Conceitual é uma representação dosconceitos, ou objetos, do mundo real pertencentes aum domínio de interesse

É exibido por um conjunto de diagramas deestrutura estática, no qual não se definemoperações

Pode ser tratado como um “dicionário visual” dasabstrações significativas do domínio ajuda a compreender vocabulário e informação do domínio

Pode mostrar: conceitos, associações entreconceitos e atributos de conceitos



BCC16/05/2017


Modelagem Conceitual

Realiza-se a análise do domínio da aplicaçãoe a modelagem das entidades e fenômenosdesse domínio considerados importantes,independentemente da implementação.

A tarefa de modelagem conceitual envolvedois mecanismos: Abstração e

Representação.

BCC16/05/2017


Modelagem Conceitual

EntidadeObservada

Entidade Representada

Avião

ABSTRAÇÃO REPRESENTAÇÃO

Operação mentalpara observar umdomínio e capturarsua estrutura

Expressão segundoas convenções:notação gráfica,linguagem deprogramação, etc.



BCC16/05/2017


Classificação/Instanciação

Estudantede

Graduação

José Maria

CL

AS

SIF

ICA

ÇÃ

O

INS

TA

NC

IAÇ

ÃOCATEGORIA

INDIVÍDUO(Objeto)

BCC16/05/2017


Modelo Conceitual: Conceito Informal: idéia, “coisa”, ou objeto do mundo real no domínio

de interesse. Algo digno de nota, de ser documentado, de importância para o

domínio.

Formal: Um conceito pode ser considerado em termos deseu: Símbolo: palavra ou imagem representando um conceito.

Ex.: Venda Intenção: a definição de um conceito.

Ex.: Uma venda representa uma transação de compra e possuidata e hora.

Extensão: o conjunto de exemplos (instâncias) ao qual oconceito se aplica. Ex.: Venda1, Venda2, Venda3 …



BCC16/05/2017


Modelo Conceitual: Conceito

Símbolo Ex.: Aeronave

Intenção Ex.: (o conceito) Aeronave representa uma aeronave, ou

seja, um meio de transporte aéreo que possui categoria,dimensões, número de lugares, …

Extensão Ex.: AirBus PT999, Boing747 PX111, …

BCC16/05/2017


Conceitos no Sistema TPV

Como identificar conceitos em um sistema ?

TPV Venda Loja



BCC16/05/2017


Estratégias paraIdentificar Conceitos

É melhor especificar em excesso um modelo conceitual commuitos conceitos do que subespecificá-lo. Menos conceitos não implicam em um modelo melhor.

Não exclua um conceito só porque sua necessidade não estáóbvia nos requisitos.

Não exclua um conceito só porque não tem atributos – ele podepossuir um papel de comportamento e não de informação.

Usar uma Lista de Categorias de Conceitos.

Identificar Substantivos.

BCC16/05/2017


Conceito - Definição

Informal: idéia, “coisa”, ou objeto do mundo real no domíniode interesse algo digno de nota, de ser documentado, de importância para o

domínio

Formal - Um conceito pode ser considerado em termos deseu: Símbolo: palavra ou imagem representando um conceito. Ex:

Venda

Intenção: a definição de um conceito. Ex: Uma vendarepresenta uma transação de compra e possui data e hora

Extensão: o conjunto de exemplos (instâncias) ao qual oconceito se aplica: Ex: Venda1, Venda2, Venda3 …



BCC16/05/2017


Exemplo

Símbolo - Ex: Aeronave

Intenção - Ex: (o conceito) Aeronave representa umaaeronave, ou seja, um meio de transporte aéreo que possuicategoria, dimensões, número de lugares, …

Extensão - Ex: AirBus PT999, Boing747 PX111,…

BCC16/05/2017


Conceitos no Sistema TPV

Como identificar conceitos em um sistema ?

TPV Venda Loja



BCC16/05/2017


Exemplos de Categorias de Conceitos

Objetos físicos ou tangíveis: TPV, Carro, Aeronave

Especificações ou Descrições de “Coisas”:EspecificaçãoProduto, ListaVerificação

Lugares: Loja, Aeroporto

Transações: Venda, Pagamento, Reserva

Regras e Políticas: PolíticaReembolso

Itens de linha de transação: ItemLinhaVendas

BCC16/05/2017


Exemplos de Categorias de Conceitos (cont.)

Papéis desempenhados por pessoas: Caixa

Contêineres: Depósito, Armário, Aeronave

Coisas em um contêiner: Item, Passageiro

Catálogos: CatálogoProdutos, CatálogoPeças

Organizações: DepartamentoVendas

Sistema externo: SistmAutorizaçãoCartCrédito

…



BCC16/05/2017


Identificação de Substantivos -caso de uso Comprar Itens

1. Este caso de uso começa quando um Cliente chega a umponto de pagamento equipado com um TPV com váriositens que deseja comprar.

2. O caixa registra o código universal do produto (UPC) decada item.Se houver mais de um exemplar do item o caixatambém pode entrar a quantidade.

3. Determina o preço do item e acrescenta informação sobre oitem à transação de vendas em andamento.

A descrição e o preço do item corrente são apresentados

BCC16/05/2017


Identificação de Substantivos

Lembre-se:

1. Nem todos os substantivos são conceitos – linguagem natural pode ser ambígua

Ex: substantivos diferentes podem representar o mesmo conceito –(Consumidor e Cliente)

2. Alguns dos substantivos são candidatos a conceitos e outros são candidatos a atributos



BCC16/05/2017


Conceitos candidatosDomínio TPV – caso de uso Comprar Itens

• TPV

• Item• Loja• Venda• CatálogoProdutos

• EspecificaçãoProduto

• ItemLinhaVenda

• Caixa• Cliente• Pagamento• Gerente

Ideal: Combinar as estratégias para identificar uma lista de candidatos a conceito

BCC16/05/2017


Incluir no modelo objetos do tipo relatório?

Um recibo é um relatório (uma saída do sistema) de umavenda a informação contida num recibo é derivada de outras fontes, e

portanto essa informação é duplicada razão para excluí-lo

Um recibo desempenha um papel importante em termos dasregras do negócio confere ao portador o direito de retornar o item comprado

razão para incluí-lo

Então… o Recibo deve ser incluído somente na fase onde oretorno de itens for tratado – considerando o ciclo dedesenvolvimento iterativo



BCC16/05/2017


O Conceito de Especificação (ou de Descrição)

O que aconteceria se todas as TVs de 19” (Item)fossem vendidas ?

Como fazer para saber o preço desse item devenda ?

Item

descriçãopreçonúmero sérieCUP

ou

?????

EspecificaçãoProduto Item

número sériedescriçãopreçoCUP

Descreve

1 *

MELHOR

BCC16/05/2017


Quando utilizar conceitos de especificações

Quando houver necessidade da existência de umadescrição de um item ou serviço, independente daexistência de uma instância do item ou serviço se a exclusão de instâncias do item/serviço resultar em

perda de informação que deveria ser mantida

Quando reduzir informação redundante ouduplicada



BCC16/05/2017


Dicas...

Objetos podem ser: Entidades Externas que produzem ou consomem informações

(outros sistemas, pessoas)

Coisas que fazem parte do domínio (relatórios, displays, cartas)

Eventos que ocorrem no contexto do sistema (transferência depropriedade)

Papéis desempenhados por pessoas (gerente, engenheiro,vendedor)

Unidades organizacionais (grupo, equipe)

Lugares que estabelecem o contexto do problema (piso defábrica, área de descarga)

BCC16/05/2017


Dicas...

Isolar nomes (e locuções nominais), verbos (e locuçõesverbais)

Os nomes e os verbos que são sinônimos ou que não temnenhuma relação com o processo de modelagem sãoomitidos

Os nomes são classes ou atributos (itens de dados)

Os verbos são operações (métodos) - relacionamento entreclasses



BCC16/05/2017


Exemplo para TPV

Vendadatahora

Pagamento

quantiaPago-por1 1

Parte do Modelo Conceitual do TPV indica que os conceitos Venda e Pagamento são significativos para o domínio indica que Venda e Pagamento estão relacionados de uma forma digna de nota

BCC16/05/2017


Modelo Conceitual

Modelo Conceitual NÃO mostra artefatos desoftware objetos ou classes de software

métodos ou responsabilidades

janelas

bases de dados

BDdeVendas

Vendadatahora

imprimir ()

NÃO!!!



BCC16/05/2017


Cardinalidade ou Multiplicidade

Cardinalidade define quantos objetos participam darelação

É o número de instâncias de objetos da classe queparticipam da relação

Para cada associação e agregação, são definidas duasmultiplicidades: uma para cada participante dorelacionamento.

BCC16/05/2017


Multiplicidade: Exemplo

C

C

C

C

C

*

1..*

1..40

5

3,5,8

zero ou mais - muitos (as)

um ou mais

um a quarenta

exatamente cinco

exatamente três, cinco ou oito

• A multiplicidadedefine quantas instâncias de um conceito A podem ser associadas a cada instância do conceito B



BCC16/05/2017


Navegação

Embora associações e agregações sejam bi-direcionais por default, por ser desejável restringir anavegação em uma direção

Para isso, uma ponta (flecha) é adicionada à linha,indicando a direção da navegação

BCC16/05/2017


Exemplo do Sistema TPV

TPV VendaCaptura

1 1

associação

nome da associação direção de leitura (default: opcional)

OBS: o símbolo SOMENTE indica direção de leitura – não tem significado no modelo



BCC16/05/2017


Exemplo

TPV VendaCaptura

1 1

nome da associação

multiplicidade

direção de leitura (default: opcional)

associação

Loja Item1 *Estoca

BCC16/05/2017


Associação - definição

Associação é um relacionamento entreconceitos indica uma conexão com significado e interesse

Em UML são descritas como“relacionamentos semânticos entre objetosdiferentes”



BCC16/05/2017


Critérios para incluir associações

Quando o conhecimento associado necessita ser preservado poralgum tempo “necessário-ser-conhecida” – requisitos indicam essa necessidade Ex: associação entre Venda e Pagamento

Evite associações cuja necessidade não é sugerida nos requisitos Ex: associação entre Venda e Gerente

É mais importante identificar conceitos do que associações Excesso de associações pode tornar o modelo conceitual confuso Evite mostrar associações redundantes ou deriváveis

BCC16/05/2017


Associações Comuns A é uma parte física de B

Gaveta – TPV Asa - Aeronave

A é uma parte lógica de B ItemLinhaVenda – Venda PernaVôo (Flight Leg) - RotaVôo

A está fisicamente contida em/sobre B Item – Prateleira Passageiro - Aeronave

A está logicamente contida em B DescriçãoItem - Catálogo Vôo – ProgramaçãoVôo

A é registrada em B Venda - TPV Reserva - ManifestoVôo



BCC16/05/2017


Associações Comuns

A é uma descrição para B DescriçãoItem – Item

DescriçãoVôo – Vôo

A é um item de linha de uma transação ou relatório B ItemLinhaVenda – Venda

ServiçoManutenção - LogManutenção

A é uma transação relacionada a outra transação B Pagamento – Venda

Reserva – Cancelamento

…

BCC16/05/2017


Associações com Papéis

Cada extremo de uma associação é chamado depapel.

Os papéis podem ter, opcionalmente, as seguintespropriedades: Nome

Expressão de multiplicidade

Navegabilidade



BCC16/05/2017


Associações com Papéis

Nomes de papéis são necessários,principalmente, para associação entre doisobjetos de mesma classe.

Companhia Empregado

1

0 .. *

subordinado1 1 .. *

BCC16/05/2017


Associações Múltiplasentre Conceitos

Vôo Aeroporto

Voa-para

Voa-de

* 1

* 1

Origem

Destino



BCC16/05/2017


Associações e Implementação

Uma associação indica um relacionamento significativo apenassob a perspectiva conceitual.

Uma associação não implica em um fluxo de dados ou conexãoentre objetos em uma solução de software.

Algumas associações do modelo conceitual podem não sernecessárias na implementação.

Durante a implementação podem ser descobertas associaçõesentre objetos de software que foram esquecidas durante amodelagem conceitual.

BCC16/05/2017


Exemplo

CompanhiaAérea

Pessoa

1..*

1

Emprega

1Vôo

*Designada-para

Aeronave1*

Designada-para

Supervisiona

1 *

OBS: considere vôos não simultâneos na alocação de pessoas e aeronaves. Essa alocação seria feita, por exemplo, o planejamento de vôos do dia/semana/mês…



BCC16/05/2017


Exemplo

Pagamento

1..1

1..1

1..1

Gerente

0..*

1..*

1..1

*

1..1

1..1

1..1

1..1

Cliente

1..1

1..1

*

1..1TPV 1..10..*

Iniciado por

1..1

*1..1

Loja

1..*

1..1Possui

1..*1..1

Catálogo de Produtos

*

1..1Usado-por

1..1

1..*

1..1

Item

*1..1

Estoca

0..1

1..1

Especificação de Produto1..*1..1

Contém

*

Descreve

*

ItemLinhaVenda

1..1

0..1

Registra-venda-de

1..1

*

Descritos-por

Venda

1..1

1..1

Paga-por

1..1

1..1

Iniciada-por

1..1

*

Registra-dados-dav

1..1

1..1

capturada-em

1..1

1..*

Contido-em

Caixa

1..1

1..1

< Registra-Vendas-do

1..1

1..1

Iniciada-por

1..1

1..1

1..1

BCC16/05/2017


Modelo Conceitual













BCC16/05/2017



Planejar eelaborar

Construir Instalar



…

RefinarPlano



BCC16/05/2017


RefinarPlano

Sincronizarartefatos


1. Definir Casosde Uso Essenciais

2. Refinar Diagramas de Casos de Uso

3. Refinar o Modelo Conceitual

4. Refinar Glossário 5. Definir Diagramas deSeqüência do Sistema

6. Definir Contratosde Operação

7. Definir Diagramasde Estado

Método Larman



BCC16/05/2017


Modelo Conceitual: Atributo

Um atributo é um valor de dados lógico de um objeto.Descreve uma característica do objeto.

Inclua no modelo conceitual apenas os atributos para osquais os requisitos sugerem ou implicam uma necessidadede memorizar a informação. Ex: preço de item, valor da compra, …

Preferivelmente, no modelo conceitual, os tipos de atributosdevem ser simples, como: tipos de dados primitivos - booleano, inteiro, real, cadeia de

caracteres,... data, hora, cor, endereço, geometria, número de telefone, CEP,

…

BCC16/05/2017


Modelo Conceitual: Atributo

Os atributos são descritos na segunda seçãoda caixa de conceito.

O tipo do atributo é opcional.

Pessoa

nome: Stringidade: Inteiro

Venda

data: Datahora: Hora



BCC16/05/2017


1..1

1..1

Caixa

1..1Gerente

1..*

1..*

*

1..1

1..1

Pagamentoquantia

1..1

1..1Cliente

1..1

1..1TPV

1..1

Registra-Vendas-do

Iniciado por

*1..1

Lojaendereçonome

1..1

Possui

1..*1..1

CatálogoProdutos

*

1..1Usado-por

*

1..1

Vendadatahora

1..1

1..1Paga-por

1..1

1..1

Iniciada-por

1..1

*

Registra-Dados-da

1..1

1..1Capturada-em

1..*

Item

*

Estoca

0..1

1..1

EspecificaçãoProdutodescriçãopreçoUPC

1..*1..1

Contém

*Descreve

*ItemLinhaVenda

quantidade

1..1

1..*

Contido-em

1..*

0..1

Registra-venda-de

1..1

*

Descritos-por

1..1

Exemplo

BCC16/05/2017


Generalização

No sistema TPV – caso de uso ComprarItens :

Os conceitos de PagamentoComDinheiro,PagamentoComCartãoCrédito e PagamentoComChequesão muitos semelhantes.

Podem ser organizados em uma hierarquia de tipos (ouconceitos). Hierarquia “generalização/especialização”.



BCC16/05/2017


Generalização

Identifica o que há em comum entre conceitos.

Permite: Construir classificações taxonômicas – hierarquias de tipos. Compreender os conceitos em termos mais gerais e abstratos, ou mais

refinados.

Conduz a uma notação mais econômica Evita repetição de informação.

Na implementação, pode ser feita com classes e herança.

BCC16/05/2017


Generalização: Notação UML

ConceitoA

ConceitoA1 ConceitoA2 ConceitoA3

ConceitoA

ConceitoA1 ConceitoA2 ConceitoA3

supertipo –conceito geral

subtipo -conceito especializado



BCC16/05/2017


Generalização e Tipo

A definição de um supertipo é mais geral e mais abrangente que adefinição de um subtipo.

Pagamento: uma transação de transferência de dinheiro (nãonecessariamente em espécie) de um comprador para um vendedor.

PagamentoComCartãoCrédito: transferência de dinheiro, via umainstituição de crédito, que necessita ser autorizada.

Propriedade pertinência ao conjunto: todos os membros de um subtiposão membros do supertipo.

ex: PagamentosComCartãoCrédito estão dentro do conjuntoPagamento.

BCC16/05/2017


Regra É-Um

Todos os membros de um conjunto subtipo devem ser membros de seuconjunto supertipo.

O Subtipo é um Supertipo.

Generalização/Especialização



BCC16/05/2017


Pagamento

PagamentoComDinheiro

PagamentoComCartãoCrédito

PagamentoCheque

supertipo –conceito geral

subtipo -conceito especializado

Pagamento

Pagamento ComDinheiro

Pagamento ComCheque

Pagamento ComCartão Crédito

Exemplo

BCC16/05/2017


PagamentoComDinheiro PagamentoComCartãoCrédito PagamentoComCheque

Pagamento

valor: QuantiaVendaPago-a

Regra dos 100%

100% da definição do supertipo dever ser aplicada ao subtipo.

O subtipo deve estar em conformidade com 100% dos seguintes elementos do supertipo:

• Atributos

• Associação

Generalização/Especialização



BCC16/05/2017


Quando definir um subtipo ?

Criar subtipos significa particionar um tipo. Dividir um tipo em subtipos disjuntos.

Quando mostrar a partição de um tipo? Depende da relevância da partição para o domínio do problema.

Ex: No sistema TPV seria útil definir a seguinte hierarquia??

Cliente

ClienteFeminino ClienteMasculino

BCC16/05/2017


Dicas de quando particionar...

1. Um subtipo tem atributos adicionais de interesse.

2. O subtipo tem associações adicionais de interesse.

3. O conceito do subtipo é tratado, operado ou manipulado demaneira diferente que o supertipo ou outros subtipos,segundo formas que são de interesse considerar.

4. O conceito do subtipo representa uma coisa ou ser animadoque se comporta de maneira diferente do supertipo ou deoutros subtipos, segundo formas que são de interesseconsiderar.



BCC16/05/2017


Exemplo

Estudante

Disciplina

Docente

Pessoa

nomeCPF

nro. UNESP

código

MinistraCursa

*

*

0..3

1..2

titulação

Departamento

nomeEstá-vinculada-a

1*atributos em comum

subtipos com atributos e associações adicionais, e comportamento e distintos

BCC16/05/2017



PagamentoComDinheiro

Pagamento

valor : QuantiaVendaPago-a

PagamentoComCartãoCrédito

CartãodeCrédito

PagamentoComCheque

Cheque

Identifica_crédito_com

1

*Pago_com

1

1

11



BCC16/05/2017


O que fazer???

Empresa

nome

Pessoanome* *emprega

Se uma pessoa pode ter mais de um emprego em empresas diferentes, onde colocar a informação de salário????

Empresa

nome


Saláriovalor

recebepaga * ***

Uma opção:

BCC16/05/2017


Um opção MELHOR: Tipos Associativos

Classe associativa: seus atributos estão relacionados a umaassociação e não a um dos conceitos envolvidos na associação.

Seu tempo de vida depende do tempo de vida da associação.

Empresa

nome


Emprego

salário: Quantia TIPO ASSOCIATIVO



BCC16/05/2017


Tipos Associativos

Indícios da existência de tipos associativos:

Um atributo está relacionado a uma associação.

As instâncias do tipo associativo têm tempo de vidadependente do tempo de vida da associação.

Existe uma associação muitos-para-muitos entre doisconceitos, bem como informações relacionadas àassociação propriamente dita.

BCC16/05/2017


Agregação

É um tipo de associação usado para modelar relacionamentostodo-parte entre coisas.

O todo é geralmente chamado composto, as partes podem serchamadas componentes.

Notação em UML: losango vazio ou preenchido.

Mão Dedo0..51

COMPOSTOCOMPONENT

E



BCC16/05/2017


Agregação Composta(Losango Preenchido)

Agregação composta ou composição significa que: A multiplicidade na extremidade do composto pode ser no

máximo 1. Uma instância do componente pode ser parte de apenas

uma instância do composto (simultaneamente).

Existe uma dependência de existência entre ocomponente e o composto.

A existência de uma instância do composto implica naexistência de instâncias dos componentes.

A destruição de uma instância do composto implica nadestruição das instâncias dos componentes agregados.

BCC16/05/2017


Exemplos

Mão Dedo0..51

Um dedo só pode fazer parte de uma mão.

Venda 1..*1

Um item de linha de venda só pode fazer parte de uma venda.

ItemLinhaVenda

1..*1

Uma especificação de produto só pode ser parte de um catálogo.

CatálogoProduto EspecificaçãoProduto



BCC16/05/2017


Agregação Compartilhada(Losango Vazio)

Agregação compartilhada significa que: A multiplicidade na extremidade do composto pode ser

maior que 1.

Uma instância do componente pode estarsimultaneamente em muitas instâncias do composto.

Esse tipo de agregação é raro em agregadosfísicos, mas aparece em conceitos não-físicos. Exemplo:

SoftwareOO Classe

**

BCC16/05/2017


Modelo Conceitual:Diretrizes para Construção

Liste os conceitos candidatos relacionados aos requisitosconsiderados. Use a Lista de Categorias de Conceitos e a Identificação de

Substantivos.

Desenhe os conceitos em um modelo conceitual.

Registre as associações entre conceitos.

Acrescente os atributos necessários para completar osrequisitos.

Identifique possíveis agregações, generalizações e tiposassociativos.



BCC16/05/2017


RefinarPlano









Método Larman

BCC16/05/2017


RefinarPlano









Método Larman



BCC16/05/2017


Diagramas de Seqüênciado Sistema (DSS)

Para dar prosseguimento à fase de análise, édesejável ter uma noção mais concreta docomportamento esperado do sistema diante doseventos que fazem parte de cada caso de uso

Idéia: investigar e definir o comportamento do sistemacomo uma “caixa preta”.

O comportamento é dependente dos casos de uso. Interação de atores com o sistema gera eventos que

solicitam operações em resposta.

BCC16/05/2017



Os diagramas de seqüência do sistema sãoutilizados para especificar parte de seucomportamento.

Mostram um cenário global do funcionamento dosistema, dividindo o caso de uso em partes bemdefinidas, denominadas operações, que sãoexecutadas em resposta aos eventos.



BCC16/05/2017



Um DSS ilustra os eventos de entrada e saída do sistema.Para uma seqüência específica de eventos (cenário) de umcaso de uso, o DSS mostra: Os atores que interagem com o sistema. O sistema, como uma “caixa-preta”. Eventos do sistema gerados pelos atores. Eventos entre sistemas. A ordem dos eventos.

Deve ser feito para uma seqüência típica do caso de uso. Possivelmente outros DSS podem ser criados para as

seqüências alternativas mais interessantes.

BCC16/05/2017


Eventos e Operações do Sistema

Um evento de sistema é um evento externo de entrada para osistema, gerado por um ator. Eventos de sistema podem incluir parâmetros.

Cada evento inicia uma operação de resposta do sistema. Uma operação de sistema é uma operação executada em

resposta a um evento de sistema.

Um mesmo nome é atribuído a um evento e à operaçãocorrespondente (assim como mensagens e métodos).

Eventos e operações também podem ser de saída.



BCC16/05/2017


Relembrando...Caso de Uso Expandido: Comprar Itens

(restrito a pagamento em dinheiro e sem tratar controle de estoque)

Caso de Uso: Comprar Itens com Dinheiro


Finalidade: Capturar a venda e seu pagamento em dinheiro

Visão geral: Um Cliente chega ao balcão de saída da loja com itens que deseja comprar. OCaixa registra os itens de compra e recebe o pagamento. Quando termina, oCliente sai com os itens comprados.

Tipo: primário e essencial (a ser discutido adiante…)

Referências Requisitos: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1Cruzadas:

BCC16/05/2017




1. Este caso de uso começa quando o Clientechega ao TPV com itens para comprar

2. O Caixa registra o identificador de cadaitem

3. Determina o preço do item e adicionainformação sobre o item à transação de vendacorrente

Se há mais de um do mesmo item, o caixatambém entra a quantidade


4. Quando termina a entrada dos itens, oCaixa indica ao TPV que as entradas estãocompletas

5. Calcula e apresenta o total da venda


7. O Cliente entrega o pagamento em dinheiro– o “pagamento em dinheiro” – possivelmentemaior que o total da venda



BCC16/05/2017



8. O Caixa registra a quantidade dedinheiro recebida

9. Exibe o valor do troco a ser devolvidoao cliente

10. O Caixa deposita o dinheiro recebidoe retira o troco devido

11. Registra a venda completada (logs)

O Caixa entrega ao cliente o troco e orecibo impresso

12. O Cliente sai com os itens comprados


Que ator(es) realmente interage(m) com o sistema??

BCC16/05/2017


:Sistema

:Caixa

Comprar Itens

terminarVenda()

fazerPagamento(quantia)

troco, recibo

entrarItem(CUP, quantidade)

descrição item, total

iniciarNovaVenda( )

*[mais itens]

Linha do tempo

Operação

Ator

Repetição de uma

operação

“:” indica instância

“*[..]” indica iteração e a caixa refere-se à iteração

Exemplo – Sistema TPVDSS para o Caso de Uso Comprar Itens



BCC16/05/2017


:Sistema

:Caixa

Comprar Itens

terminarVenda()

fazerPagamento(quantia)

troco, recibo

entrarItem(CUP, quantidade)

descrição item, total

iniciarNovaVenda( )

*[mais itens]

Exemplo – Sistema TPVDSS para o Caso de Uso Comprar Itens

Evento de entrada: ator dispara uma operação do

sistema

Valores de retorno associados ao evento anterior

Evento de saída: resposta do sistema

à uma operação

Evento com parâmetro –representa o evento de entrada de dados de pagamento por algum mecanismo

BCC16/05/2017


Operações do Sistema

O conjunto de eventos do sistema define umconjunto de operações do sistema.

entrarItem(CUP, quantidade) Retorna descrição do item e total da compra.

terminarVenda() Sem retorno.

fazerPagamento(quantia) Retorna o troco e o recibo da compra.



BCC16/05/2017


Como dar nome aos eventosdo sistema???

Devem capturar a intenção do evento. Não devem ser nomeados em termos dos meios físicos da

entrada de dados ou dos elementos da interface.

Começar o nome com um verbo no infinitivo.

Exemplo: “entrarItem” (intenção do evento) é melhor que

“escanearItem” (revela intenções de projeto – uso descaner laser).

BCC16/05/2017


RefinarPlano









Método Larman



BCC16/05/2017


RefinarPlano









Método Larman

BCC16/05/2017



É importante que as tarefas atribuídas às operações sejambem documentadas, para evitar redundâncias einconsistências.

Um contrato especifica o comportamento esperado para cadaoperação correspondente a um evento do sistema. Linguagem precisa, analítica e rigorosa.

Deve-se fazer um contrato para cada operação relevante.



BCC16/05/2017



Características típicas de um contrato: Nome da operação.

Parâmetros de entrada.

Referências cruzadas. Casos de uso nos quais a operação pode ocorrer.

Pré-condições.

Pós-condições.

BCC16/05/2017



Pré-Condições

Representam o estado do sistema antes dainvocação da operação.

Não serão verificadas pela operação. Assume-se que elas são verdadeiras ao invocar a

operação.



BCC16/05/2017



Pós-Condições

Representam o estado do sistema após a invocação daoperação, mostrando o que mudou como conseqüência dasua execução.

Para cada operação, analisar os conceitos identificados noModelo Conceitual e definir, para cada possível objeto dosistema, o que muda quando a operação é invocada.

Observar o DSS para ter uma melhor idéia do contexto emque a operação está inserida e o contexto resultante.

BCC16/05/2017



entrarItem

Qual a responsabilidade desta operação?

Em quais casos de uso ela aparece?

O que ela considera como verdadeiro para serexecutada?

O que muda no Modelo Conceitual após suainvocação?



BCC16/05/2017



Operação: entrarItem(CUP, quantidade)

Referências Cruzadas: Casos de uso: ProcessarVenda

Pré-Condições: Existe uma venda em andamento.

Pós-Condições: Foi criada uma instância liv de LinhaDeItemDeVenda (criação de uma

instância)

Liv foi associada com a Venda corrente (associação formada)

liv.quantidade tornou-se quantidade (modificação de atributo).

liv foi associada com uma EspecificaçãoDeProduto, com base nacorrespondência de um itemID (associação formada).

BCC16/05/2017


RefinarPlano









Método Larman



BCC16/05/2017


Conclusão da Fase de Análise

A fase de análise enfatiza uma compreensão dosrequisitos do sistema. “Fazer a Coisa Certa” – compreender objetivos, conceitos

e características do domínio do problema.

Artefatos estudados...

Artefato da Análise

Casos de Uso

Modelo Conceitual

Diagramas de Seqüência do Sistema


Questões Respondidas

Quais são os processos do domínio?

Quais são os conceitos (objetos)?

Quais são os eventos e operações?

Qual é o comportamento da operação?

BCC16/05/2017



Planejar eelaborar

Construir Instalar



…

RefinarPlano



Próximo passo...

es i aula04n [modo de...

Documents