Slides Poo2 Unificados

3.
1 FERRAMENTAS PARA PROGRAMAÇÃO EM

LINGUAGEM ORIENTADAS A OBJETOS
Professor: Edilson Lima
2
FERRAMENTAS
Na programação temos que utilizar boas práticas no desenvolvimento de
software. Com isso são colocados os elementos de testes unitários,
ferramentas para documentação e controle de versão. Assim, os testes em
software são essenciais para que o produto entregue tenha os requisitos de
qualidade impostos pelo cliente ou cenários em que o sistema será
implementado.
3
3.1 FERRAMENTAS PARA PROGRAMAÇÃO EM LINGUAGEM
ORIENTADAS A OBJETOS
▸ Os testes em software são essenciais para que o produto

entregue tenha os requisitos de qualidade imposto pelo cliente
ou os cenários nos quais o sistema será implementado. Para
avaliar esses testes, devemos primeiramente observar três
conceitos básicos sobre testes (AMMANN, 2008):
4
1. Defeito: implementação incorreta feita em uma aplicação.

2. Erro: manifestação desse defeito ou falha.
3. Falha: comportamento externo que resulta em problemas de
execução de um sistema (por exemplo, problemas de rede ou
hardware).
5
▸ Podemos criar um grande arcabouço para fazer com que uma
aplicação tenha seu número de defeitos minimizado e, assim,
menor probabilidade de erros. Para isso, podemos executar
diversas formas de testes obter um cenário com poucos erros.
Também, é possível investir em uma documentação acurada e
em um sistema de controle de versão de código, a fim de
aumentar a confiabilidade do sistema e seu desenvolvimento. A
forma inicial para a produção de testes são os testes unitários.
6
▸ Para isso, podemos executar diversas formas de testes para
obter um cenário com poucos erros. Também, é possível investir
em uma documentação acurada e em um sistema de controle de
versão de código, a fim de aumentar a confiabilidade do sistema
e seu desenvolvimento.
7
Testes Unitários em Java

8
▸ Existem diversas categorias de testes, tais como de módulos,

de integração, de sistema e de validação (SOMMERVILLE,
2016). Um dos testes iniciais que podem ser feitos é o
unitário, cujo objetivo é verificar se os métodos estão
funcionando.
9
▸ Umas das ferramentas utilizadas para realizar esse tipo de

teste é o JUnit, com o qual é possível fazer diversas
avaliações para confirmar se o código está funcionando
corretamente (TAHCHIEV, 2010). O teste unitário pode ser
comparado a testar e validar todas as peças de um carro
antes de fazer a montagem. Se as peças estão funcionando
corretamente, as chances de a montagem funcionar
aumentam.
10
▸ Vamos utilizar um exemplo para demonstrar a criação de

testes unitários.
classe Calculadora
▸ Com base nessa classe vamos desenvolver os testes
unitários.
11
▸ Os testes unitários têm o objetivo de validar o funcionamento

de um método, sendo, assim, possível detectar problemas e
validar a coesão e o acoplamento de cada elemento. Desta
forma, pode-se validar o funcionamento das partes,
minimizando o erro quando esses componentes forem
conectados.
12
▸ Para executar esses testes, é necessário que alguma

ferramenta auxilie no processo juntamente com o JUnit. O IDE
Eclipse já possui integração para fazer os testes unitários,
cuidando da sua criação e execução através de uma
determinada classe.
13
▸ Ao utilizar o NetBeans, é preciso criar um JUnit Test Case,

seguindo o menu Arquivo->Novo Arquivo->Em categorias
selecione Testes de Unidades->Em tipo de arquivos selecione
Teste para a classe existente->Procure a classe a testar e
Finalize e uma classe para testar foi criada.
14
▸ Dentro da classe CalculadoraTeste temos quatro

métodos, cada um relacionado a um método da classe
Calculadora.
15
▸ A marcação @Test se refere ao JUnit para afirmar que o

método imediatamente abaixo é um teste. Utilizaremos como
exemplo o teste chamado void testSomar(). Nesse
método, a classe Calculadora (Calculadora c = new
Calculadora();) é instanciada e o método double res =
c.soma(10, 50); é utilizado, guardando o resultado em
uma variável.
16
▸ O assertEquals(60, res);. O assert vem do inglês

afirmar ou confirmar, então, esse método vai comparar o 60
com o valor de res. Se esses valores forem iguais, é
considerado como sucesso, mas caso seja diferente, significa
que o teste falhou. Os outros métodos seguem a mesma
lógica, fazendo a instância da classe que se quer testar e
utilizando o assert para validar o resultado. Assim, a lógica
dos métodos pode ser testada, evitando enviar para o cliente
resultados inesperados.
17
2.1 PROGRAMAÇÃO EM JAVA USANDO THREADS
18
Testes unitários: defesa contra os bugs

▸ Dessa forma, é possível verificar que os testes unitários são a
primeira linha de defesa contra os bugs, o que ajuda a garantir
que cada parte de um sistema esteja funcionando e, ainda que
em caso de modificações, o sistema ainda mantenha seu
funcionamento. Em certos cenários de desenvolvimento e até
algumas ferramentas não permitem que o software seja
liberado ou integrado a uma aplicação sem antes que todos os
testes unitários tenham sucesso. Outra forma de garantir que
defeitos não sejam gerados em um sistema é a utilização
correta da documentação de um sistema.
19
Documentação de código fonte com o

Javadoc
20
Documentação de código fonte com o Javadoc
▸ O Javadoc é uma ferramenta produzida pela própria Oracle

que documenta todos os códigos de sistema implementado
em Java. Com ela é possível fazer diversas marcações no
decorrer do código para gerar uma versão em HTML para
explicar o funcionamento de cada classe, métodos e outros
de uma aplicação (DEITEL; DEITEL, 2016).
21
▸ Essa documentação tem o objetivo de explicar a função de

cada elemento do código para os desenvolvedores, e não
diretamente para o usuário (HORSTMANN, 2016).
22
Gerando a documentação pelo Javadoc

▸ A documentação gerada pelo Javadoc é feita por meio de
anotações específicas, que são utilizadas para identificar as
partes do código e estruturar o documento HTML para que
fique organizado. Algumas anotações usadas com frequência
estão especificadas no quadro.
23
Exemplos de marcação do Javadoc

24
▸ A seguir exemplo da codificação para gerar o Javadoc.

25
▸ A seguir exemplo da codificação para gerar o Javadoc.

26
▸ Javadoc.
27
▸ Javadoc.
28
Importante!
▸ A junção dos testes unitários e o mecanismo de
documentação são um grande avanço na qualidade do
desenvolvimento. Além desses dois elementos, é de grande
importância uma forma de gerenciar as versões de um
software e as contribuições de diversas pessoas da equipe.
29
Sistema de controle de versão

30
▸ Existem diversos sistemas de controle de versão, tais como

o Concurrent Versions System (CVS), Apache
Subversion (SVN), git e outros. Um que está em grande
destaque é o git, um sistema de controle de versão muito
simples e versátil e, para utilizá-lo, é possível fazer a
integração via Eclipse ou usar diretamente no terminal
(CHACON, 2018).
31
Vamos sintetizar esse

procedimento de
desenvolvimento?
▸ Em resumo, com o uso do
sistema de versão, o
procedimento de
desenvolvimento pode ser
sintetizado em cinco passos:
32
▸ Com essa etapa dos estudos é possível avançar nas formas

de produção, controle e documentação, além de produzir
códigos profissionais e duradouros.
33
HORA DE PRATICAR
Situação problema
atividade
34
▸ Introdução: Esse sistema possui diversos sensores e é

necessário utilizar uma classe que acumula todas essas
medidas e calcula a média e desvio padrão, é necessário
produzir um teste unitário para garantir que os cálculos estão
corretos e os dados foram armazenados na classe de maneira
correta. Utilizando a classe do Quadro 1 [próximo slide], se
deve desenvolver os testes unitários. Para isso se deve criar
um teste unitário para método onde seja possível validar sua
execução.
35 Atividade proposta:
package U3S1;
import java.util.ArrayList;
/**
*
* @author Edilson Lima
*/
public class EstatisticasUmidade {
private ArrayList<Double> lstUmidade;

public EstatisticasUmidade()
{
lstUmidade = new ArrayList<Double>();
}
public void setValor(double umidade)
{
lstUmidade.add(umidade);
}
public double media(int amostra)

{
double soma = 0.0;
for (int i = 0; i < amostra; i++) {
soma = soma + lstUmidade.get(i);
}
return soma/lstUmidade.size();
}
public double desvioPadrao(int amostra)

{
double media = media(amostra);
double st = 0.0;
for (int i = 0; i < amostra; i++) {
st = st + Math.pow(lstUmidade.get(i) -
media, 2);
}
return st/amostra;
}
}
• Os testes unitários devem validar o método que calcula a média e o

