ESI AnáliseOO

Prévia do material em texto

Análise Orientada a Objetos
Prof. Wilson M Yonezawa
UNESP – FC – Bauru
Depto. Computação
yonezawa@fc.unesp.br
Engenharia Software I
Orientação a Objetos
Objetos
• Coisas do mundo real
• Em computação
• Algo alto contido
• Algo concreto ou abstrato
• Ideia bem definida
• Objeto é determinado por:
• Identidade
• Características
• Comportamento (coisas que
ele pode fazer)
Objetos
• Substantivo
• Pessoas
• Lugares
• Ideia
• Conceito • Pergunte: a coisa
• O tabuleiro
• A mesa
• A conta bancária
• O usuário
Classe
• Gabarito para criar um objeto
• Classe:
• Nome
• Propriedades (atributos)
• Operações
• Objeto é uma instância de uma classe
• Objeto é algo independente
• Em computação há classes
pré-escritas genéricas
• Strings
• Datas
• E/S
• Coleções
• Rede (networking)
Java Class Library
.Net Framework
C++ Standard Library
Bases da Orientação a Objetos
• Abstração
• Encapsulamento
• Herança
• Polimorfismo
Bases da Orientação a Objetos
• Abstração
Carro
Mesa
Aulas
Conta bancária
Ideias / Modelo mensal
(abstrações)
(qualidades essenciais)
Bases da Orientação a Objetos
• Encapsulamento
• Conteúdo e proteção do conteúdo
• Empacotamento das informações do objeto
• Mostrar somente o que é necessário
• Ex: O telefone
Conhecemos a função do 
telefone, isto é, porque e como 
utilizar, mas não preciso saber 
dos mecanismos internos que 
permitem o funcionamento do 
aparelho
Bases da Orientação a Objetos
• Herança
• Conceito de generalização/especialização
• Pai e filho
• Filho herda características do pai
• Superclasse (pai) e subclasse (filho)
Super Classe: Conta bancária
Subclasse: Conta especial
Subclasse: Conta poupança
Bases da Orientação a Objetos
• Polimorfismo
• Múltiplas formas
• Comportamento automático, mas diferente
dependendo do que está sendo operado
Adição
a + b 
6 + 6
Concatenação
a + b 
“Olá” + “mundo”
Exemplo: Sinal +
Bases da Orientação a Objetos
• Exemplo da função retirada() em duas classes:
pai e filha.
Análise orientada a objetos
1. Reunir requisitos
2. Descrever a aplicação
3. Identificar os principais objetos
4. Descrever as interações entre os objetos
5. Criar diagrama de classes
Análise orientada a objetos
Passo 1: Reunir requisitos
• O que a aplicação deve fazer?
• Que problema a aplicação ira resolver?
Análise orientada a objetos
Passo 2: Descrever a aplicação
• Construir narrativas simples
• Pequenas histórias
• Use Case
• Use Stories
• Mockup ou protótipo
Análise orientada a objetos
Passo 2: Descrever a aplicação
• Mockup ou protótipo
Análise orientada a objetos
Passo 2: Descrever a aplicação
• Mockup (ferramentas)
• https://mockingbot.com/downloads
• https://proto.io/
• https://www.fluidui.com/demos
• http://www.mockupbuilder.com/
• https://moqups.com/
• http://www.simplediagrams.com/
• https://balsamiq.com/
• https://www.hotgloo.com/
• http://framebox.org/
Análise orientada a objetos
Passo 3: Identificar os principais objetos
• Utilizar as narrativas dos usuários
• Obter e selecionar as ideias, conceitos
e coisas importantes (objetos)
• Eliminar as coisas irrelevantes
Análise orientada a objetos
Passo 4: Descrever as interações entre os objetos
• Descrever formalmente as interações entre os
objetos
• Ex: Um cliente abre uma conta bancária
• Identificar e compreender as responsabilidades
(quem faz o que?) e o comportamento (o que
devem executar / exibir?)
• Quando os objetos interagem uns com os
outros, o que devem fazer e em que ordem isso
ocorre?
Análise orientada a objetos
Passo 5: Criar diagrama de classes
• Monta uma representação visual das classes
necessárias para construir o sistema
• Utilizar os princípios (bases) da O.O.
• Abstração
• Encapsulamento
• Polimorfismo
• Herança
Análise de Requisitos
• Requisitos funcionais (características /
capacidades do sistema)
• Regras de negócio
• Requisitos não funcionais (características
adicionais)
• Questões legais
• Desempenho
• Suporte
• Segurança
Análise de Requisitos
• Exemplos de requisitos funcionais
• O sistema deve permitir que o usuário
consulte a grade de horários
• O sistema deve calcular os gastos do mês
• O sistema deve permitir o envido da fatura
por email para o cliente
Análise de Requisitos
• Exemplos de requisitos não funcionais
• O sistema deve apresentar o resultado da
consulta em menos de 10 segundos
• Suporte técnico 24/7 (24 horas, 7 dias na
semana)
Análise de Requisitos
Para “checklist” dos requisitos, utilize o 
FURPS e FURPS+
• FURPS:
• Funcional
• Usability
• Reliability
• Performance
• Suportatbility
• FURPS+:
• Design
• Implementation
• Interface
• Physical
UML – Unified Modeling Language
• Não é linguagem de programação
• Notação gráfica
• Conjuntos de diagramas
• Auxilia na análise e projeto O.O.
• Desenho de diagramas para sistemas O.O.
Use Cases (Caso de Uso)
• Foco no usuário
• Descreve como o usuário realiza ou busca
realizar algo (um objetivo) com a aplicação
• Utiliza linguagem do dia a dia
• O registro ocorre por meio de:
• Use case
• Use Stories
Use Cases
• Título: (what)
• Objetivo = frase curta
• Ator: (who)
• Pessoa que realiza algo ou busca realizar
algo
• Cenário: (how)
• Os passos para realizar ou atingir o
objetivo
Use Cases
• Título: (what)
• Objetivo = frase curta
• Registrar o cliente
• Depositar o dinheiro
• Emitir cheque
• Comprar itens
• Retirar dinheiro
Use Cases
• Ator: (who)
• Pessoa que realiza algo ou busca realizar
algo (exatamente quem faz)
• Usuário
• Cliente
• Administrador
• Sistema X
• Gerente
Use Cases
• Cenário: (how)
• Os passos para realizar ou atingir o objetivo
• Título: Comprar itens
• Ator: Cliente
• Cenário:
“O cliente revê os itens e o carrinho de
compras. Fornece informações de entrega e
pagamento. O sistema valida as informações
de pagamento e responde com uma
confirmação, bem como gera um número de
pedido que o cliente pode utilizar para
consultar a situação (status) do pedido”.
Use Cases
• Título:
• Ator:
• Cenário:
• 1) ação a (ex: Seleciona itens)
• 2) ação b (ex: Fornece informações de entrega)
• 3) ação c (ex: Confere dados de pagamento)
• Extensões:
• Precondições:
• Pós condições
• Stackholder:
• Tecnologia utilizadas:
Identificando atores
• Atores são todos cujo comportamento está do
lado de fora do sistema, mas necessitam da
aplicação por algum motivo para realizar algo.
• O sistema interage com outros sistemas ou
outras organizações
• Cuidados com:
• Papeis exercidos
• Profissões / cargos
• Atores primários e secundários
• Crie uma lista de possíveis atores:
• Objetivos sugerem atores
• Atores sugerem objetivos
Identificando cenários
• Descrever um objetivo que um ator deseja
realizar ou atingir
• Foco na meta/objetivo do usuário
• Ex: Login no sistema não é um objetivo. O
objetivo é fazer algo, como comprar itens,
pagar, reclamar, etc.
• Cuidado com objetivos “amplos” como
“escrever um livro”, “analisar pedido de
crédito”, “controlar alunos”.
• Escrever em voz ativa
• Evitar termos técnicos
Identificando cenários
Título: Comprar itens
Ator: Cliente
Cenário: Cliente checa os itens no carrinho de compras. Cliente fornece
informações de pagamento e entrega. O sistema valida as
informações de pagamento, responde com uma confirmação e
fornece um número de pedido para o cliente. O cliente utiliza o
número do pedido para acompanhar, via email, a situação
(status) do pedido.
Extensões: Um ou mais itens não constam no estoque
a) Cliente remove os itens e continua
b) Cliente cancelatodo pedido
Extensões O método (forma) de pagamento é recusado
a) Cliente tenta outra forma de pagamento
b) Cliente cancela todo pedido 
Identificando cenários
• Utilizando voz ativa
Errado: O sistema é abastecido com informações de
pagamento e entrega pelo cliente.
Correto: Cliente fornece informações de pagamento e
entrega.
Errado: O sistema se conecta com o servidor externo
de pagamento via HTTPS e utiliza JSON para enviar as
informações de pagamento e entrega que são serão
validadas. O sistema aguada por uma resposta de
callback.
Correto: O sistema valida as informações de
pagamento.
Identificando cenários
Título: Comprar itens
Ator: Cliente
Cenário: 1. Cliente escolhe entrar no processo de checkout
2. Cliente vê a página de confirmação do pedido e pode mudar
a quantidade, remover itens ou cancelar o pedido
3. Cliente informa os dados de entrega
4. Sistema valida os dados de entrega
5. Cliente seleciona o método de pagamento
6. Sistema valida os detalhes de pagamento
7. Sistema gera um número de pedido para que o cliente
possa acompanhar a situação do pedido
8. Sistema apresenta para o cliente a tela de confirmação
9. Email com detalhes de compras é enviado para o cliente
Identificando cenários
• Diagrama de use cases (casos de uso)
• Proporciona uma visão geral do sistema
• É uma ferramenta de comunicação
• Não substitui os casos de uso (use cases)
Use Stories
• Descrição escrita, simples e curta de uma
parta da aplicação
• Descreve um simples cenário a partir da
perspectiva do usuário
• Mostra o que o usuário deseja fazer e os
motivos do porque fazer
• Descrição escritas com uma ou duas
sentenças em um cartão (index card)
User Stories
USER STORY
Como um (tipo de usuário)
Eu desejo (objetivo ou meta)
Porque (motivo)
USER STORY
Como um Cliente (do banco)
Eu desejo Mudar minha senha online
Porque Não quero ir ao banco
Comparando user stories e use cases
User stories Use cases
Curto (um cartão) Longo (documento)
Um objetivo sem destaque Múltiplos objetivos e detalhes
Informal Casual até formal
Marcador da conversação
“lembrete de que precisamos
aprofundar os detalhes de algo”
Registro da conversação
Utilizado no XP, Scrum Utilizado no Agile Unified Process
Modelo Conceitual
• Identifica os objetos mais importantes
• Coisas na aplicação que necessitam de
atenção
• Associações e interações entre os objetos
• Foco na construção orientada a objetos
Modelo Conceitual
• Identificar os objetos mais importantes
• Utilizar os Use cases ou user stories
• Selecionar os substantivos nas descrições dos
cenários
Cliente checa os itens no carrinho de compras. Cliente
fornece informações de pagamento e entrega. O sistema
valida as informações de pagamento e entrega, responde
com uma confirmação e fornece um número de pedido para
o cliente. O cliente utiliza o número do pedido para
acompanhar, via email, a situação (status) do pedido
• Fazer uma lista de substantivos
• Cliente, item, pedido, carrinho de compra, informações de
pagamento, entrega, email, número do pedido, sistema,
status do pedido.
Modelo Conceitual
Observar as responsabilidades e os 
relacionamento entre os diferentes 
objetos
Modelo Conceitual
• Identificar os relacionamentos
• Utilizar novamente os Use cases ou user stories
• Exemplos:
• Cliente usa o carrinho de compra
• Pedido pago por pagamento
• Carrinho de compra contém itens
• Cliente faz pedido
• Pedido contém informações de entrega (endereço de
entrega)
Modelo Conceitual
contém
1 n
Modelo Conceitual
• Identificar as responsabilidades de cada classe
• Utilize novamente os user stories e use cases
• Comportamento que se tornará um método
• Ex:
• Verificar itens
• Fornecer informação de pagamento e entrega
• Processar vendar
• Validar pagamento
• Confirmar pedido
• Fornecer número do pedido
• Checar status do pedido
• Enviar detalhes do pedido para o cliente
Modelo Conceitual
• Nem sempre fica óbvio de quem é a
responsabilidade
• Um objeto pode iniciar um comportamento, mas
ser responsável pelo comportamento
• Ex:
• Checar o status do pedido
Iniciado pelo cliente, mas onde reside esse
comportamento? Quem executa a
responsabilidade? IMPORTANTE:
As responsabilidades devem ser distribuídas 
entre os objetos
Modelo Conceitual
Cartões CRC
• CRC = Class Responsability Collaboration
Nome da classe
Responsabilidade Colaboradores
Pagamento
• Armazenar 
detalhes do 
pagamento
• Validar pagamento
• Pedido
Cartões CRC
Cartões CRC
Convertendo diagrama de classes 
para código
public class Produto {
// Atributos
public String nome;
public boolean estaAtivo;
private int qtdEstoque;
// Métodos
public string pegaNome(String desc) {
return desc;
}
public int defineEstoque(int qtd) {
qtdEstoque = qtd;
return
}
}
Visibilidade 
(- privado e + público)
Tempo de vida dos objetos
• O que acontece quando um objeto é criado
(instanciado)?
• O que acontece quando um objeto é descartado?
• Instanciação:
• Produto prod1 = new Produto();
• Construtor:
// Construtor
public Product() {
nome = “sem nome”;
estaAtivo = false;
}
// Construtor sobrecarregado
public Product(String n) {
nome = n;
estaAtivo = false;
}
Membros estáticos
// Variáveis estáticas
public static float taxaImposto;
Produto.taxaImposto = 10.0;
prod1.nome;
prod2.nome;
prod3.nome;
Referências
• Allardice, S. Foundations of Programming Object-Oriented Design,
Disponível online em: www.lynda.com, acessado em setembro/2016.
• Booch, G.; Rumbauch, J.; Jacobson I. UML Guia do Usuário, Editora
Campus, 2006.