desvio padrão. Deve ser feito um método para cada teste com a
marcação @Teste onde é utilizado a classe e o resultado da
execução comparado com o devido assert.
Checklist:
Para verificar se a tarefa foi concluída com sucesso, os seguintes itens
devem ser contemplados:
• Criar os testes utilizando a marcação @Test;
• Todos os testes são executados retornando sucesso;
• O teste unitário consegue validar cenários de execução do método.
• Foram documentados todos os métodos com a tags @param e
@return.
• Foi documentada a classe com os parâmetros @author e @since
• Parâmetros foram descritos utilizando a tag @param;
• Os tipos de retorno forma mapeados pela tag @return;
41
Obrigado!
Não somos o que a sociedade e o acaso fizeram de nós, e sim
o que escolhemos ser, desde o mais profundo do nosso ser.
Peter Koestenbaum
edilsonlima3@gmail.com
42
Bibliografia
Programação Orientada a Objetos com Java - 4ª Ed.

Barnes,David J.; Kolling,Michael - Pearson Universidades
Programação Orientada A Objetos - Conceitos e

Técnicas
Furgeri, Sergio - Editora Érica
43
Bons estudo, muita dedicação e exclentes resultados.
😉 Email
✋👆👉👍👤👦👧👨👩👪💃🏃
💑❤😂😉😋😒😭👶😸🐟🍒
🍔💣📌📖🔨🎃🎈🎨🏈🏰🌏🔌
🔑 em busca de resultados...
3.3 MÉTODOS ÁGEIS EM ORIENTAÇÃO A
OBJETOS
2
Métodos Ágeis
O desenvolvimento de software é essencial para todas as atividades, e
podemos encontrar exemplos desta afirmação em todas as áreas, basta
olharmos ao redor. Durante o início da computação, o software não recebia
a sua devida importância, e o hardware recebia todo o crédito pelas
aplicações computacionais. Contudo, esse contexto mudou rapidamente,
devido à popularidade das soluções que o computador provia.
3
3.3 MÉTODOS ÁGEIS EM ORIENTAÇÃO A OBJETOS
▸ A maneira de desenvolvimento de software seguia uma

metodologia semelhante aos projetos de hardware, com
formas rígidas de desenvolvimento, ignorando as
necessidades de diversas partes.
4
O modelo de cascata foi a primeira maneira de

desenvolvimento e é considerado o modelo direto para o
desenvolvimento de software. A Figura apresenta as
etapas clássicas de desenvolvimento de software nesse
modelo (SOMMERVILLE, 2011):
5
1. Requisitos: levantar, entender e desenvolver as necessidades

que levam à criação do software.
2. Projeto: elaborar os diagramas de Unified Modeling
Language (UML - linguagem de modelagem unificada) e
escolher as arquiteturas de software para o projeto.
3. Implementação: desenvolver o software utilizando os
requisitos e o projeto feitos nas etapas anteriores.
4. Verificação: executar os testes no software e fazer a
instalação.
5. Manutenção: verificar e corrigir problemas que foram
detectados durante a operação do software.
6
Problemas do modelo castaca (STELLMAN, 2015):

1. As etapas de requisitos e de projeto tomam muito tempo, comparadas ao
projeto completo, assim, depois de certo tempo, apenas a documentação
poderia ser entregue ao cliente, e não o software.
2. O software entregue, em diversos casos, não atende às necessidades do
cliente, mesmo ele tenha as detalhado.
3. Durante o desenvolvimento, o projeto muda devido a dificuldades ou
limitações, levando a uma implementação diferente do projeto.
4. Como o tempo de desenvolvimento pode ser grande, as etapas anteriores não
geram entregáveis. Além disso, a etapa de testes pode ser negligenciada,
validando os requisitos levantados no início do projeto, que podem não
coincidir com o estado atual do desenvolvimento do sistema.
7
▸ Devido às limitações que o modelo em cascata apresenta,

surgiram outras formas de desenvolvimento de software.
Esses modelos são caracterizados pela sua visão
incremental dos estágios do modelo canônico cascata. Com
isso, as etapas são feitas diversas vezes no projeto, até que
o sistema esteja pronto.
8
▸ Dois modelos relacionados a esse tipo de abordagem são o

em espiral e o de protótipo, que evitam diversos problemas
que o modelo em cascata apresenta, tais como a entrega
tardia do projeto e a distância entre requisitos e projeto com
o software.
9
▸ Todavia, as próprias metodologias apresentam limitações

em um aspecto essencial que os programas de
computadores possuem, pois a maioria dessas aplicações é
utilizada por pessoas que não são aquelas que fazem o
pedido ou que estão envolvidas no processo.
10
▸ Ao final, mesmo com todo o aspecto incremental, as

entregas continuam a enviar para o cliente algo que ele não
esperava ou, ainda, algo em uma ordem não relacionada à
importância para o cliente.
11
▸ Diante desse cenário de diversas inconsistências, com o

objetivo de encaminhar as formas de resolução para as
questões de requisitos, prioridade de entrega, mudanças no
projeto e outros, em 2001 foi elaborado um manifesto com 4
valores que devem ser levados em consideração durante o
desenvolvimento de software (COHN, 2015):
12
1. Indivíduos e interações mais que processos e ferramentas.

2. Software em funcionamento mais que documentação
abrangente.
3. Colaboração com o cliente mais que negociação de
contratos.
4. Responder a mudanças mais que seguir um plano.
13
▸ Esses quatro valores são permeados por 12 princípios que

os detalham, reforçando que as necessidades do cliente têm
prioridade sob a metodologia. Nesse processo, as pessoas
que fazem parte do uso, gerência, pedido e outros devem
fazer parte do desenvolvimento, e as entregas devem ser
feitas de forma constante e por prioridade que o cliente
definir, mantendo a simplicidade do sistema.
14
Scrum
15
Scrum
O scrum é uma das diversas metodologias que usam conceitos

ágeis, em que são definidos 3 papéis (STELLMAN, 2015):
1. Product owner (PO):
a) Pessoa responsável pelo produto a ser entregue.
b) Determina o que será desenvolvido e em qual ordem.
c) Faz a comunicação entre o time de desenvolvimento e as
outras entidades para garantir a correta visão do que está
sendo desenvolvido.
16
Scrum
Scrum master:
a. Possui familiaridade pela etapa atual de desenvolvimento
podendo ajudar toda equipe.
b. Ajuda a manter os princípios, valores e papéis do scrum.
c. Protege o time de desenvolvimento de interferências
externas.
d. Resolve conflitos e problemas técnicos e pessoais para
garantir a produtividade.
e. Não tem papel de gerência externa.
17
Scrum
Time de desenvolvimento:
a. Grupo de pessoas que se auto-organiza para atingir o objetivo
proposto pelo PO.
b. Com 5 a 9 pessoas, coletivamente possui todas as habilidades
necessárias para realizar o projeto.
18
Scrum
Visão geral das etapas do scrum

19
Scrum
▸ O backlog, consiste em um conjunto de

requisitos/funcionalidades elencadas pelo project onwer, junto
com a equipe de desenvolvimento e o scrum master.
▸ A equipe de desenvolvimento pode opinar em relação aos
requisitos, mas o PO tem prioridade no processo.
20
Scrum
O sprint backlog consiste em um conjunto de funcionalidades

vindas do backlog, selecionadas pelo PO (com certa orientação
técnica do scrum master e do time de desenvolvimento). Tais
tarefas devem ser realizadas e entregues em certo período de
tempo, chamado de sprint. Ao final de cada sprint é gerado um
empregável para o cliente. Todos os dias são feitas reuniões com a
equipe de desenvolvimento (daily meeting) para entender como
está o desenvolvimento da sprint.
21
Como usuário <tipo de usuário>, eu

preciso <objetivo>, pois <necessidades>
22
Como usuário <tipo de usuário>, eu preciso <objetivo>, pois
<necessidades>
▸ O valor deve explicar qual usuário fará a ação, por exemplo, o
usuário padrão, administrador ou outros. O parâmetro descreve
o que deve ser feito, contendo as suas necessidades e
justificativas para implementação. O elemento que explica a
razão auxilia no entendimento das necessidades daquela
funcionalidade e em que momento deve ser priorizada.
23
<necessidades>
▸ Essas histórias são transformadas em tarefas, e o processo
consiste em dividir as histórias em tarefas que possuem um
nome e uma estimativa de tempo. Esse processo é muito
importante, pois o tempo que se espera para concluir uma tarefa
é utilizado para planejar o sprint.
24
<necessidades>
▸ Essas tarefas levam em conta a criação das classes, pois estas
serão criadas a partir dos substantivos das frases. Além disso,
os atributos das classes poderão ser identificados pelos
adjetivos e o relacionamento entre classes através dos verbos
(DEITEL; DEITEL, 2016).
25
<necessidades>
Scrum board para controle das tarefas e histórias
26
Como usuário <tipo de usuário>, eu preciso <objetivo>,
pois <necessidades>
▸ Assim, a atualização do quadro com as histórias e tarefas que
estão sendo feitas pode ocorrer tanto no momento em que
chega nova demanda, quanto durante a sprint de
desenvolvimento. Todos os dias, na reunião diária, as tarefas
são atualizadas e todos informam o que foi feito.
27
pois <necessidades>
▸ A atualização do quadro com as histórias e as tarefas que
desenvolvimento.
28
pois <necessidades>
▸ Todos os dias, na reunião diária, as tarefas são atualizadas e
todos informam o que foi feito. Além do quadro, é feito um
gráfico burndown, que apresenta uma relação entre os dias da
sprint e o esforço em horas da soma das tarefas, sendo T o
tempo total de cada tarefa N e F o tempo utilizado para a tarefa
N que foi efetivo no seu desenvolvimento. Isso mostra o tempo
total ainda necessário para terminar a sprint.
29
pois <necessidades>
Exemplo do gráfico burndown
30
pois <necessidades>
▸ Mesmo com todos os aspectos incrementais, humanos e
interativos que os métodos ágeis possuem, é sempre
necessária a correção de problemas que um código-fonte pode
ter. O sistema em seu início tem uma estrutura orientada a
objetos, e os métodos são bem planejados para ter as
características de coesão e acoplamento. Cada correção
arruma os problemas, porém, tende por alterar a estrutura do
software (COHN, 2015).
31
pois <necessidades>
▸ Para resolver essa questão ou melhorar um código que foi mal
elaborado, existe a refatoração. Esta etapa consiste em alterar
a estrutura de um código sem modificar o seu comportamento,
o que implica que será necessário utilizar tempo no sprint para
alterar o código que já foi implementado e está funcionando.
32
pois <necessidades>
As razões que levam a essa demanda são diversas. Podemos citar
alguns cenários que podem ser os sinais de que é necessário
utilizar tempo para refatorar o código (MESZAROS, 2007):
▸ Nomes de variáveis, métodos ou atributos sem significado para
o sistema.
▸ Partes do código duplicadas.
▸ Códigos extensos que poderiam ser reaproveitados de
bibliotecas ou de outros projetos.
▸ Porções de códigos que não passaram nos testes (nesse caso,
os testes unitários ganham destaque para forçar uma
refatoração).
33
pois <necessidades>
▸ O tempo gasto em correções dos bugs ser alto comparado ao
tempo de desenvolvimento.
▸ Os programadores, quando têm que corrigir um problema em
módulos de autoria de outras pessoas, utilizam muito mais
tempo que nos de própria autoria.
34
pois <necessidades>
Todos esses sintomas devem ser avaliados durante as etapas de
desenvolvimento para desencadear os processos de refatoração.
Existem momentos indicados para que seja feito o processo de
correção do código, que podem ser:
▸ Quando se adiciona uma nova característica ao software, quando é
possível ver quais partes são utilizadas e, então, corrigir os problemas.
▸ No próprio processo de correção de bugs pode-se averiguar as
condições do código e aplicar as correções.
▸ Em casos mais complexos, pode ser necessário fazer uma revisão de
código e aplicar a refatoração, dessa forma, tentase minimizar o
tempo de correção e entendimento do código.
35
pois <necessidades>
Os processos de refatoração podem ser descritos como uma
revisão e melhor entendimento de cada parte do código. Há
metodologias precisas para descrever como um código deve ser
refeito para se tornar melhor. Aqui abordaremos as formas mais
gerais:
▸ Métodos devem ser claros, e a sua função precisa ser muito
bem descrita. A função de um método deve ser uma tarefa direta
e simples.
▸ As classes necessitam sempre buscar a alta coesão e o baixo
acoplamento, ou seja, fazer ações específicas de maneira
independente.
36
pois <necessidades>
▸ Durante a refatoração não se deve incluir novas funções, o foco
deve ser deixar o código mais legível e preciso.
▸ Todos os testes ao final da refatoração devem ter sucesso, e
essa é uma medida de qualidade essencial em projetos.
37
pois <necessidades>
▸ A refatoração consiste em observar o código e avaliar se é
necessário melhorar a base já implementada para que o projeto
tenha uma duração longa.
38
HORA DE PRATICAR
Situação problema
atividade
39
ATIVIDADE PROPOSTA
▸ Desenvolvimento de sistema de automação residencial por uma

empresa que utiliza o sistema Scrum.
40
ATIVIDADE PROPOSTA
Imagine uma situação de uma empresa que está começando a utilizar o

Scrum e já possui os elementos do software descritos como história de
usuário:
1. Como usuário comum, eu preciso ter uma interface gráfica para acionar as
lâmpadas de forma individual, pois é necessário um ajuste unitário de
cada elemento de iluminação.
2. Como usuário comum, eu preciso ter uma opção de emergência que
acione todos os elementos de iluminação da casa, pois consiste em um
requisito de segurança do projeto.
3. Como administrador, eu preciso ter uma interface gráfica para configurar
ou remover elementos de iluminação, pois o sistema deve ser configurável
para cenário proposto
41
ATIVIDADE PROPOSTA
▸ Agora é necessário organizar o sprint visando que o cliente gostaria

de ter uma versão básica o quanto antes focando no acionamento
das lâmpadas. Dessa forma é necessário converter as histórias de
usuário em tarefas. O aluno deve entregar o protótipo da interface
gráfica, uma modelagem do banco de dados e simular 2 a 3 daily
meating para alinhar o que deve estar na interface gráfica e no
banco de dados.
42
ATIVIDADE PROPOSTA
Utilizando como base a história de usuário, o aluno deve dividir todos

os elementos em tarefas visando uma atividade que o programador
poderia implementar e testar, encaminhando para a entrega que o
usuário pediu para criar o sprint:
▸ Tarefa A: Criar banco de dados para cadastro de elementos de iluminação;
▸ Tarefa B: Criar interface gráfica de controles para cadastro de elementos
de iluminação;
▸ Tarefa C: Criar interface gráfica de controles para o acionamento e
desligamento dos elementos de iluminação.
43
ATIVIDADE PROPOSTA
Como parte do desenvolvimento, os alunos devem simular 4 dias de

desenvolvimento com os membros da equipe. No primeiro dia deve
ser desenvolvido um modelo do banco de dados contendo:
Tabela itensIluminacao:
a. id (int);
b. nome (String);
c. Localização (String); d. Estado (booleano).
44
ATIVIDADE PROPOSTA
1. Deve ser efetuada a daily meeting e apresentar esse modelo de

banco de dados, e iniciar o desenvolvimento da primeira interface
gráfica (Figura 1).
Protótipo da tela de cadastro
45
ATIVIDADE PROPOSTA
Checklist:
Para verificar a tarefa se deve:
1. Verificar se todas as tarefas são derivadas das histórias de
usuário;
2. Existem apenas tarefas que levam a entrega que o cliente pediu;
3. Verificar se as interfaces gráficas e banco de dados contemplam
as descrições que os usuários colocam.
46
Obrigado!
Peter Koestenbaum
47
Bibliografia


Técnicas
48
😉 Email
✋👆👉👍👤👦👧👨👩👪💃
🏃💑❤😂😉😋😒😭👶😸🐟🍒
🍔💣📌📖🔨🎃🎈🎨🏈🏰🌏
🔌🔑 em busca de resultados...
4.1 BANCO DE DADOS NoSQL
2
NoSQL
este tipo de banco de dados não tem um
esquema de dados rígido, o que facilita as
mudanças da aplicação durante o seu
desenvolvimento. Além disso, é possível fazer
escalonamento e alta disponibilidade, de
maneira mais simples e abrangente.
3
▸ O armazenamento de dados estruturados é um dos pilares da

computação. Desde o início do uso mais abrangente da
computação, os bancos de dados possuem papel importante
para garantir a persistência e a disponibilidade dos dados.
4
▸ Todavia, o dinamismo necessário na modelagem dos dados, o

grande volume de informação disponível (big data) e o acesso
acesso a informação fez com que o modelo clássico de banco
de dados fosse renovado. Ao invés de um sistema
centralizado e rígido, atualmente faz-se necessário criar
sistemas de armazenamento, de forma mais diversificada,
conhecida como not only SQL (NoSQL).
5
▸ Os NoSQL são sistema de banco de dados que possuem

elementos mais relacionados ao desempenho, à modelagem
dinâmica e à escalabilidade. Dessa forma, propicia formas
mais precisas de tornar os sistemas mais ágeis a constante
mudanças. Esse novo modelo de armazenamento de
informação foi proposto a partir da necessidade de sistemas
de banco de dados relacionais mais leves.
6
▸ O termo NoSQL se refere a “Not Only SQL”, ou seja, não apenas

SQL. O nome faz à analogia a não obrigatoriedade de usar uma
linguagem de consulta estruturada (como o SQL), pois o
próprio modelo de armazenamento não é estruturado na forma
de tabelas e colunas.
7
▸ De forma direta, os bancos de dados NoSQL tratam a

informação como um formato em que a estrutura não precisa
ser definida. Ainda, a forma de buscar a informação não obriga
o programador a saber como os dados estão organizados,
diferente do modelo relacional. Dessa forma, o
desenvolvimento se torna mais dinâmico e mais adaptável
para as constantes mudanças que podem ocorrer durante o
processo, deixando, assim, mais próximo o desenvolvimento
das metodologias ágeis.
8
▸ Cenários mais clássicos, como instituições financeiras,

sistemas legados e operações críticas, em que a relação de
diversas tabelas é necessária, o uso do NoSQL deve ser
analisado com cautela. Uma das limitações dos sistemas
NoSQL refere-se à propriedade de atomicidade das operações,
assim, a utilização do NoSQL em cenários em que esse tipo de
operação é essencial deve ser analisada com cuidado.
9
Atomicidade
‍
▸ É uma característica do SGBD, na qual uma operação deve ser
executada por completo ou falhar, como a transferência de
dinheiro entre contas bancárias.
10
▸ Sistemas de banco de dados NoSQL são indicados para os

casos em que a estrutura dos dados não precisa ser definida,
para que seja possível fazer as operações de consulta,
alteração, inserção e exclusão. Com isso é possível obter
outras vantagens, como a escalabilidade no aumento da
quantidade de informação e o dinamismo do desenvolvimento.
11
O NoSQL possui um conjunto de características básicas que

devem ser utilizadas para guiar a tomada de decisão no uso
dessa nova tecnologia.
1. Independente de esquema
O armazenamento não possui uma organização rígida,
levando a um conjunto de bibliotecas para acesso mais
simples.
12
2. Livre de junções de tabelas

Não são indicados os joins, mesmo que possíveis em alguns
modelos, tornando a utilização menos complexa.
13
3. Crescimento horizontal
A maioria das soluções NoSQL é escalável, sendo anexados

mais computadores e não necessariamente computadores
mais caros.
14
4. Hardware mais simples
É possível utilizar mais hardware barato pela própria

arquitetura da solução.
15
5. Autocontido
Cada computador que funciona como armazenamento é

independente, levando em diversos casos, cópias das bases
de dados.
16
5. Controle de usuário
Necessita de poucos elementos de controle de usuário,

transação e concorrência.
17
Modelos de dados para os NoSQL

▸ Como a estrutura de acesso à informação em um NoSQL é
simples, torna-se possível variar a estrutura interna de
controle. Existem muitos modelos para organizar a informação
dentro de um NoSQL, todavia, existem quatro modelos mais
comuns:
18
Modelos de dados para os NoSQL

▸ Como a estrutura de acesso à informação em um NoSQL é
simples, torna-se possível variar a estrutura interna de
controle. Existem muitos modelos para organizar a informação
dentro de um NoSQL, todavia, existem quatro modelos mais
comuns:
19
1. Key-value
▸ O sistema de key-value é uma estrutura mais simples, em que
cada conjunto de dados possui apenas uma chave principal. A
imagem a seguir apresenta um exemplo deste sistema, onde
na coluna Key temos um número que identifica o registro e na
coluna value existem os valores armazenados. Repare que não
é necessário padronizar os dados, sendo que os valores da
entrada 1 são diferentes da entrada 2.
20
1. Key-value
21
1. Key-value
▸ Um exemplo modelo key-value é o Amazon SimpleDB. Esse
tipo de organização contém as seguintes vantagens:
22
2. Document stores
▸ No modelo document stores, diversos arquivos formatados são
utilizados para fazer o armazenamento dos dados. Em vários
casos, utiliza-se o Extensible Markup Language (XML) ou
o JavaScript Object Notation (JSON) para fazer a formatação
dos dados que são armazenados no NoSQL. A imagem a
seguir apresenta um exemplo de um JSON.
23
2. Document stores
▸ Observe que é possível criar diversas estruturas em cada
registro e ainda no próprio NoSQL você pode utilizar diversos
arquivos diferentes para guardar os dados.
24
2. Document stores
▸ Um exemplo de uso do modelo document stores é o MongoDB.
Esse modelo apresenta as seguintes vantagens:
25
3. Sistema orientado a colunas

▸ Organiza a informação de forma semelhante ao document
stores. Todavia, ele cria estruturas separadas para juntar
informações pertinentes a uma entidade. Sua aplicação é
considerada mais específica, pois os casos de uso são
relacionados a sistemas com grande volume de dados já
estruturados e com necessidade de processamento muito
rápida.
26
3. Sistema orientado a colunas

27
4. Grafos
▸ Nesse modelo a informação pode ter uma estrutura inicial
de key-value, porém, existe algum tipo de relacionamento
entre cada uma das entradas dos dados. A imagem a seguir
apresenta um exemplo desse tipo de forma de
armazenamento, em que o item de ID 1 possui ligação com o
item 3 e o item 3 possui ligações com o 2 e o 4. Um exemplo
do modelo de grafos é neo4j.
28
4. Grafos
29
4. Grafos
▸ Existem diversos cenários em que um NoSQL baseado
em grafos pode ser utilizado:
▪ Sistema de recomendações de filmes.
▪ Armazenamento de sistema forense.
▪ Sistema de armazenamento para machine learning.
▪ Relacionamento entre pessoas em uma rede social.
▪ Comunicação de sistema de internet of things (IoT).
30
▸ Podemos então, citar diversos modelos de sistemas NoSQL:

31
▸ Existem diversas soluções e projetos que possuem os

conceitos de NoSQL. Por por ser uma tecnologia
relativamente nova e ter aplicação em um cenário de
armazenamento de dados, é necessário certo cuidado nas
escolhas. Portanto, é essencial o estudo de diversas
implementações e testes para validar a migração para um
NoSQL.
32
HORA DE PRATICAR
Situação problema
atividade
33
▸ Analisar um cenário para implementação de um banco de

dados NoSQL.
▸ O líder técnico descobriu as diversas vantagens de um sistema

NoSQL e tem objetivos de aplicar em alguns cenários do ERP.
O cenário escolhido consiste na parte principal do sistema,
onde são feitos todos os cadastros dos clientes e produtos. A
tabela cliente possui: nome, endereço (logradouro, número,
bairro, CEP e complemento) e CPF, a tabela produto possui:
nome, marca, modelo, fabricantes e quantidade. O papel do
aluno consiste em analisar esses dados e verificar se nesse
cenário é possível aplicar o sistema NoSQL.
Para executar a tarefa é necessário verificar os seguintes pontos:

1. O conjunto de dados depende de transações de banco de
dados constantes;
2. Um grande sistema já feito em SQL clássico;
3. Segurança entre usuário;
4. Concorrência de dados
Nesse cenário é possível fazer a migração para um SGDB NoSQL,

pois:
1. O conjunto de dados não depende de transações;
2. O sistema será migrado em partes, o que leva a facilidade de
aplicação;
3. Não são dados sensíveis, dessa forma é possível utilizar
proteções básicas;
4. Não existe concorrência direta dos dados.
Produtos:
• nome;
• marca;
• modelo;
• fabricantes;
• quantidade.
Utilizando a forma de JSON do MongoDB se deve produzir uma

estrutura para a tabela de clientes como no Quadro 1.
• Para os dados de produto se deve produzir uma estrutura

semelhante como no Quadro 2.
Checklist:
• Analisar os pontos positivos e negativos do cenário proposto.
• Pensar em uma estrutura de dados para o sistema em formato
JSON.
41
Obrigado!
Peter Koestenbaum
42
Bibliografia


Técnicas
43
😉 Email
✋👆👉👍👤👦👧👨👩👪💃🏃
💑❤😂😉😋😒😭👶😸🐟🍒
🍔💣📌📖🔨🎃🎈🎨🏈🏰🌏🔌
4.2
INTRODUÇÃO AO DESENVOLVIMENTO
EM JAVA USANDO MongoDB
2
MongoDB
Vamos ver que a utilização e a configuração
básica deste sistema de gerenciamento de
banco de dados (SGBD) é simples, comparada a
SGDB relacionais simples.
3
4.2 INTRODUÇÃO AO DESENVOLVIMENTO EM JAVA USANDO MongoDB
▸ O MongoDB tem seu nome derivado da palavra humongous que

significa enorme ou monstruoso, declarando um novo sistema
de gerenciamento de banco dados com as premissas do NoSQL.
4
▸ O MongoDB possui 3 elementos básicos para o armazenamento,

que consistem no banco de dados, na coleção e
no registro. Cada banco de dados possui diversas coleções, que
são conjuntos de registros com a mesma estrutura, e os
registros são os dados armazenados.
5
▸ Utiliza uma estrutura do sistema NoSQL

chamada document stores, em que são utilizados arquivos
formatados para fazerem o armazenamento da informação.
Esses arquivos utilizam o formato JSON (JavaScript Object
Notation), sendo os dados gravados em modo binário. Esse
formato tem sido muito usado devido ao seu processo de leitura
(por humanos e computadores) ser considerado simples
quando comparado aos sistemas mais complexos, como grafos
ou formatos proprietários.
6
Versões do MongoDB
▸ Existem diversas versões disponíveis deste projeto, tais como:
a Atlas, para ser utilizada na nuvem e composta por formas
simples de criar instâncias e conjuntos do SGDB;
o Community Server, que pode ser utilizado de forma livre (que
usaremos aqui) e o Enterprise Server, que envolve custos de
licenciamento, porém possui algumas características a mais que
a versão Community.
7
Download
▸ Faça o donwload em:https://goo.gl/pXAhsu (aba Community
Server), acesso em: 8 out. 2018. Existem versões para GNU/Linux,
Microsoft Windows e Mac OSX (selecione a versão para
Microsoft Windows versão 4.0, a arquitetura do computador deve
ser x86).
8
Instalação
▸ Durante a instalação, selecione a versão Custom e certifique-se de
que todos os componentes estejam selecionados e sejam
instalados.
▸ Após essa etapa, selecione a opção “Install MongoDB as a Service”.
▸ No item Data Directory, insira o caminho C:\data\db, e no item Log
Directory, insira C:\data\log. Utilizar a opção de instalar como serviço
garante que o Microsoft Windows controle o início de forma
independente.
▸ Após essa etapa, selecione o item que define a instalação
do MongoDB Compass.
9
Após a instalação
▸ É necessário verificar se as pastas, onde serão armazenados os
bancos de dados e os arquivos de log do MongoDB, foram
criados (C:\data\db e C:\data\log). Em caso negativo, você deverá
criá-las.
▸ Para isso, você pode utilizar o Explorador de Arquivos do
Microsoft Windows, mas também é possível fazer esse processo
com o prompt de comando do Windows (Command Prompt ou
CMD).
10
▸ As pastas C:\data\db e C:\data\log, são usadas pelo MongoDB

para armazenar os bancos de dados e os arquivos de log,
respectivamente. Ao executar o MongoDB, caso ele não encontre
tais pastas, será exibido um erro e o SGBD não será aberto.
11
Iniciar servidor
▸ Antes de iniciar o MongoDB, é necessário garantir que o servidor
mongod tenha sido iniciado. Para isso, ainda no prompt e como
administrador, é necessário utilizar o comando: "C:\Program
Files\MongoDB\Server\4.0\bin\mongod.exe"
▸ Ao “subir” o servidor, você verá na última linha, dentre várias
mensagens, a instrução “waiting for connections on port 27017”.
▸ O servidor estará esperando por conexões na porta 27017, que é
a padrão usada pelo MongoDB. Em seguida, você deve abrir uma
nova janela de prompt (sem fechar a que está aberta) e utilizar o
comando "C:\Program Files\MongoDB\Server\4.0\bin\mongo.exe"
12
▸ A imagem apresenta o resultado de executar o MongoDB shell,

repare que no final da imagem a entrada de comando apresenta
apenas o sinal de maior (>), isso significa que o
MongoDB shell está esperando por comandos.
13
14
▸ Existem diversas operações que podem ser feitas na interface

textual do MongoDB. Veja a seguir os comandos que podem ser
utilizados.
15
Criar um banco de dados

▸ Para criar um banco execute o comando: “use testeBanco”
onde testeBanco é o nome do banco a ser criado.
▸ Ao confirmar o comando com “enter”, recebemos a resposta
“switched to db testeBanco”, porém, ao executar o comando
“ show dbs”, ele não aparece na lista (mesmo tendo sido criado).
16
▸ Para que ele apareça na lista, é necessário que haja algum

registro nesse banco. Então, para fazer a inserção de algum
registro pelo terminal, é necessário utilizar o comando:
db.alunos.insertOne( { nome: "João", idade: 25, curso: "ADS" }
▸ Em que alunos é o nome da collection, os dados são separados

por vírgula e o texto é definido por aspas duplas.
17
18
Para a criação de um banco de dados no MongoDB, via linha de

comando, é necessário seguir os seguintes passos:
1. Abrir o CMD do Microsoft Windows como Administrador.
2. C:\Program Files\MongoDB\Server\4.0\bin\mongod.exe
3. Abrir outra janela de CMD do Microsoft Windows como
Administrador.
4. Executar o comando C:\Program
Files\MongoDB\Server\4.0\bin\mongo.exe.
19
5. No MongoDB shell você deve utilizar os seguintes comandos

(substituindo os valores entre < > por suas escolhas):
a. use <nome do banco>
b. db.<nome da collection>.insertOne( { chave1: "Valor1", chave2:
25 } )
c. show dbs
d. show collections
20
▸ A criação e a inserção de dados no MongoDB ocorre sem a

obrigatoriedade de uma modelagem, na qual se definem tabelas,
tipos de dados e relacionamentos.
▸ No MongoDB, as colunas são criadas automaticamente, à medida
que os dados são inseridos. O único passo obrigatório é definir
em qual coleção os dados serão inseridos.
21
▸ Outra forma de se administrar o banco de dados é utilizar

o MongoDB Compass, que é instalado junto com o pacote, sendo
possível fazer as mesmas ações que estão disponíveis na linha
de comando, com interface gráfica. Explore a galeria para ver
mais.
▸ Visão da interface gráfica para controle do MongoDB, onde estão
sendo exibidos todos os bancos de dados disponíveis e, ao
selecionar um deles, é possível ver suas collections.
22
23
▸ Visão da interface gráfica para visualização dos dados, onde é

possível visualizar em detalhe como os dados são apresentados.
24
Acesso ao MongoDB pelo Java

▸ Após a instalação do MongoDB e dos testes iniciais, é preciso
instalar as dependências necessárias para utilizar esse SGBD
junto ao Java e ao Eclipse. Uma das opções é baixar o arquivo
Jar e incluí-lo diretamente no projeto, o que está cada vez menos
aconselhado, pois todo o tratamento de dependência é feito pelo
programador.
▸ Uma forma mais dinâmica é utilizar o Maven, que faz o
tratamento e o controle das dependências das bibliotecas em
uma aplicação Java de maneira documentada. Com esse
componente é possível apenas indicar o software que será
necessário e ele tratará todas as dependências.
25
▸ No Eclipse é possível criar um projeto já com o suporte

ao Maven seguindo o menu File >> New >> Other. No menu para
criação de novo item, busque Maven e selecione o Maven Project.
▸ Nessa etapa é importante selecionar a opção Create a simple
project (skip archetype selection) e, com isso, não será necessário
escolher entre arquiteturas que o projeto se encaixa na
formatação do Maven.
26
27
▸ Na segunda interface, é preciso definir o Group Id e o Artifact Id, o

primeiro representando um nome único dos projetos e o segundo
definindo o nome para a distribuição do projeto (jar). Como
exemplo, podemos definir o Group Id como exemplo.mongodb e
o Artifact Id como JavaMongoDBTeste. As outras opções podem
ser deixadas como padrão.
28
▸ No projeto criado, existe um arquivo chamado pom.xml. Ele

controla diversos aspectos no projeto, tais como as
dependências, e ao abri-lo é possível ver um editor específico no
Eclipse. Na parte inferior dessa tela, procure por uma a
aba pom.xml e selecione essa opção para editar diretamente no
arquivo, adicionando o conteúdo XML fornecido pelo projeto do
MongoDB.
29
▸ A parte de dependencies foi inserida conforme as

recomendações. Com isso, o projeto está pronto para acessar o
MongoDB pelo Java, portanto, não é necessário tratar
diretamente as dependências e o programador pode focar no
desenvolvimento.
30
31
▸ A utilização do MongoDB é mais simples e direta que de um

SGDB relacional, sendo necessário menos tempo para
configurações e ajustes na estrutura do banco. Esse uso vai de
acordo com as metodologias ágeis, pois a ideia é gastar mais
tempo no desenvolvimento do sistema do que planejar algo que
pode nem ser aceito pelo cliente.
▸
32
HORA DE PRATICAR
Situação problema
atividade
33
Atividade Proposta
▸ Análise de cenários para NoSQL e implementação de um

documento e uma collection no MongoDB.
34
Atividade Proposta
Procedimentos para a realização da atividade:

Uma empresa de desenvolvimento que tem foco em sistemas
enterprise resource planning (ERP) está planejando o uso de banco
de dados NoSQL. Como o ERP dessa empresa é muito grande,
existem diversos cenários que a utilização do NoSQL deve ser
avaliado:
35
Atividade Proposta
▸ Módulo de cadastro de clientes, produtos, vendas etc: essa é a

base do ERP e já possui cerca de 10 anos de código
desenvolvido;
▸ Módulo de envio de notas fiscais: módulo de 5 anos que cuida
da validação e envio das notas fiscais.
▸ Módulo de transações financeiras: executa pagamento de
contas e envio de dinheiro pelo sistema das instituições
financeiras. Sistema em desenvolvimento.
▸ Módulo para análise de vendas: essa parte do sistema irá avaliar
as vendas e procurará padrões para gerar promoções. Sistema
em desenvolvimento
36
Atividade Proposta
Nessa primeira atividade avalie os cenários e monte uma tabela

contendo:
▸ Cenário;
▸ Dependência de relação entre outras tabelas;
▸ Dependência de transações atômicas e semelhantes;
▸ Histórico de desenvolvimento e código legado;
▸ Variedade de tipo de dados;
▸ Avaliação para uso do NoSQL.
37
Atividade Proposta
▸ Essa parte do trabalho consiste em avaliar os cenários, dessa forma o

Quadro 1 apresenta o resultado dessa análise.
38
Atividade Proposta

Cenário Dependênci Dependênci Histórico e Variedade Avaliaçã o

a entre a entre código de tipo de do uso
tabelas e transações legado dados NoSQL
relações
Módulo de Grande Média Código antigo Dados textuais Por depender
cadastros dependência dependência. é a base do e numéricos. de transaçõ es
entre diversos relacionado a ERP e código antigo
tabelas controle de não é indicado
estoque. o uso do
NoSQL
39
Atividade Proposta


relações
Módulo de Grande Média Código de Dados textuais Por depender
envio de notas dependência dependência, tempo médio e numéricos. de transaçõ es
fiscais entre tabelas. relacionado a em relação ao e código antigo
controle de tempo do não é indicado
estoque. sistema. o uso do
NoSQL
40
Atividade Proposta


relações
Módulo de Grande Grande Código novo, Dados textuais Mesmo em
transações dependência dependência ainda em e numéricos. desenvolvimen
financeiro. entre tabelas. de transações. desenvolvimen to o sistema
to. depende muito
de transações,
dessa forma
não é indicado
o uso.
41
Atividade Proposta


relações
Módulo para O dados Pouca de Código novo, Dados textuais Indicado o uso
avaliação de podem ser dependência ainda em e numéricos. de NoSQL, por
venda. importados em em transações. desenvolvimen ser um sistema
banco de to. novo e com
dados pouco
independente. dependência
de transações
42
Atividade Proposta
▸ Agora com o cenário pronto, é necessário preparar a primeira versão do

banco de dados NoSQL que possui características adequadas para
aplicação. No caso, o sistema de avaliação de vendas possui mais
pontos para a utilização de um banco de dados NoSQL. Dessa forma,
você deve criar um banco de dados no MongoDB (que já foi instalado
nos computadores) para abrigar os dados:
• id da venda;
• Nome do cliente;
• Valor total da venda;
• Forma de pagamento;
• Data da compra;
43
Atividade Proposta
▸ Além disso, se deve criar 3 registros de exemplo no banco de dados

NoSQL.
▸ Os passos consistem em:
1. Abrir o Command Prompt clicando com o botão direito do Mouse sobre
o ícone do Menu Iniciar e selecionar Prompt de Comando
(Adminstrator);
2. Executar o comando: "C:\Program
Files\MongoDB\Server\4.0\bin\mongod.exe"
3. Abrir outra janela de prompt e executar o comando: "C:\Program
Files\MongoDB\Server\4.0\bin\mongo.exe"
44
Atividade Proposta
▸ Agora no MongoDB shell se deve:

1. Utilizar o comando use para definir o banco de dados corrente: use
vendas
▸ Utilizar o comando db para criar uma collections com os dados
formatados, por exemplo: db.vendas.insertOne( { id: 10, nomeCliente:
“João”, valorTotal: 1500.00, formagamento: “boleto”, data:
“21/12/2008” } ). Esse comando deve ser repetido mais duas vezes
com dados diferentes;
45
Atividade Proposta
Checklist:
1. Verificar se todos os cenários foram avaliados considerando:
a. Quanto do sistema já foi desenvolvido;
b. Relação entre tabelas;
c. Dependência de transações;
d. Tipos de dados;
2. Para cada cenário o aluno deve apresentar um parecer da utilização do
NoSQL.
3. Verificar se o mongo foi devidamente iniciado.
4. Verificar se as duas janelas do prompt estão abertas e funcionando.
5. Verificar se o banco de dados foi devidamente criado;
6. Verificar se os dados foram devidamente inseridos;
7. Verificar se os dados inseridos condizem com a descrição do sistema.
46
Atividade Proposta
Algumas fontes possuem mais informações sobre padrões

de projeto, por exemplo:
▸ Refactoring Guru disponível em: <http://bit.ly/2wkrIO2>.
▸ Source Making disponível em: <http://bit.ly/2OVzpSF>.
47
Obrigado!
Peter Koestenbaum
48
Bibliografia


Técnicas
49
😉 Email
✋👆👉👍👤👦👧👨👩👪💃🏃
💑❤😂😉😋😒😭👶😸🐟🍒
🍔💣📌📖🔨🎃🎈🎨🏈🏰🌏🔌
4.3 MÉTODOS ÁGEIS EM ORIENTAÇÃO A
OBJETOS
2
Métodos Ágeis
O desenvolvimento de software é essencial para todas as atividades, e
podemos encontrar exemplos desta afirmação em todas as áreas, basta
olharmos ao redor. Durante o início da computação, o software não recebia
a sua devida importância, e o hardware recebia todo o crédito pelas
aplicações computacionais. Contudo, esse contexto mudou rapidamente,
devido à popularidade das soluções que o computador provia.
3
▸ A maneira de desenvolvimento de software seguia uma

metodologia semelhante aos projetos de hardware, com
formas rígidas de desenvolvimento, ignorando as
necessidades de diversas partes.
4
O modelo de cascata foi a primeira maneira de

desenvolvimento e é considerado o modelo direto para o
desenvolvimento de software. A Figura apresenta as
etapas clássicas de desenvolvimento de software nesse
modelo (SOMMERVILLE, 2011):
5
1. Requisitos: levantar, entender e desenvolver as necessidades

que levam à criação do software.
2. Projeto: elaborar os diagramas de Unified Modeling
Language (UML - linguagem de modelagem unificada) e
escolher as arquiteturas de software para o projeto.
3. Implementação: desenvolver o software utilizando os
requisitos e o projeto feitos nas etapas anteriores.
4. Verificação: executar os testes no software e fazer a
instalação.
5. Manutenção: verificar e corrigir problemas que foram
detectados durante a operação do software.
6
Problemas do modelo castaca (STELLMAN, 2015):

1. As etapas de requisitos e de projeto tomam muito tempo, comparadas ao
projeto completo, assim, depois de certo tempo, apenas a documentação
poderia ser entregue ao cliente, e não o software.
2. O software entregue, em diversos casos, não atende às necessidades do
cliente, mesmo ele tenha as detalhado.
3. Durante o desenvolvimento, o projeto muda devido a dificuldades ou
limitações, levando a uma implementação diferente do projeto.
4. Como o tempo de desenvolvimento pode ser grande, as etapas anteriores não
geram entregáveis. Além disso, a etapa de testes pode ser negligenciada,
validando os requisitos levantados no início do projeto, que podem não
coincidir com o estado atual do desenvolvimento do sistema.
7
▸ Devido às limitações que o modelo em cascata apresenta,

surgiram outras formas de desenvolvimento de software.
Esses modelos são caracterizados pela sua visão
incremental dos estágios do modelo canônico cascata. Com
isso, as etapas são feitas diversas vezes no projeto, até que
o sistema esteja pronto.
8
▸ Dois modelos relacionados a esse tipo de abordagem são o

em espiral e o de protótipo, que evitam diversos problemas
que o modelo em cascata apresenta, tais como a entrega
tardia do projeto e a distância entre requisitos e projeto com
o software.
9
▸ Todavia, as próprias metodologias apresentam limitações

em um aspecto essencial que os programas de
computadores possuem, pois a maioria dessas aplicações é
utilizada por pessoas que não são aquelas que fazem o
pedido ou que estão envolvidas no processo. Ao final,
mesmo com todo o aspecto incremental, as entregas
continuam a enviar para o cliente algo que ele não esperava
ou, ainda, algo em uma ordem não relacionada à importância
para o cliente.
10
▸ Diante desse cenário de diversas inconsistências, com o

objetivo de encaminhar as formas de resolução para as
questões de requisitos, prioridade de entrega, mudanças no
projeto e outros, em 2001 foi elaborado um manifesto com 4
valores que devem ser levados em consideração durante o
desenvolvimento de software (COHN, 2015):
11
1. Indivíduos e interações mais que processos e ferramentas.

2. Software em funcionamento mais que documentação
abrangente.
3. Colaboração com o cliente mais que negociação de
contratos.
4. Responder a mudanças mais que seguir um plano.
12
▸ Esses quatro valores são permeados por 12 princípios que

os detalham, reforçando que as necessidades do cliente têm
prioridade sob a metodologia. Nesse processo, as pessoas
que fazem parte do uso, gerência, pedido e outros devem
fazer parte do desenvolvimento, e as entregas devem ser
feitas de forma constante e por prioridade que o cliente
definir, mantendo a simplicidade do sistema.
13
Scrum
14
Scrum
O scrum é uma das diversas metodologias que usam conceitos

ágeis, em que são definidos 3 papéis (STELLMAN, 2015):
1. Product owner (PO):
a) Pessoa responsável pelo produto a ser entregue.
b) Determina o que será desenvolvido e em qual ordem.
c) Faz a comunicação entre o time de desenvolvimento e as
outras entidades para garantir a correta visão do que está
sendo desenvolvido.
15
Scrum
Scrum master:
a. Possui familiaridade pela etapa atual de desenvolvimento
podendo ajudar toda equipe.
b. Ajuda a manter os princípios, valores e papéis do scrum.
c. Protege o time de desenvolvimento de interferências
externas.
d. Resolve conflitos e problemas técnicos e pessoais para
garantir a produtividade.
e. Não tem papel de gerência externa.
16
Scrum
Time de desenvolvimento:
a. Grupo de pessoas que se auto-organiza para atingir o objetivo
proposto pelo PO.
b. Com 5 a 9 pessoas, coletivamente possui todas as habilidades
necessárias para realizar o projeto.
17
Scrum
Visão geral das etapas do scrum

18
Scrum
▸ O backlog, consiste em um conjunto de

requisitos/funcionalidades elencadas pelo project onwer, junto
com a equipe de desenvolvimento e o scrum master.
▸ A equipe de desenvolvimento pode opinar em relação aos
requisitos, mas o PO tem prioridade no processo.
19
Scrum
O sprint backlog consiste em um conjunto de funcionalidades

vindas do backlog, selecionadas pelo PO (com certa orientação
técnica do scrum master e do time de desenvolvimento). Tais
tarefas devem ser realizadas e entregues em certo período de
tempo, chamado de sprint. Ao final de cada sprint é gerado um
empregável para o cliente. Todos os dias são feitas reuniões com a
equipe de desenvolvimento (daily meeting) para entender como
está o desenvolvimento da sprint.
20
Como usuário <tipo de usuário>, eu

preciso <objetivo>, pois <necessidades>
21
<necessidades>
▸ O valor deve explicar qual usuário fará a ação, por exemplo, o
usuário padrão, administrador ou outros. O parâmetro descreve
o que deve ser feito, contendo as suas necessidades e
justificativas para implementação. O elemento que explica a
razão auxilia no entendimento das necessidades daquela
funcionalidade e em que momento deve ser priorizada.
22
<necessidades>
▸ Essas histórias são transformadas em tarefas, e o processo
consiste em dividir as histórias em tarefas que possuem um
nome e uma estimativa de tempo. Esse processo é muito
importante, pois o tempo que se espera para concluir uma tarefa
é utilizado para planejar o sprint.
23
<necessidades>
▸ Essas tarefas levam em conta a criação das classes, pois estas
serão criadas a partir dos substantivos das frases. Além disso,
os atributos das classes poderão ser identificados pelos
adjetivos e o relacionamento entre classes através dos verbos
(DEITEL; DEITEL, 2016).
24
<necessidades>
Scrum board para controle das tarefas e histórias
25
pois <necessidades>
▸ Assim, a atualização do quadro com as histórias e tarefas que
são atualizadas e todos informam o que foi feito.
26
pois <necessidades>
▸ A atualização do quadro com as histórias e as tarefas que
são atualizadas e todos informam o que foi feito. Além do
quadro, é feito um gráfico burndown, que apresenta uma
relação entre os dias da sprint e o esforço em horas da soma
das tarefas, sendo T o tempo total de cada tarefa N e F o tempo
utilizado para a tarefa N que foi efetivo no seu
desenvolvimento. Isso mostra o tempo total ainda necessário
para terminar a sprint.
27
pois <necessidades>
Exemplo do gráfico burndown
28
pois <necessidades>
▸ Mesmo com todos os aspectos incrementais, humanos e
interativos que os métodos ágeis possuem, é sempre
necessária a correção de problemas que um código-fonte pode
ter. O sistema em seu início tem uma estrutura orientada a
objetos, e os métodos são bem planejados para ter as
características de coesão e acoplamento. Cada correção
arruma os problemas, porém, tende por alterar a estrutura do
software (COHN, 2015).
29
pois <necessidades>
▸ Para resolver essa questão ou melhorar um código que foi mal
elaborado, existe a refatoração. Esta etapa consiste em alterar
a estrutura de um código sem modificar o seu comportamento,
o que implica que será necessário utilizar tempo no sprint para
alterar o código que já foi implementado e está funcionando.
30
pois <necessidades>
As razões que levam a essa demanda são diversas. Podemos citar
alguns cenários que podem ser os sinais de que é necessário
utilizar tempo para refatorar o código (MESZAROS, 2007):
▸ Nomes de variáveis, métodos ou atributos sem significado para
o sistema.
▸ Partes do código duplicadas.
▸ Códigos extensos que poderiam ser reaproveitados de
bibliotecas ou de outros projetos.
▸ Porções de códigos que não passaram nos testes (nesse caso,
os testes unitários ganham destaque para forçar uma
refatoração).
31
pois <necessidades>
▸ O tempo gasto em correções dos bugs ser alto comparado ao
tempo de desenvolvimento.
▸ Os programadores, quando têm que corrigir um problema em
módulos de autoria de outras pessoas, utilizam muito mais
tempo que nos de própria autoria.
32
pois <necessidades>
Todos esses sintomas devem ser avaliados durante as etapas de
desenvolvimento para desencadear os processos de refatoração.
Existem momentos indicados para que seja feito o processo de
correção do código, que podem ser:
▸ Quando se adiciona uma nova característica ao software, quando é
possível ver quais partes são utilizadas e, então, corrigir os problemas.
▸ No próprio processo de correção de bugs pode-se averiguar as
condições do código e aplicar as correções.
▸ Em casos mais complexos, pode ser necessário fazer uma revisão de
código e aplicar a refatoração, dessa forma, tentase minimizar o
tempo de correção e entendimento do código.
33
pois <necessidades>
Os processos de refatoração podem ser descritos como uma
revisão e melhor entendimento de cada parte do código. Há
metodologias precisas para descrever como um código deve ser
refeito para se tornar melhor. Aqui abordaremos as formas mais
gerais:
▸ Métodos devem ser claros, e a sua função precisa ser muito
bem descrita. A função de um método deve ser uma tarefa direta
e simples.
▸ As classes necessitam sempre buscar a alta coesão e o baixo
acoplamento, ou seja, fazer ações específicas de maneira
independente.
34
pois <necessidades>
▸ Durante a refatoração não se deve incluir novas funções, o foco
deve ser deixar o código mais legível e preciso.
▸ Todos os testes ao final da refatoração devem ter sucesso, e
essa é uma medida de qualidade essencial em projetos.
35
pois <necessidades>
▸ A refatoração consiste em observar o código e avaliar se é
necessário melhorar a base já implementada para que o projeto
tenha uma duração longa.
36
HORA DE PRATICAR
Situação problema
atividade
37
ATIVIDADE PROPOSTA
▸ Desenvolvimento de sistema de automação residencial por uma

empresa que utiliza o sistema Scrum.
38
ATIVIDADE PROPOSTA
Imagine uma situação de uma empresa que está começando a utilizar o

Scrum e já possui os elementos do software descritos como história de
usuário:
1. Como usuário comum, eu preciso ter uma interface gráfica para acionar as
lâmpadas de forma individual, pois é necessário um ajuste unitário de
cada elemento de iluminação.
2. Como usuário comum, eu preciso ter uma opção de emergência que
acione todos os elementos de iluminação da casa, pois consiste em um
requisito de segurança do projeto.
3. Como administrador, eu preciso ter uma interface gráfica para configurar
ou remover elementos de iluminação, pois o sistema deve ser configurável
para cenário proposto
39
ATIVIDADE PROPOSTA
▸ Agora é necessário organizar o sprint visando que o cliente gostaria

de ter uma versão básica o quanto antes focando no acionamento
das lâmpadas. Dessa forma é necessário converter as histórias de
usuário em tarefas. O aluno deve entregar o protótipo da interface
gráfica, uma modelagem do banco de dados e simular 2 a 3 daily
meating para alinhar o que deve estar na interface gráfica e no
banco de dados.
40
ATIVIDADE PROPOSTA
Utilizando como base a história de usuário, o aluno deve dividir todos

os elementos em tarefas visando uma atividade que o programador
poderia implementar e testar, encaminhando para a entrega que o
usuário pediu para criar o sprint:
▸ Tarefa A: Criar banco de dados para cadastro de elementos de iluminação;
▸ Tarefa B: Criar interface gráfica de controles para cadastro de elementos
de iluminação;
▸ Tarefa C: Criar interface gráfica de controles para o acionamento e
desligamento dos elementos de iluminação.
41
ATIVIDADE PROPOSTA
Como parte do desenvolvimento, os alunos devem simular 4 dias de

desenvolvimento com os membros da equipe. No primeiro dia deve
ser desenvolvido um modelo do banco de dados contendo:
Tabela itensIluminacao:
a. id (int);
b. nome (String);
c. Localização (String); d. Estado (booleano).
42
ATIVIDADE PROPOSTA
1. Deve ser efetuada a daily meeting e apresentar esse modelo de

banco de dados, e iniciar o desenvolvimento da primeira interface
gráfica (Figura 1).
Protótipo da tela de cadastro
43
ATIVIDADE PROPOSTA
Checklist:
Para verificar a tarefa se deve:
1. Verificar se todas as tarefas são derivadas das histórias de
usuário;
2. Existem apenas tarefas que levam a entrega que o cliente pediu;
3. Verificar se as interfaces gráficas e banco de dados contemplam
as descrições que os usuários colocam.
44
Obrigado!
Peter Koestenbaum
45
Bibliografia


Técnicas
46
😉 Email
✋👆👉👍👤👦👧👨👩👪💃🏃
💑❤😂😉😋😒😭👶😸🐟🍒
🍔💣📌📖🔨🎃🎈🎨🏈🏰🌏🔌

Slides Poo2 Unificados

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Slides Poo2 Unificados

Enviado por

Direitos autorais:

Formatos disponíveis

3.

1 FERRAMENTAS PARA PROGRAMAÇÃO EM

▸ Os testes em software são essenciais para que o produto

1. Defeito: implementação incorreta feita em uma aplicação.

Testes Unitários em Java

▸ Existem diversas categorias de testes, tais como de módulos,

▸ Umas das ferramentas utilizadas para realizar esse tipo de

▸ Vamos utilizar um exemplo para demonstrar a criação de

▸ Os testes unitários têm o objetivo de validar o funcionamento

▸ Para executar esses testes, é necessário que alguma

▸ Ao utilizar o NetBeans, é preciso criar um JUnit Test Case,

▸ Dentro da classe CalculadoraTeste temos quatro

▸ A marcação @Test se refere ao JUnit para afirmar que o

▸ O assertEquals(60, res);. O assert vem do inglês

Testes unitários: defesa contra os bugs

Documentação de código fonte com o

▸ O Javadoc é uma ferramenta produzida pela própria Oracle

▸ Essa documentação tem o objetivo de explicar a função de

Gerando a documentação pelo Javadoc

Exemplos de marcação do Javadoc

▸ A seguir exemplo da codificação para gerar o Javadoc.

▸ A seguir exemplo da codificação para gerar o Javadoc.

Sistema de controle de versão

▸ Existem diversos sistemas de controle de versão, tais como

Vamos sintetizar esse

▸ Com essa etapa dos estudos é possível avançar nas formas

▸ Introdução: Esse sistema possui diversos sensores e é

private ArrayList<Double> lstUmidade;

public double media(int amostra)

public double desvioPadrao(int amostra)

• Os testes unitários devem validar o método que calcula a média e o

Programação Orientada a Objetos com Java - 4ª Ed.

Programação Orientada A Objetos - Conceitos e

Bons estudo, muita dedicação e exclentes resultados.

▸ A maneira de desenvolvimento de software seguia uma

O modelo de cascata foi a primeira maneira de

1. Requisitos: levantar, entender e desenvolver as necessidades

Problemas do modelo castaca (STELLMAN, 2015):

▸ Devido às limitações que o modelo em cascata apresenta,

▸ Dois modelos relacionados a esse tipo de abordagem são o

▸ Todavia, as próprias metodologias apresentam limitações

▸ Ao final, mesmo com todo o aspecto incremental, as

▸ Diante desse cenário de diversas inconsistências, com o

1. Indivíduos e interações mais que processos e ferramentas.

▸ Esses quatro valores são permeados por 12 princípios que

O scrum é uma das diversas metodologias que usam conceitos

Visão geral das etapas do scrum

▸ O backlog, consiste em um conjunto de

O sprint backlog consiste em um conjunto de funcionalidades

Como usuário <tipo de usuário>, eu

▸ Desenvolvimento de sistema de automação residencial por uma

Imagine uma situação de uma empresa que está começando a utilizar o

▸ Agora é necessário organizar o sprint visando que o cliente gostaria

Utilizando como base a história de usuário, o aluno deve dividir todos

Como parte do desenvolvimento, os alunos devem simular 4 dias de

1. Deve ser efetuada a daily meeting e apresentar esse modelo de

Programação Orientada a Objetos com Java - 4ª Ed.

Programação Orientada A Objetos - Conceitos e

Bons estudo, muita dedicação e exclentes resultados.

▸ O armazenamento de dados estruturados é um dos pilares da

▸ Todavia, o dinamismo necessário na modelagem dos dados, o

▸ Os NoSQL são sistema de banco de dados que possuem

▸ O termo NoSQL se refere a “Not Only SQL”, ou seja, não apenas