DICA PARA CONCURSO

MÉTODO NISHIMURA:

1) Quando a questão explica sobre determinado assunto, geralmente, a assertiva é verdadeira;

2) Quando a questão impõe algo, geralmente, a assertiva é falsa;
3) Quando a questão compara duas tecnologias, geralmente, a assertiva é falsa;
4) Quando a questão "fala mal" "menospreza" determinada tecnologia, geralmente a assertiva é falsa;
5) Quando a questão enumera itens, se todos os itens pertencem ao mesmo grupo/programa, a assertiva é
verdadeira;
6) Se um dos itens, geralmente o último, não faz parte do grupo/programa, a assertiva é falsa;
7) Estas palavras indicam uma questão certa: pode(m), permite(m), é possível, pode ser...
8) Estas palavras indicam uma questão errada: automaticamente, deve. deve-se, só, somente, não permite, não
sendo possível, sempre, é necessário, necessariamente.

BLOCO 1:

1. Engenharia de Software.
Conceito Engenharia de Software:

 É uma disciplina que se ocupa de todos os aspectos da produção de software, desde os estágios iniciais de
especificação do sistema até a manutenção desse sistema, depois que ele entrou em operação. Seu
principal objetivo é fornecer uma estrutura metodológica para a construção de software com alta qualidade.
 Engenharia de software não se preocupa apenas com processos técnicos e também com outras atividades
tais como gerenciamento de projetos.
 Engenharia de Software está inserido no contexto de: das engenharias de sistemas, de processo e de
produto.
 Desenvolvimento de Hardware está fora do contexto da Engenharia de Software.
 A IEEE define engenharia de software como a aplicação de uma abordagem sistemática, disciplinada e
quantificável de desenvolvimento, operação e manutenção de software.
 meta principal é desenvolver sistemas de software com boa relação custo/benefício.
 Software não é apenas o programa, mas também todos os dados de documentação e configuração
associados, necessários para que o programa opere corretamente.
 De acordo com Pressman: “A Engenharia de Software ocorre como consequência de um processo chamado
Engenharia de Sistemas. Em vez de se concentrar somente no software, a engenharia de sistemas focaliza
diversos elementos, analisando, projetando, e os organizando em um sistema que pode ser um produto, um
serviço ou uma tecnologia para transformação da informação ou controle”.
 A Engenharia de Software tem por objetivos a aplicação de teoria, modelos, formalismos, técnicas e
ferramentas da ciência da computação e áreas afins para a desenvolvimento sistemático de software.
Associado ao desenvolvimento, é preciso também aplicar processos, métodos e ferramentas sendo que
a pedra fundamental que sustenta a engenharia de software é o foco na qualidade.

 A Engenharia de Software possui alguns princípios:

o Formalidade, em que o software deve ser desenvolvido de acordo com passos definidos com
precisão e seguidos de maneira efetiva;
o Abstração, preocupa-se com a identificação de um determinado fenômeno da realidade, sem se
preocupar com detalhes, considerando apenas os aspectos mais relevantes.
o Decomposição , em que se divide o problema em partes, de maneira que cada uma possa ser
resolvida de uma forma mais específica;
o Generalização, maneira usada para resolver um problema, de forma genérica, com o intuito de
reaproveitar essa solução em outras situações;
o Flexibilização é o processo que permite que o software possa ser alterado, sem causar problemas
para sua execução.
 A Engenharia de Software:
o não visa o desenvolvimento de teorias e fundamentações, preocupando-se unicamente com as
práticas de desenvolvimento de software
o tem como foco o tratamento dos aspectos de desenvolvimento de software, abstraindo-se dos
sistemas baseados em computadores, incluindo hardware e software.
o tem como métodos as abordagens estruturadas para o desenvolvimento de software que incluem
os modelos de software, notações, regras e maneiras de desenvolvimento.
 Diferença Engenharia de Software x Ciencia da Computação:
 o A Ciência da Computação tem como objetivo de estudo/desenvolvimento de teorias e
fundamentações. Já a Engenharia de Software se preocupa com as práticas de desenvolvimento
de software.

1.1 Modelos de ciclo de vida de software.

 Modelo de ciclo de vida de software é uma representação que descreve todas as atividades que tratam da
criação de um produto de software.
 Um modelo de ciclo de vida, geralmente, organiza as macro-atividades básicas do processo, estabelecendo
precedência e dependência entre as mesmas.
 Refere às fases pelas quais um sistema de software atravessa desde sua concepção até sua retirada de
produção.
 O Modelo de Ciclo de Vida de Software trata das fases pelas quais um software passa desde o seu início até
o seu fim e como essas fases se relacionam através de processos: processo de software pode ser visto
como o conjunto de atividades, métodos, práticas e transformações que guiam pessoas na produção de
software
 Modelo de Ciclo de Vida como sinônimo de Modelo de Processo! Trata-se exatamente do mesmo conceito
de Modelo de Ciclo de Vida. Ele é uma representação abstrata de um processo de software.
 Um processo de software não pode ser definido de forma universal. Para ser eficaz e conduzir à construção
de produtos de boa qualidade, um processo deve ser adequado às especificidades do projeto em questão.
Deste modo, processos devem ser definidos caso a caso, considerando-se diversos aspectos específicos do
projeto em questão, tais como:
o Características da aplicação (domínio do problema, tamanho do software, tipo e complexidade,
etc);
o Tecnologia a ser adotada na sua construção (paradigma de desenvolvimento, linguagem de
programação, mecanismo de persistência, etc);
o Organização onde o produto será desenvolvido e a equipe de desenvolvimento alocada (recursos
humanos).
 Segundo Modelo de Ian Sommerville, um ciclo de vida de software contém 4 fases:

 Especificação de Software;
 Desenvolvimento de Software (Projeto e Implementação);
 Validação de Software; e
 Evolução de Software.

 Um modelo de processo de software ou modelo de ciclo de vida trata

da representação abstrata/simplificada (e não COMPLEXA) de um
processo de software, apresentada a partir de uma perspectiva genérica.

1.2 Metodologias de desenvolvimento de software.

 Conhecido também como (também chamada de Processo de Desenvolvimento de Software).

 É uma caracterização prescritiva ou descritiva de como um produto de software deve ser desenvolvido,
i.e., define o quê, como e quando fazer algo – um exemplo clássico é o RUP!

 Os principais modelos podem ser agrupados em três categorias:

 o Modelos sequenciais:
 Organizam o processo em uma sequência linear de fases.
 Exemplos: Modelo em cascata (Royce,1970) e Modelo em V(V-Model)
 Tamanho do sistema e controle de versão impossibilita a adoção de um modelo
sequencial. Sugestão: Modelo incremental é indicado.
o Modelos incrementais:
 o sistema é dividido em subsistemas ou módulos, tomando por base a funcionalidade.
Os incrementos (ou versões) são definidos, começando com um pequeno subsistema
funcional que, a cada ciclo, é acrescido de novas funcionalidades.
 Necessário definição das versões antes do desenvolvimento da primeira versão.
 Exemplos: RUP(Rational Unified Process) , RAD (Rapid Application Development) e
Metodologias Ágeis (Scrum,XP,TDD.
o Modelos evolutivos:
 Enquanto modelos incrementais têm por base a entrega de versões operacionais desde
o primeiro ciclo, modelos evolutivos não têm essa preocupação.
 o que ocorre na maioria das vezes é que os primeiros ciclos produzem protótipos ou até
mesmo apenas modelos. À medida que o desenvolvimento avança e os requisitos vão
ficando mais claros e estáveis, protótipos vão dando lugar a versões operacionais, até
que o sistema completo seja construído.
 É o modelo mais adaptável a mudanças por se utilizar de iterações.
 A avaliação ou o uso do protótipo/sistema pode aumentar o conhecimento sobre o
produto e melhorar o entendimento que se tem acerca dos requisitos. Entretanto, é
necessária uma forte gerência do projeto e de configuração.

 Modelo em Cascata (Modelos Sequenciais)

o Conhecido como clássico, sequencial linear, Waterfall, Rígido, Monolítico.
o É o mais antigo dos modelos sequenciais.
o Segue uma abordagem sistemática para o desenvolvimento de software, com forte ênfase em
documentação
o Oferece encadeamento simples de uma fase com a outra.
o Uma fase só se inicia após o término e aprovação da fase anterior
o É apropriado para quando os requisitos já estão bem definidos e compreendidos.
o Não reage bem a mudanças de requisitos e incertezas de projeto – Pouco adaptável
o Atrasa a redução de riscos que só são descobertas no final do processo – em geral na fase de
testes
o Percebam que erros nas fases iniciais possuem custos de correção mais altos. Logo, o maior custo
está na fase de requisitos que é a fase inicial!

1.3 Arquitetura de software.

A arquitetura de software de um sistema consiste na definição dos componentes de software, suas propriedades
externas, e seus relacionamentos com outros softwares. O termo também se refere à documentação da arquitetura
de software do sistema. A documentação da arquitetura do software facilita: a comunicação entre os stakeholders,
registra as decisões iniciais acerca do projeto de alto-nível, e permite o reúso do projeto dos componentes e padrões
entre projetos.

As Linguagens de descrição de arquitetura (LDAs) são usadas para descrever a arquitetura de software. Várias
LDAs distintas foram desenvolvidas por diferentes organizações, incluindo Wright (desenvolvido por Carnegie Mellon),
Acme (desenvolvido por Carnegie Mellon), xADL (desenvolvido por UCI), Darwin (desenvolvido por Imperial College
London), DAOP-ADL (desenvolvido pela University of Málaga).

Elementos comuns de uma LDA são componentes, conexão e configuração.

A arquitetura de software é normalmente organizada em visões, as quais são análogas aos diferentes tipos de plantas
utilizadas no estabelecimento da arquitetura:

Algumas possíveis visões são:

 Visão funcional/lógica
 Visão de código.
 Visão de desenvolvimento/estrutural
 Visão de concorrência/processo/thread
 Visão física/evolutiva
 Visão de ação do usuário/retorno

Os principais tipos de arquitetura de software são:

 Layers (camadas): Os módulos e componentes do software são organizados em camadas de

funcionalidades, que podem ser desconstruídas em diferentes serviços. Este padrão é mais usado em
programas de e-commerce.
  Client-server (cliente-servidor): Neste modelo arquitetural, o processamento da informação se divide em
módulos e processos distintos. Um deles é responsável pela manutenção da informação e o outro pela
obtenção de dados. Este tipo de arquitetura de software é bastante usado em aplicativos de bancos e e-
mail.
 Model-view-controller (MVC): O padrão MVC separa o projeto do software em três camadas
independentes: o modelo (manipulação da lógica de dados), a visão (a interface do usuário) e o controlador
(fluxo de aplicação). Esta separação facilita a manutenção do código, que pode ser reutilizado em outros
projetos. O modelo de arquitetura modelo-visão-controlador (MVC) é responsável por encapsular as
funcionalidades e os objetos de conteúdo.  
 Microservices (microsserviços): O padrão se baseia em múltiplos serviços e componentes para
desenvolver uma estrutura modular. É o modelo preferido dos desenvolvedores e arquitetos de software,
por permitir escalabilidade e independência dos módulos, que podem usar diferentes linguagens.
 Pipes-and-filters (PF): Baseada em uma arquitetura linear, o padrão Pipe-and-filter usa os componentes
computacionais como filtros, que recebem uma entrada, transformam-na a partir de um ou mais algoritmos
e geram uma saída para um canal de comunicação. Alguns exemplos deste tipo de arquitetura de software
são o Sheel do Linux e os reprodutores de vídeo em diferentes formatos.
 Peer-to-Peer (P2P): Se você já baixou algum arquivo via torrent, se deparou com este padrão arquiteturall.
No Peer-to-Peer, todos os pares são clientes e servidores, ou seja, cada computador é um provedor de
serviços independente de um servidor central.
 Service-Oriented Architecture (SOA): O SOA facilita a operação das grandes empresas, pois auxilia na
criação do processo de encontrar, definir e gerenciar os serviços disponibilizados. O NuBank e a Amazon
são exemplos de corporações que utilizam este modelo arquitetural.
 Publish-Subscribe (Pub/Sub): Principal padrão arquitetural de redes sociais como Instagram e do Spotify,
o modelo Publish-Subscribe conecta publicadores (publishers) e assinantes (subscribers). Os publishers
enviam mensagens aos subscribers, que são notificados sempre que um novo conteúdo é disponibilizado.

A construção de um software é precedida pelo seu design (projeto). O design de software inclui arquitetura de software
e não inclui gerenciamento de projeto.

1.4 Conceitos e técnicas do projeto de software.

https://pt.wikipedia.org/wiki/Padr%C3%A3o_de_projeto_de_software

1.5 Processos e práticas de desenvolvimento de software.

1.6 Processo interativo e incremental.

 Ciclo de vida incremental / Incremental Life Cycle. Ciclo de vida do projeto em que o escopo
do projeto é geralmente determinado no início do ciclo de vida do mesmo, e as estimativas de
tempo e custos são rotineiramente modificadas à proporção que a compreensão do produto pela
equipe do projeto aumenta. As iterações desenvolvem o produto através de uma série de ciclos
repetidos, enquanto os incrementos sucessivamente acrescentam à funcionalidade do produto.
 Ciclo de vida iterativo / Iterative Life Cycle. Ciclo de vida do projeto em que o escopo do
projeto é geralmente determinado no início do ciclo de vida do mesmo, mas as estimativas de
tempo e custos são rotineiramente modificadas à proporção que a compreensão do produto pela
equipe do projeto aumenta. Iterações desenvolvem o produto através de uma série de ciclos
repetidos, enquanto os incrementos sucessivamente acrescentam à funcionalidade do produto.
 Ciclo de vida preditivo / Predictive Life Cycle. Uma forma de ciclo de vida do projeto em que o
escopo do projeto, bem como o tempo e custos exigidos para entregar tal escopo são
determinados o mais cedo possível no seu ciclo de vida.

1.7 Práticas ágeis de desenvolvimento de software.

 SCRUM
o Scrum é um framework leve que ajuda pessoas, times e organizações a gerar valor por meio de soluções
adaptativas para problemas complexos.

o Em suma, Scrum requer um Scrum Master para promover um ambiente onde:

o 1. Um Product Owner ordena o trabalho para um problema complexo em um Product Backlog.
o 2. O Scrum Team transforma uma seleção do trabalho em um incremento de valor durante um
Sprint.
o 3. O Scrum Team e seus stakeholders inspecionam os resultados e se ajustam para o próximo
Sprint.
o 4. Repita
o Os cinco valores do Scrum:
o Compromisso: O Scrum Team se compromete a atingir seus objetivos e suportar uns aos outros
 o Foco: Seu foco principal é o trabalho da Sprint para fazer o melhor progresso possível em direção
a essas metas.
o Abertura: O Scrum Team e seus stakeholders são abertos quanto ao trabalho e os desafios
o Respeito: Os membros do Scrum Team se respeitam quanto a serem pessoas capazes e
independentes, e são respeitados como tal pelas pessoas com quem trabalham.
o Coragem: Os membros do Scrum Team têm a coragem de, fazer a coisa certa e trabalhar em
problemas difíceis
o Scrum Team
o A unidade fundamental do Scrum é um pequeno time de pessoas (normalmente 10 ou menos
pessoas) pois, times menores se comunicam melhor e são mais produtivos.
o O Scrum Team consiste em um Scrum Master, um Product owner e Developers.
o Dentro de um Scrum Team, não há sub-times ou hierarquias. É uma unidade coesa de
profissionais focados em um objetivo de cada vez, a Meta do Produto.
o Os Scrum Teams são multifuncionais, o que significa que os membros possuem todas as
habilidades necessárias para criar valor a cada Sprint. Eles também são autogerenciáveis, o que
significa que decidem internamente quem faz o quê, como e no que trabalhar !
o O Scrum Team é responsável por todas as atividades relacionadas ao produto, desde a
colaboração com stakeholder, verificação, manutenção, operação, experimentação, pesquisa e
desenvolvimento, e qualquer outra coisa que possa ser necessária. Eles são estruturados e
empoderados pela organização para gerenciar seu próprio trabalho. Trabalhar em Sprints em um
ritmo sustentável melhora o foco é a consistência do Scrum Team.
o Scrum define três responsabilidades específicas dentro do Scrum Team:
 Developers:
 pessoas do Scrum Team que estão comprometidas em criar qualquer aspecto
de um Incremento utilizável a cada Sprint.
 São responsáveis por:
o Criar um plano para a Sprint chamado Sprint Backlog; Inclusive o
próprio Sprint Backlog
o Introduzir gradualmente qualidade aderindo a uma Definition of
Done;
o Adaptar seu plano a cada dia em direção à meta da Sprint; e,
o Responsabilizar-se mutuamente como profissionais.
 Product Owner:
 é responsável por maximizar o valor do produto resultante do trabalho do
Scrum Team.
 é responsável pelo gerenciamento eficaz do Product Backlog que inclui:
o Desenvolver e comunicar explicitamente a meta do produto;
o Criar e comunicar claramente os itens do Product Backlog;
o Ordenar os itens do Product Backlog; e,
o Garantir que o Product Backlog seja transparente, visível e
compreensível.
 O Product Owner pode fazer o trabalho acima ou pode delegar a
responsabilidade a outros. Independentemente disso, o Product Owner ainda é
o responsável.
 Toda a organização deve respeitar suas decisões. Essas decisões são visíveis
no conteúdo e na ordem do Product Backlog e por meio do incremento
inspecionável na revisão da sprint.
 O Product Owner é uma pessoa, não um comitê. O Product Owner pode
representar as necessidades de muitos stakeholders no Product Backlog.
Aqueles que desejam alterar o Product Backlog podem fazê-lo tentando
convencer o Product Owner.
 Apenas o Product Owner tem autoridade para cancelar a Sprint.
 Scrum Master:
 é responsável por estabelecer o Scrum na organização ajudando todos a
entender a teoria e prática do Scrum
 é responsável pela eficácia do Scrum Team
 São verdadeiros líderes que servem ao Scrum Team e à organização como
um todo.
 Scrum Master serve ao Scrum Team:
o Treinar os membros do time em autogerenciamento e cross-
funcionalidade;
o Ajudar o Scrum Team a se concentrar na criação de incrementos de
alto valor que atendem à Definition of Done (qualidade);
o Provocando a remoção de impedimentos ao progresso do Scrum
Team; e,
o Garantir que todos os eventos Scrum ocorram e sejam positivos,
produtivos e mantidos dentro do Timebox.
 Scrum Master serve o Product Owner:
 o Ajudar a encontrar técnicas para a definição eficaz de meta do
Produto e gerenciamento do Product Backlog;
o Ajudar o Scrum Team a entender a necessidade de itens do Product
Backlog claros e concisos;
o Ajudar a estabelecer o planejamento empírico do produto para um
ambiente complexo; e,
o Facilitar a colaboração dos stakeholder, conforme solicitado ou
necessário.
 O Scrum Master serve a organização de várias maneiras:
o Liderar, treinar e orientar a organização na adoção do Scrum;
o Planejar e aconselhar implementações de Scrum dentro da
organização;
o Ajudar os funcionários e os stakeholders a compreender e aplicar
uma abordagem empírica para trabalhos complexos; e,
o Remover barreiras entre stakeholders e Scrum Teams.
o EVENTOS SCRUM:
 Sprint é um contêiner para todos os outros eventos
 Cada evento no Scrum é uma oportunidade formal para inspecionar e adaptar os
artefatos do Scrum.
 Os eventos são usados no Scrum para criar regularidade e minimizar a necessidade de
reuniões não definidas no Scrum
 O ideal é que todos os eventos sejam realizados no mesmo horário e local para reduzir a
complexidade
 Sprint
 Sprints são o coração do Scrum, onde ideias são transformadas em valor
 São eventos de duração fixa de um mês ou menos para criar consistência.
 Uma nova Sprint começa imediatamente após a conclusão da Sprint anterior.
 Todo o trabalho necessário para atingir a meta do Produto, incluindo Sprint
Planning, Daily Scrums, Sprint Review e Sprint Retrospective, acontece dentro
de Sprints.

 Durante a Sprint:
 Nenhuma mudança é feita que coloque em risco a meta da Sprint;
 A qualidade não diminui;
 O Product Backlog é refinado conforme necessário; e,
 O escopo pode ser esclarecido e renegociado com o Product Owner conforme
mais é aprendido.
 Sprints permitem previsibilidade, garantindo a inspeção e adaptação do
progresso em direção a uma meta do Produto ao menos uma vez por mês.
Cada Sprint pode ser considerado um projeto curto.
 Existem várias práticas para prever o progresso: como
o burn-downs: torna visível a evolução diária do trabalho da equipe de
desenvolvimento. No gráfico o eixo x (horizontal) representa o
tamanho da Sprint em dias e o eixo y (vertical) a quantidade de
tarefas. É uma representação gráfica do trabalho a ser feito versus
tempo. Mostra o desenvolvimento planejado e o desenvolvimento
ideal.
o burn-ups: Mesma coisa que burn dows pois, este exibe o que a
equipe já desempenhou até o momento. ou
o cumulative flows.
 Uma Sprint pode ser cancelada se a Meta da Sprint se tornar obsoleta.
 Apenas o Product Owner tem autoridade para cancelar a Sprint.
 Tipos de eventos SCRUM:
 Sprint Planning:
o Três tópicos: “O que”, “Como” e “Por que”
o inicia a Sprint ao definir o trabalho a ser realizado na Sprint.
o A Sprint Planning tem um Timebox definido com duração máxima de
de oito horas para uma Sprint de um mês. Para Sprints mais curtas,
o evento geralmente é mais curto.
o Este plano resultante é criado pelo trabalho colaborativo de todo o
Scrum Team.
o O Product Owner garante que os participantes estejam preparados
para discutir os itens mais importantes do Product Backlog e como
eles são mapeados para a Meta do Produto (A meta da Sprint
deve ser finalizada antes do final da Sprint Planning.). O Scrum
Team também pode convidar outras pessoas para participar da
Sprint Planning para fornecer conselhos.
o O Product Owner propõe como o produto pode aumentar seu valor e
utilidade no Sprint atual.
 o os Developers selecionam itens do Product Backlog para incluir na
Sprint atual. O Scrum Team pode refinar esses itens durante este
processo, o que aumenta a compreensão e a confiança.
o Para cada item do Product Backlog selecionado, os Developers
planejam o trabalho necessário para criar um Incremento que atenda
à Definition of Done (decompondo itens do Product Backlog em itens
de trabalho menores de um dia ou menos. A forma como isso é feito
fica a critério exclusivo dos Developers .)
o Sprint Backlog: Contém:
 Meta da Sprint,
 Itens do Product Backlog selecionados para a Sprint,
 Mais o plano para entregá-los
 Daily Scrum:
o O propósito da Daily Scrum é inspecionar o progresso em direção a
Meta da Sprint e adaptar o Sprint Backlog conforme necessário,
ajustando o próximo trabalho planejado.
o é um evento de 15 minutos para os Developers do Scrum Team
o é realizado no mesmo horário e local, todos os dias úteis da Sprint.
Se o Product Owner ou o Scrum Master estão trabalhando
ativamente nos itens do Sprint Backlog, eles participam como
Developers.
o Os Developers podem selecionar qualquer estrutura e técnicas que
quiserem, desde que seu Daily Scrum se concentre no progresso
em direção a Meta da Sprint e produza um plano de ação para o
próximo dia de trabalho. Isso cria foco e melhora o
autogerenciamento
o melhoram as comunicações, identificam os impedimentos,
promovem a rápida tomada de decisões e consequentemente,
eliminam a necessidade de outras reuniões.
o A Daily Scrum não é o único momento em que os Developers
podem ajustar seu plano. Eles costumam se reunir ao longo do dia
para discussões mais detalhadas sobre a adaptação ou
replanejamento do resto do trabalho da Sprint.
 Sprint Review:
o O propósito da Sprint Review é inspecionar o resultado da Sprint e
determinar as adaptações futuras.
o O Scrum Team apresenta os resultados de seu trabalho para os
principais stakeholders e o progresso em direção a Meta do
Produto é discutido.
o Durante o evento, o Scrum Team e os stakeholders revisam o que
foi realizado na Sprint e o que mudou em seu ambiente. O Product
Backlog também pode ser ajustado para atender a novas
oportunidades. A Sprint Review é uma sessão de trabalho e o Scrum
Team deve evitar limitá-la a uma apresentação.
o A Sprint Review é o penúltimo evento da Sprint e tem um Timebox
com prazo máximo de quatro horas para uma Sprint de um mês.
Para Sprints mais curtas, o evento geralmente é mais curto.
 Sprint Retrospective:
o é planejar maneiras de aumentar a qualidade e a eficácia.
o Scrum Team inspeciona como foi a última Sprint em relação a
indivíduos, interações, processos, ferramentas e sua Definition of
Done.
o As suposições que os desviaram são identificadas e suas origens
exploradas. O Scrum Team discute o que deu certo durante a Sprint,
quais problemas encontraram e como esses problemas foram (ou
não) resolvidos.
o As mudanças detectadas como impactantes podem até ser
adicionadas ao Sprint Backlog para a próxima Sprint.
o A Sprint Retrospective conclui a Sprint. É limitada pelo Timebox de
no máximo três horas para uma Sprint de um mês. Para Sprints
mais curtas, o evento geralmente é mais curto.
o ARTEFATOS SCRUM:
 representam trabalho ou valor
 Eles são projetados para maximizar a transparência das principais informações.
 Compromisso de cada artefato:
 Para o Product Backlog, é a Meta do produto:
o Descreve um estado futuro do produto que pode servir como um
alvo para o Scrum Team planejar.
 o é o objetivo de longo prazo para o Scrum Team. Eles devem cumprir
(ou abandonar) um objetivo antes de assumir o próximo.
 Para o Sprint Backlog, é a Meta da Sprint.
o Embora a Meta da Sprint seja um compromisso dos Developers,
esta fornece flexibilidade em termos do trabalho exato necessário
para alcançá-la.
o A Meta da Sprint é criada durante o evento Sprint Planning e então
adicionada ao Sprint Backlog.
o Conforme os Developers trabalham durante a Sprint, eles mantêm a
Meta da Sprint em mente. Se o trabalho acabar sendo diferente do
que eles esperavam, eles colaboram com o Product Owner para
negociar o escopo do Sprint Backlog dentro da Sprint sem afetar a
Meta da Sprint.
 Para o incremento, é a “Definition of Done”:
o é um trampolim concreto em direção a Meta do produto.
o Cada incremento é adicionado a todos os incrementos anteriores e
completamente verificado, garantindo que todos os incrementos
funcionem juntos. A fim de fornecer valor, o incremento deve ser
utilizável.
o Vários incrementos podem ser criados em uma Sprint. A soma dos
incrementos é apresentada na Sprint Review, apoiando assim o
empirismo.
o No entanto, um incremento pode ser entregue aos stakeholders
antes do final da Sprint. A Sprint Review nunca deve ser
considerada um marco para liberar valor.
o O trabalho não pode ser considerado parte de um incremento a
menos que atenda o Definition of Done.
 Tipos de artefatos:
 Product Backlog:
o é uma lista ordenada e emergente de melhoria de produto
o É a única fonte de trabalho realizado pelo Scrum Team.
o Somente itens do Product Backlog são preparados para uso no
evento Sprint Planning.
o Product Backlog refinement é o ato de quebrar e incluir definição
adicional aos itens do Product Backlog para ter itens menores e
mais precisos.
o Esta é uma atividade contínua para adicionar detalhes, como
descrição, ordem e tamanho. Os atributos geralmente variam de
acordo com o domínio de trabalho.
o Os Developers que farão o trabalho são responsáveis pelo
dimensionamento. O Product Owner pode influenciar os Developers,
ajudando-os a entender e selecionar trade-offs (trocas de itens).
 Definition of Done:
o é uma descrição formal do estado do Incremento quando ela atende
às medidas de qualidade exigidas para o produto.
o um item do Product Backlog atende a Definition of Done, um
incremento nasce.
o cria transparência ao fornecer a todos um entendimento
compartilhado de qual trabalho foi concluído como parte do
Incremento. Se um item do Product Backlog não atender à Definição
de Pronto, ele não poderá ser liberado ou mesmo apresentado na
Sprint Review. Em vez disso, ele retorna ao Product Backlog para
consideração futura.
o Se a Definição de Pronto para um incremento faz parte dos padrões
da organização, todos os Scrum Teams devem segui-la como
mínimo. Se não for um padrão organizacional, o Scrum Team deve
criar uma Definição de Pronto apropriada para o produto.
o Os Developers devem estar em conformidade com a Definição de
Pronto. Se houver vários Scrum Teams trabalhando juntos em um
produto, eles devem definir e cumprir mutuamente a mesma
Definição de Pronto.

QUESTOES CESPE:

Em uma abordagem ágil, no início da iteração, determina-se a quantidade de itens mais prioritários da lista de
backlog que podem ser entregues na próxima iteração; os processos coletar os requisitos, definir o escopo e criar a
estrutura analítica do projeto (EAP) são executados em cada uma dessas iterações. (CERTO)

O SCRUM é composto por quatro atividades: planeamento, projeto, codificação e testes, as quais normalmente são
repetidas iteração a iteração. (ERRADO) É O XP

Na metodologia Scrum, é feita na sprint planning a seleção dos itens do backlog que serão desenvolvidos durante a
sprint; depois de fechado o seu escopo, a sprint não poderá mais ser alterada. (CERTO) Durante a Sprint não são
feitas mudanças que podem afetar o objetivo da Sprint.

O responsável direto pelo backlog da sprint é o time de desenvolvimento, que decide sobre as adições e(ou)
remoções e os ajustes de tarefas durante a execução da sprint; no entanto, se algum item for retirado, o dono do
produto deve ser avisado o mais breve possível.  (CERTO)
O Time de Desenvolvimento que é o responsável pelo Backlog da Sprint, apesar do Time de Desenvolvimento ter
autonomia para alterar o Backlog da Sprint ao longo de toda Sprint, é proibido realizar mudanças que afetem sua
meta. A Sprint só pode ser cancelada pelo Product Owner (caso o objetivo se torne obsoleto).

O Product Owner também é o único que pode gerenciar o Product Backlog e o único que pode cancelar uma Sprint.
Ele pode priorizar os itens do Product Backlog também.

Já o Scrum Master tem a sua função mais ligada a garantir que o Scrum seja entendido e aplicado por todos.
Apenas orienta o Product Owner, remove os impedimentos e utiliza técnicas de facilitação e de coaching. Ele não
interfere nos itens do produto (nem no Backlog da Sprint, muito menos no Product Backlog). E um Scrum Master
jamais pode ser o Product Owner ao mesmo tempo.
Um dos artefatos do Scrum, o backlog do produto é gerenciado, exclusivamente, pelo dono do produto e representa
o conteúdo, a disponibilidade e a ordenação do trabalho a ser realizado, sendo a única porta de entrada para todos
os registros de requisitos de mudança a serem realizados no produto.(CERTO)

As histórias são consideradas pequenos requisitos de um projeto na perspectiva do usuário final. (CERTO) No

Scrum, o backlog contém uma lista de requisitos de produtos e de negócio, descritos na forma de Estória de
Usuário: Histórias de usuários são requisitos pequenos ou solicitações escritas da perspectiva de um usuário final.

Pequenas partes do trabalho com a perspectiva do patrocinador são artefatos denominados Epics. (ERRADO) Nas
fases iniciais as Estórias de Usuário são em alto nível. Eles são chamadas de Épicos. Esse Épicos são grande e
acabam sendo divididos em estórias de usuário menores. As histórias de usuário, como nome sugere, tem a
perspectiva do usuário/cliente e não do patrocinador.

O scrum master possui autoridade para cancelar uma sprint antes de o time-boxed da sprint terminar. (ERRADO)

SCRUM que consiste de um framework para desenvolver e manter produtos complexos, utiliza-se uma abordagem
iterativa e incremental para aperfeiçoar o controle de riscos. (CERTO)

Entre os processos da gestão de projetos com Scrum, as inspeções constituem os processos mais complexos e
formais e, por isso, ocorrem somente ao fim de um ciclo de várias sprints, após a liberação de uma funcionalidade
plena e o seu reconhecimento pelo demandante.(ERRADO) a inspeção é utilizada nas reuniões diárias que
acontecem todos os dias durante o ciclo da uma sprint, portanto a inspeção não ocorre somente ao fim de um ciclo

No método Scrum, ao final de cada período de duas a quatro semanas de um Sprint backlog, pode-se planejar uma
entrega periódica ao cliente. (ERRADO)
No método Scrum, pode-se planejar uma entrega periódica ao cliente ao final de cada período de duas a quatro
semanas de um Sprint (E não Sprint Backlog).O planejamento é no início do Sprint, a entrega ao final.
Sprint: O coração do Scrum é a Sprint, um time-boxed de um mês ou menos, durante o qual um “Pronto”, versão
incremental potencialmente utilizável do produto, é criado. Sprints tem durações coerentes em todo o esforço de
desenvolvimento.
No Scrum, o product backlog é uma lista que contém todos os requisitos não funcionais para um software, criada
com o uso de ponto de função.(ERRADO)

Conforme o Scrum, a equipe de desenvolvimento é responsável por determinar o tamanho do trabalho suficiente
para ser entregue na próxima Sprint durante a reunião de planejamento da Sprint. (CERTO)
A sprint não começa depois de acaba o Sprint Planning, e sim junto com o Sprint Planning.
"Scrum combina quatro eventos formais ... contidos dentro de um evento, a Sprint"
"todo o trabalho necessário para atingir a meta do produto, incluindo o Sprint Planning, .... , acontece DENTRO de
Sprints"

São exemplos de práticas ágeis: ciclos curtos; simplicidade; retrospectivas regulares; ambiente de trabalho centrado
no indivíduo; P.O. (Project Owner) que receba e retenha informações; e entrega de produto de software somente no
final de cada fase. (ERRADO) Certo é centrado no cliente

No Scrum, o requisito IV é atendido pela retrospectiva da sprint, que possui como objetivo principal revisar o burn-
down (esta parte está certa). No PMBOK 5, esse requisito é atendido pela técnica Delphi, que coleta informações do
andamento do cronograma e traça o gráfico de esforço por produtividade. (ERRADO) pois SPRINT
RETROSPECTIVE É FOCADA NO PROCESSO e SPRINT REVIEW É FOCADA NO PRODUTO. Técnica Delphi é
uma maneira de obter um consenso de especialistas. Os especialistas em riscos do projeto participam
anonimamente nessa técnica. O facilitador usa um questionário para solicitar ideias sobre riscos importantes do
projeto. As respostas são resumidas e redistribuídas aos especialistas para comentários adicionais. O consenso
pode ser obtido após algumas rodadas desse processo. A técnica Delphi ajuda a reduzir a parcialidade nos dados e
evita que alguém possa influenciar indevidamente o resultado.

Em um desenvolvimento ágil sob a metodologia Scrum, deve-se fazer uma reunião diária, chamada daily Scrum,
que terá a finalidade de resolver os problemas que forem identificados e não solucionados no dia de trabalho
 anterior. (ERRADO) pois Daily Meetings or Daily Scrum: As reuniões diárias são reuniões rápidas, de
aproximadamente 10 a 15 minutos, dependendo do tamanho da equipe, onde os participantes a realizam de pé. O
objetivo desta é explanar para o restante do time o que foi feito no dia anterior e o que pretende-se fazer no dia
atual, bem como a existência de quaisquer impedimentos no desenvolvimento.
1 - o que foi feito no dia anterior
2 - pretende-se fazer no dia atual
3 - quais impedimentos no desenvolvimento
O Daily Scrum não deve ser usado como uma reunião para resolução de problemas. Questões levantadas devem
ser levadas para fora da reunião e normalmente tratadas por um grupo menor de pessoas que tenham a ver
diretamente com o problema ou possam contribuir para solucioná-lo. Durante o Daily Scrum, cada membro da
equipe provê respostas para cada uma destas três perguntas:
 Extreme Programming XP
o é uma metodologia focada no desenvolvimento de software que possui valores e princípios, onde são
fundamentados por um conjunto de práticas.
o É uma metodologia leve que pode facilmente ser adotada por diferentes níveis de desenvolvedores
(experientes ou não) e em qualquer tamanho de equipe. É uma excelente metodologia por se adaptar a
requisitos que às vezes podem mudar rapidamente.
o O XP pode ser utilizado de forma complementar ao Scrum, pois ele acaba focando mais em processos
de engenharia e desenvolvimento de software.
o O framework XP é aplicável quando:
 A equipe é pequena, não superior a 12 pessoas;
 Prevê riscos causados por projetos de tempo fixo com a utilização de novas tecnologias;
 Projetos de pesquisa que prevêem mudanças constantes;
 A tecnologia que os desenvolvedores estão usando permite testes automatizados de
unidades e funcionalidades;
 Tem alteração dinâmica dos requisitos do software e escopo.
o Scrum VS XP
 Entre as várias metodologias ágeis, o Scrum vs XP vão apresentar diversas semelhanças,
como o ênfase em trabalho em equipe, mas a principal diferença é que enquanto o Extreme
Programming está muito mais focado e apropriado para as peculiaridades da área de
software, o Scrum pode ser aplicado em qualquer setor.
o XP abrange 5 valores. Para trabalhar com rapidez e eficiência, a metodologia ágil XP é baseada em
cinco valores para que os envolvidos no projeto se sintam confiantes na direção que o projeto estará
tomando:
 Simplicidade: O Extreme Programming vai dividir a etapa principal em metas menores,
totalmente realizáveis pela equipe desenvolvedora, que cumpre apenas exatamente o que foi
solicitado para maximizar o valor criado na etapa.
 Comunicação: Todos envolvidos no desenvolvimento, que trabalham juntos, de requisitos à
implementação de códigos, devem se comunicar diariamente, durante reuniões stand-up,
para atualização de status e resolução de problemas de forma imediata. A comunicação é
obrigatória para que não haja lacunas em processos e problemas entre equipe, cliente e
fornecedor;
 Coragem: Não há nada a temer com as mudanças de requisitos durante a execução do
software, especialmente porque todos trabalham juntos. Por isso, é preciso sempre dizer a
verdade sobre estimativas e progresso no desenvolvimento. Cada membro da equipe deve
assumir a responsabilidade pela sua parte de forma corajosa, com uma “ação efetiva diante
do medo”, conforme previu o próprio criador do XP, Kent Beck.
 Respeito: Nas equipes dessa metodologia ágil o respeito é ponto fundamental para que a
comunicação seja boa, o que vai promover melhor fornecimento de feedbacks e aceitação
deles, especialmente quando houver necessidade de promover mudanças.
 Feedback: As equipes do Extreme Programming devem se adaptar de acordo com as
necessidades do cliente e do projeto, por isso, os feedbacks são tão importantes. Também
pela mesma razão, os desenvolvedores precisam apresentar o software com frequência e
antecedência para promover alterações necessárias.
o O XP entrega conceitos bem semelhantes em relação às outras metodologias, como:
 Abordagem incremental;
 Encorajamento de comunicação face a face;
 Feedback constante.
o Mas também conta com procedimentos exclusivos da metodologia, como a orientação para boas
práticas de engenharia de software e a utilização do Pair Programming. Esses dois pontos citados
acima são o que determinam que o Extreme Programming foi desenvolvido para times de
desenvolvimento de software
o Não é possível replicar suas práticas em diversas áreas como vemos acontecer com o Scrum ou o
Kanban.
o Proibido fazer horas extras !
o Principal caratceristica da XP: Cliente sempre presente ! E nada de um equipe técnica especializada ou
outras artimanhas.
o User Stories são partes do comportamento desejado de um software. São usadas para dividir uma
grande quantidade de funcionalidades em partes menores de forma a auxiliar no planejamento. Em
resumo, cada história de usuário ataca só uma parte do escopo, uma funcionalidade, por exemplo.
o As boas práticas do XP:
 O cliente sempre disponível (The Customer is Always Available): Constante
disponibilidade do cliente para colaborar em dúvidas, alterações, e prioridades em um
escopo, ou seja, dando um dinamismo ativo ao projeto.
 Metaphor (Uso de metáforas no projeto): Visando facilitar a comunicação da equipe, caso
seja possível, é estabelecido o uso de metáforas em pontos chaves ao projeto como, por
exemplo, a definição de um nome que seja comum à equipe e simbolize algo de fácil
assimilação como, por exemplo: "Vamos chamar nosso projeto de "cartão de ponto", para um
sistema que gerencie as batidas de ponto de funcionários, gerando o provisionamento
financeiro e mensal para módulo de folha de pagamento".
 Planning Game (Planejando o jogo): Entre o cliente e os técnicos são estimuladas reuniões
usando quadros brancos, com o objetivo de captar e definir as "user stories" (estórias, que
são textos claros ou diagramas com notação UML com as especificações de regras de
negócios inerentes ao sistema) e também para poder estimar o tempo ideal das interações, o
projeto como um todo, elaborar estratégias e tentar prever as contingências para projeto.
Essa prática é fundamental para elaborar a estratégia das interações, que é a forma como se
trabalha o "cronograma" de um projeto com XP, onde basicamente define-se um tempo
padrão para as interações e especifica-se quais e quantas estórias podem ser implementadas
em uma interação. Necessário participação dos desenvolvedores para definir
prioridades e estimativas técnicas.
 Small Releases (Pequenas versões): Conforme as interações são concluídas, o cliente
recebe pequenas versões/releases do sistema, visando com que seja colocado em prática e
validado aquilo que está sendo implementado. Isto também permite que mais cedo possam
ser detectadas necessidades de alterações de requisitos no software.
 Acceptance Tests (Testes de Aceitação): São definidos pelo usuário na fase inicial do
projeto e são os critérios de aceitação do software conforme a estratégia de entrega e
representa exatamente a métrica de aderência do software desenvolvido/implantado ao
universo do cliente.
 Test First Design (Primeiro os testes): Aplicados a partir de testes unitários do código
produzido, além de serem preparados utilizando os critérios de aceitação definidos
previamente pelo cliente. Garante também a redução de erros de programação e aumenta a
fidelidade do código produzido ao padrão estabelecido para o projeto. Através da prática de
testes unitários, definimos antes da codificação , os testes dos métodos críticos do
software ou métodos simples que podem apresentar alguma exceção de processamento.
 Continuous Integration (Integração Contínua): Os diversos módulos do software são
integrados diversas vezes por dia e todos os testes unitários são executados. O código não
passa até obter sucesso em 100% dos testes unitários, facilitando, dessa forma, o trabalho de
implementação da solução.
 Simple Design (Simplicidade de Projeto): O código está, a qualquer momento, na forma
mais simples e mais clara, conforme os padrões definidos pela equipe de desenvolvimento,
facilitando a compreensão e possível continuidade por qualquer um de seus membros.
 Refactoring (Refatoração - melhoria constante do código): A cada nova funcionalidade
adicionada, é trabalhado o design do código até ficar na sua forma mais simples, mesmo que
isso implique em "mexer" em um código que esteja em funcionamento. Claro que a prática de
refatoração nem sempre é aceita, pois envolve questões como prazo e custo. Além disso, e
essa prática em si pode ser minimizada caso o projeto esteja usando 100% de orientação a
objeto, onde podemos criar códigos os mais genéricos e reutilizáveis possíveis, diminuindo o
trabalho em caso de uma possível refatoração.
 Pair Programming (Programação em dupla): Todo código de produção é desenvolvido por
duas pessoas trabalhando com o mesmo teclado, o mesmo mouse e o mesmo monitor,
somando forças para a implementação do código. À primeira vista pode parecer loucura,
pois se imagina estar gastando dois recursos humanos ao mesmo tempo para fazer a mesma
tarefa e sem possibilidade de avanço substancial no projeto. Mas na verdade, essa prática
tem pontos positivos como:
 Compartilhamento de conhecimento sobre das regras de negócio do projeto por
todos da equipe de desenvolvimento;
 Fortalece a prática de Propriedade Coletiva do Código;
 Nivelação de conhecimento técnico dos programadores : Elevação dos níveis de
atenção ao código produzido, pois um “supervisiona” e orienta o trabalho do outro.
Dessa forma, minimiza-se a possibilidade de erros no código, erros de lógica e
produção de um código fora dos padrões estabelecidos pela equipe.
 Move People Around (Rodízio de pessoas): As duplas de programação são revezadas
periodicamente, com o objetivo de uniformizar os códigos produzidos, deixar todos os
módulos do sistema com mesmo padrão de código/pensamento e compartilhar o código com
todos da equipe.
 Collective Code Ownership (Propriedade coletiva - O código é de todos da equipe): Uma
vez aplicados a Programação em Dupla e o Rodízio de Pessoas, a equipe como um todo é
responsável por cada arquivo de código. Não é preciso pedir autorização para alterar
qualquer arquivo, mantendo claro, um padrão prático de comunicação da equipe.
  Coding Standards (Padronização do código): Todo código é desenvolvido seguindo um
padrão, qualquer que seja, mas toda equipe deve seguir o mesmo padrão. Dessa forma,
todos da equipe terão a mesma visão do código.
 40 Hour Week (Otimizando as jornadas de trabalho): Trabalhar por longos períodos é
contraproducente. Portanto, sempre que possível, deve-se evitar a sobrecarga de trabalho de
todos da equipe, criando condições favoráveis ao uso da carga normal de trabalho. É
necessário deixar a equipe livre para relaxar, brincar, ou fazer o quem bem entender para
equilibrar o trabalho mental e físico. Existe até uma frase que diz: trabalhe a 100% durante as
40 horas e descanse a 100% no resto. Se algum deles não for feito com 100%, um afetará o
outro.
o Regras do XP:
 Extreme Programming Planning (Planejamento): Nesta fase, o cliente vai escrever
histórias de usuário que gostaria de ver. Essa reunião vai acontecer no início do ciclo da
iteração e vai contar com:
 Histórias de usuários ;
 Será criado um planejamento de liberação para criar a programação de liberação;
 Projeto é dividido em iterações e lançamentos frequentes;
 O planejamento de iteração vai iniciar cada iteração.
 Gerenciamento: Essa é a etapa em que o gerente de projeto vai escolher a equipe, que vai
trabalhar de forma colaborativa, e poderá promover sucesso no desenvolvimento do software.
Nesta fase há ações como :
 Espaço de trabalho aberto e dedicado;
 Definição de ritmo sustentável;
 Reunião stand up todos os dias;
 Medição da velocidade do projeto;
 Movimento das pessoas;
 Correção do XP, quando necessário.
 Projetando: Nessa regra o valor da simplicidade ganha peso, com início de um design mais
simples ou não adicionar funcionalidade com muita antecedência. Algumas ações dessa fase
são:
 Escolher metáfora do sistema;
 Usar cartões CRC para sessões de design;
 Criar soluções de pico para reduzir riscos;
 Cuidado na adição das funcionalidades com muita antecedência;
 Refatorar sempre que possível, para aprimorar a concepção do software.
 Codificação: Depois de várias fases de trabalho é chegada a hora de implementação do
código no software. Nesta hora, todos revisam e qualquer um dos desenvolvedores podem
acrescentar funcionalidades. Para isso é necessário que:
 O cliente esteja disponível e presente;
 Desenhar diagramas (Extreme Programming Diagram) que serão inscritos nos
códigos;
 O código seja escrito de acordo com os padrões definidos;
 Codificar o teste de unidade primeiro;
 Todo teste de codificação será programado com membros das equipes em pares;
 Apenas um par vai integrar um código por vez;
 Configurar um computador de integração dedicado;
 Usar propriedade coletiva.
 Testes: Nesta fase, a equipe precisa fazer testes de unidade para corrigir eventuais bugs,
antes que código seja liberado. Além disso:
 Quando um erro é encontrado, os testes são criados;
 Os testes de aceitação são realizados frequentemente e a pontuação é executada.
 O feedback ocorre quando os testes unitários ou testes de integração retornam o
estado do sistema após a implementação das mudanças. Ademais, como os
clientes participam do desenvolvimento de testes, eles podem dar um feedback
instantâneo.

Como forma de agilizar as implantações de novas releases nesse modelo, são acumulados grandes grupos de
funcionalidades e implantadas grandes releases. (ERRADO)

é, na XP (Extreme Programming), sustentado por meio de pequenos e frequentes releases do sistema, e os clientes
estão intimamente envolvidos na especificação e na priorização dos requisitos do sistema. (CERTO)

No XP (Extreme Programming), o valor de uma história de usuário é atribuído pelos membros da equipe e é medido
em termos de semanas estimadas para o desenvolvimento. (ERRADO)
Cada história é escrita pelo cliente e é colocada em uma ficha. O cliente atribui um valor (uma prioridade) à
história baseando-se no valor de negócio global do recurso ou função. Os membros da equipe XP avaliam então
cada história e atribuem um custo — medido em semanas de desenvolvimento — a ela. Se a história requerer,
por estimativa, mais do que três semanas de desenvolvimento, é solicitado ao cliente para dividir a história em
histórias menores e a atribuição de valor e custo ocorre novamente.
 RUP (Rational Unified Process)
o É um framework e NÃO uma metodologia (DICA: Não desconsiderar este assunto nas
questões pois CESPE considera como metodologia.!
o Objetivo: garantindo uma produção de software de alta qualidade que cumpra um
cronograma e um orçamento previsíveis.
o Tem como principais características ser incremental e iterativo. Incremental significa
que aquele software é construído e entregue em pedaços, constituindo um conjunto de
funcionalidades completas.
o É utiliza uma abordagem de orientação a objetos em sua concepção e é projetado e
documentado utilizando o UML para ilustrar os processos.
o Através de pequenos ciclos de projetos - que correspondem a uma iteração - o software
é melhorado através da adição de mais detalhes, o que resulta em um incremento no
software. Iterações referem-se a passos e incrementos a evolução do produto.
o Para gerencia de projetos: O RUP define perfeitamente quem é responsável pelo que,
como as coisas deverão ser feitas e quando devem ser realizadas, descrevendo todas
as metas de desenvolvimento especificamente para que sejam alcançadas.
o Uma característica marcante do RUP é que as suas fases são estreitamente relacionadas a
assuntos de negócio, e não ao técnico.
o O RUP é descrito, normalmente, em três perspectivas (O RUP é um exemplo de modelo de
processo que apoia a prototipação e a entrega incremental de softwares. No entanto, ele consegue
combinar as perspectivas estática e dinâmica em um único diagrama.)
 :. Primeira Dimensão: Dinâmica (Horizontal) mostra as fases do modelo (logo são
temporais (dinâmicos). Representa o tempo)
 :. Segunda Dimensão: Estática (Vertical): mostra as atividades/disciplinas realizadas;
Não obrigatoriamente deve-se passar por todas as disciplinas a cada iteração. É
descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho,
artefatos e papéis do processo.
 :. Prática: sugere boas práticas.
o O RUP oferece 4 linhas mestras/esqueletos/princípios de desenvolvimento de
software/práticas (para os membros da equipe de um ciclo de produção: parte do
cliente, e uma avaliação do progresso do projeto pela sua gerência. Além disso, ajuda
os programadores a manterem-se concentrados no projeto.)
 Gestão de Requisitos:
 RUP descreve como documentar a funcionalidade, restrições de sistema,
restrições de projeto e requisitos de negócio. E também ESCOPO DO
PROJETO.
 Os casos de uso (em inglês Use Cases) e os cenários são exemplos de
artefatos dependentes do processo, que têm sido considerados muito mais
eficazes na captura de requisitos funcionais.
 A correção dos requisitos gera a correção do produto, desta forma as
necessidades dos usuários são encontradas.
 As características necessárias serão incluídas, reduzindo o custo de
desenvolvimentos posteriores.
 Atividades do Gerenciamento de Requisitos:
o Análise do problema é concordar com o problema e criar medições
que irão provar seu valor para a organização
o Entender as necessidades de seus stakeholders é compartilhar o
problema e valores com os stakeholders-chave e levantar quais as
necessidades que estão envolvidas na elaboração da ideia
o Definir o problema é a definição das características das
necessidades e esquematização dos casos de uso, atividades que
irão facilmente mostrar os requisitos de alto-nível e esboçar o
modelo de uso do sistema
o Gerenciar o escopo do sistema trata das modificações de escopo
que serão comunicadas baseadas nos resultados do andamento e
selecionadas na ordem na qual os fluxogramas de casos de uso são
atacados
o Refinar as definições do sistema trata do detalhamento dos
fluxogramas de caso de uso com os stakeholders de forma a criar
uma especificação de requerimentos de software que pode servir
como um contrato entre o seu grupo e o do cliente e poderá guiar as
atividades de teste e projeto
o Gerenciamento das mudanças de requisitos trata de como
identificar é importante questionar o quanto o entendimento das
metas propostas desafia a capacidade de equalização das
condições financeiras e administrativas exigidas. as chegadas das
mudanças de requerimento num projeto que já começou
  Uso de arquitetura baseada em componentes
 A arquitetura baseada em componentes cria um sistema que pode ser
facilmente extensível, promovendo a reutilização de software e um
entendimento intuitivo. Um componente normalmente se relaciona com um
objeto na programação orientada a objetos.
 O RUP oferece uma forma sistemática para construir este tipo de sistema,
focando-se em produzir uma arquitetura executável nas fases iniciais do
projeto, ou seja, antes de comprometer recursos em larga escala.
 Promove reusabilidade de software
 Esta arquitetura então se torna um protótipo nos ciclos iniciais de
desenvolvimento.
 Diferença Classes de Análise x Classes de Projeto - Características:
o Classe de Análise: Abstrato, Independente, Simples, Modelos de
caso de uso
o Classe de Projeto: Concreto, Depende da tecnologia, Detalhado e o
modelo é unificado em um.
 Uso de software de modelos visuais
 Ao abstrair a programação do seu código e representá-la utilizando blocos de
construção gráfica, o RUP consegue uma maneira efetiva de se ter uma visão
geral de uma solução.
 O uso de modelos visuais também pode permitir que indivíduos de perfil
menos técnico (como clientes) tenham um melhor entendimento de um dado
problema, e assim se envolvam mais no projeto como um todo.
 A linguagem de modelagem UML tornou-se um padrão industrial para
representar projetos
 Notação UML: Cases de Usos, Diagrama de Classes
 Verificação da qualidade do software
 visa auxiliar no controle do planejamento da qualidade, verificando-a na
construção de todo o processo e envolvendo todos os membros da equipe de
desenvolvimento.
 RUP assume que cada membro da equipe é responsável pela qualidade
durante todo o processo. O processo tem enfoque na descoberta da qualidade
esperada e provê testes nos processos para medir este nível.
 Gestão e Controle de Mudanças do Software
 define métodos para controlar e monitorar mudanças.
 define áreas de trabalho seguras, garantindo a um programador que as
mudanças efetuadas em outro sistema não afetarão o seu sistema.
 Desenvolvimento iterativo
 usa desenvolvimento iterativo e incremental
 De forma ideal, ao término de cada iteração haverá uma versão executável, o
que ajuda a reduzir o risco de configuração do projeto, permitindo maior
retorno do usuário e ajudando ao desenvolvedor manter-se focado.
 Os riscos são abordados no inicio do desenvolvimento e cada iteração permite
a verificação de riscos já percebidos bem como a identificação de novos
 O envolvimento dos stakeholders é frequentemente encorajado a cada
entrega.
 as entregas servem como uma forma de se obter o comprometimento dos
envolvidos, promovendo também uma constante comparação entre os
requisitos e o desenvolvimento da organização para as pendências que
surgem.
o Pilares do RUP:
 Iterativo e Incremental
 Guiado por casos de uso
 Centrado na arquitetura
 Orientado a objetos
 Planejado por riscos
o O RUP também se baseia nos 4 Ps:
 Pessoas
 Projeto
 Produto
 Processo
 As fases são compostas de iterações. As iterações são janelas de tempo; as iterações
possuem prazo definido enquanto as fases são objetivas. Todas as fases geram
artefatos. Estes serão utilizados nas próximas fases e documentam o projeto, além de
permitir melhor acompanhamento.
o A qualidade de software é um quesito para TODAS as fases do RUP.
o O RUP organiza o desenvolvimento em 4 fases bem direcionadas, contendo em cada
uma delas no mínimo uma iteração, ou seja, um ciclo de vida composta de:
 Concepção/Iniciação : define o escopo do software e escopo de projeto. É uma fase
preliminar, é nessa etapa que se concentra o levantamento de requisitos, define preços
e prazos da entrega do sistema e onde se avalia os possíveis riscos. Abrange as tarefas
de comunicação com o cliente e planejamento. É feito um plano de projeto avaliando os
possíveis riscos, as estimativas de custo e prazos, estabelecendo as prioridades,
levantamento dos requisitos do sistema e preliminarmente analisá-lo. Assim, haverá uma
anuência das partes interessadas na definição do escopo do projeto, onde são
examinados os objetivos para se decidir sobre a continuidade do desenvolvimento.
 Contém workflow
 Requisitos são transformados em Casos de Uso e Objetos
 Etapa de análise de viabilidade e riscos/custos do projetos
 Permitido protótipo.
 Quando necessário, podem existir implementações e testes, bem
como elaboração de protótipos para redução de possíveis riscos ao
projeto (WAZLAWICK, 2013). 
 Elaboração: Ênfase na arquitetura/plano do projeto de sistema, especificação de
características e arquitetura. Aqui todas as análises de riscos são aprofundadas, como
também os custos.
 Levantamento / documentação dos casos de uso, voltado para a arquitetura
do sistema,
 Revisa a modelagem do negócio para os projetos
 inicia a versão do manual do usuário.
 Deve-se aceitar: Visão geral do produto (incremento + integração) está
estável?; O plano do projeto é confiável?; Custos são admissíveis?
 Construção: Ênfase no desenvolvimento. Ocorre a codificação do software.
 começa o desenvolvimento físico do software, produção de códigos, testes
alfa.
 Os testes beta são realizados no início da fase de Transição.
 Deve-se aceitar testes, e processos de testes estáveis, e se os códigos do
sistema constituem "baseline".
 Transição: ênfase na implantação. implantação do software, assegurando que ele
esteja disponível aos usuários finais. Nesta fase está incluída os testes e o treinamento
dos usuários.
 é realizado o plano de implantação e entrega, acompanhamento e qualidade
do software.
 Realização de teste BETA
 Produtos (releases, versões) devem ser entregues, e ocorrer a satisfação do
cliente.
 Nesta fase também é realizada a capacitação dos usuários.
 O produto de software é desenvolvido em iterações; o final de cada iteração é
marcado por um ponto de verificação[ponto de validação com lançamento
de uma versão release/executável ] e disponibilização de artefatos que
representem o atingimento do marco[marco ao final de cada fase, não
interação].
 Cada fases e seu marco
Iniciação = Marco dos objetivos do ciclo de vida;
Elaboração = Marco da arquitetura do ciclo de vida;
Construção = Marco da capacidade operacional inicial;
Transição = Marco de lançamento do produto/Release do produto
o RUP oferece 6 disciplinas de Engenharia de Software:
 Disciplina de Modelagem de Negócios
 Modelagem de negócios, explica como descrever uma visão da organização
na qual o sistema será implantado e como usar esta visão como uma base
para descrever o processo, papéis e responsabilidades.
 estabelecer uma melhor compreensão e canal de comunicação entre
engenharia de negócios e engenharia de software.
 Compreender o negócio significa que os engenheiros de software devem
compreender a estrutura e a dinâmica da empresa alvo (o cliente), os atuais
problemas na organização e possíveis melhorias.
 Disciplina de Requisitos
 explica como levantar pedidos das partes interessadas ("stakeholders") e
transformá-los em um conjunto de requisitos que os produtos funcionam no
âmbito do sistema a ser construído e fornecem requisitos detalhados para o
que deve fazer o sistema.
 Disciplina de Análise e Desenho/Projeto("Design")
 mostrar como o sistema vai ser realizado.
  O modelo de design serve como uma abstração do código-fonte, isto é, o
projeto atua como um modelo de "gabarito" de como o código-fonte é
estruturado e escrito.
 O modelo de projeto consiste em classes de design estruturado em pacotes
e subsistemas com interfaces bem definidas, representando o que irá se
tornar componentes da aplicação. Ele também contém descrições de como
os objetos dessas classes colaboram para desempenhar casos de uso do
projeto.
 disciplina de análise e suporte pertence ao grupo das disciplinas de
engenharia e portanto não produzem artefatos de suporte.
 Disciplina de Implementação
 O processo descreve como reutilizar componentes existentes ou implementar
novos componentes com responsabilidades bem definidas, tornando o sistema
mais fácil de manter e aumentar as possibilidades de reutilização.
 Para definir a organização do código, em termos de subsistemas de
implementação organizadas em camadas
 Para implementar classes e objetos em termos de componentes (arquivos-
fonte, binários, executáveis e outros)
 Para testar os componentes desenvolvidos como unidades individuais
 Integrar os resultados produzidos por implementadores individuais (ou
equipes), em um sistema executável
 A disciplina de Implementação é a que demanda maior esforço nas
fases de elaboração e construção.
 Disciplina de Teste
 Verificar a interação entre objetos
 Verificar a integração adequada de todos os componentes do software
 Verificar se todos os requisitos foram corretamente implementados
 Identificar e garantir que os defeitos são abordados antes da implantação do
software
 Garantir que todos os defeitos são corrigidos, reanalisados e fechados.
 Propõe uma abordagem iterativa, o que significa que deve-se testar todo o
projeto. Isto permite encontrar defeitos tão cedo quanto possível, o que reduz
radicalmente o custo de reparar o defeito.
 Os testes são realizados ao longo de quatro dimensões da qualidade:
o confiabilidade,
o funcionalidade,
o desempenho da aplicação, e o
o desempenho do sistema.
 Para cada uma destas dimensões da qualidade, o processo descreve como
passar pelo teste do ciclo de planejamento, projeto, implementação, execução
e avaliação.
 Disciplina de Implantação
 Embora as atividades de implantação estejam principalmente centradas em
torno da fase de transição, muitas das atividades devem ser incluídas nas
fases anteriores para se preparar para a implantação, no final da fase de
construção. Os processos ("workflows") de "Implantação e Ambiente" do RUP
contêm menos detalhes do que outros workflows.
o RUP oferece 3 disciplinas de Apoio/Suporte:
 Disciplina de Ambiente
 enfoca as atividades necessárias para configurar o processo para um projeto.
Ele descreve as atividades necessárias para desenvolver as diretrizes de
apoio a um projeto. A proposta das atividades de ambiente é prover à
organização de desenvolvimento de software os processos e as ferramentas
que darão suporte à equipe de desenvolvimento.
 ajudar a tornar esta etapa mais simples, engenheiros de processos e gerentes
de projeto poderiam mais facilmente personalizar o RUP para suas
necessidades de projeto.
 Quesito de Qualidade de Software.
 Disciplina de Configuração e Gerência de Mudança
 abrange três gerenciamentos específicos:
o de configuração:
 responsável pela estruturação sistemática dos produtos.
Artefatos, como documentos e modelos, precisam estar
sob controle de versão e essas alterações devem ser
visíveis. Ele também mantém o controle de dependências
entre artefatos para que todos os artigos relacionados
sejam atualizados quando são feitas alterações
(rastreabilidade)
 o de solicitações de mudança:
 Durante o processo de desenvolvimento de sistemas com
muitos artefatos existem diversas versões. O CRM
mantém o controle das propostas de mudança
o de status e medição:
 Os pedidos de mudança têm os estados: novo,
conectado, aprovado, cedido e completo. A solicitação
de mudança também tem atributos como a causa raiz, ou
a natureza (como o defeito e valorização), prioridade,
etc. Esses estados e atributos são armazenados no banco
de dados para produzir relatórios úteis sobre o andamento
do projeto.
 Disciplina de Gerência de Projeto
 O planejamento de projeto no RUP ocorre em dois níveis. Há uma baixa
granularidade ou planos de Fase que descreve todo o projeto, e uma série de
alta granularidade ou planos de Iteração que descrevem os passos iterativos.
Esta disciplina concentra-se principalmente sobre os aspectos importantes de
um processo de desenvolvimento iterativo: Gestão de riscos; Planejamento de
um projeto iterativo através do ciclo de vida e para uma iteração particular; E o
processo de acompanhamento de um projeto iterativo, métricas. No entanto,
esta disciplina do RUP não tenta cobrir todos os aspectos do gerenciamento
de projetos. Por exemplo, não abrange questões como:
o Gestão de Pessoas: contratação, treinamento, etc
o Orçamento Geral: definição, alocação, etc
o Gestão de Contratos: com fornecedores, clientes, etc

 Agile UX e Lean UX
o Agile UX e Lean UX se complementam e vivem em simbiose do mesmo projeto

o Design Thinking: (traço vermelho): Qual é o problema que precisa ser resolvido (pain point) e
para explorar hipoteses e potenciais soluções para ele.
o Lean UX (traço amarelo): Processo iterativo de construir algo, receber feedback sobre o que foi
construído e na sequência pensar novas ideias que incorporarão o feedback recebido no produto.
Tudo em forma de ciclo: o produto vai amadurecendo mais e mais à medida que as várias
iterações de design acontecem.
 Construir MPV para resolver problemas de usuário
 Prototipar rapidamente e colaborativamente
 Validar hipóteses com os usuários o quanto antes
 Usar métricas e outros insights para validar as ideias e refiná-las com o passar do
tempo.
 Exemplos de ferramentas/técnicas de Lean UX:
 MVP
 Funnel Anaylis (Analise de Funil)
 Conversando com clientes
 Resolvendo problemas
 Aprendendo looping
o Agile UX (traço azul): Mistura de métodos ágeis e UX onde UX Designers e Desenvolvedores
trabalham lado a lado para fazer o protótipo de produto tomar forma.
 Interações entre os membros de time são mais importantes do que os processos e
ferramentas
 Construir o software é mais importante do que produzir documentação super extensa
 Envolver o consumidor no processo é extremamente importante para colher feedback o
quanto antes
 Saber adaptar a mudança ao invés de seguir um plano rígido.
  Exemplos de técnicas de Agile UX:
 Sprints
 Owners
 Kanban
 ScrumMaster
 Iteration
 Retrospectivas
o As duas priorizam colaboração em relação à documentação.

Domain-driven design (DDD)

 foi criado para ajudar equipes a ter mais sucesso no desenvolvimento de software com alta qualidade.
Quando implementado corretamente, o DDD entrega um design que traduz exatamente como o dominio
funciona.
 A principal ideia do DDD é a de que o mais importante em um software não é o seu código, nem sua
arquitetura, nem a tecnologia sobre a qual foi desenvolvido, mas sim o problema que o mesmo se propõe a
resolver, ou em outras palavras, a regra de negócio.
 Entregar um software com poucos bugs é bom.
 Ainda assim, entregar um software em que o modelo de domínio foi cuidadosamente elaborado. O design
traduz a complexidade das regras de negócio e processos da organização. Resulta em benefícios a longo
prazo. Agiliza os processos da empresa. Facilita a implementação de novas features. Aumenta a vida útil do
software.
 O Domain Driven Design (DDD) combina práticas de design e desenvolvimento. Oferece ferramentas de
modelagem estratégica e tática para entregar um software de alta qualidade. O objetivo é acelerar o
desenvolvimento de software que lidam com complexos processos de negócio.
 O DDD não é uma tecnologia ou uma metodologia. Pode ser utilizado independente da linguagem. Não
importa se é C# ou Java. Se é MVC ou Windows Forms.
 Não é arquitetura em camadas e não impõe processos rígidos ao time.
 DDD não é apenas separar as camadas, mas sim seguir todo um processo de desenvolvimento, desde
entender o negócio com o Domain Expert, extrair a linguagem ubíqua, definir os contextos, criar o mapa de
contexto para poder começar a trabalhar as entidades e poder desenvolver a aplicação.
 Dominio: Domínio é o coração do negócio em que você está trabalhando. É baseado em um conjunto de
ideias, conhecimento e processos de negócio. É a razão do negócio existir. Sem o domínio todo o sistema,
todos os processos auxiliares, não servirão para nada.
 DDD é uma jornada, não o destino. A busca pela harmonia do domínio nunca termina. O domínio muda à
medida que o negócio muda. Mantém o software alinhado com o negócio. Faz isso estratégica, tática e
filosoficamente.
 Praticar DDD, significa aproximar os especialistas do domínio (Domain experts) do time de
desenvolvimento. Criando uma linguagem única. Uma comunicação sem ruídos, limpa.
 Atores:
o Domain Expert
 É aquele que entende do negócio. Apoia o time de desenvolvimento na modelagem do
domínio.
 Possuem condições de guiar a equipe para desenvolver um bom software.
 DDD irá entregar um código que fala sobre o negócio. Faz sentido do ponto de vista de
negócio. Se os domains experts fossem os devs, seria o código que eles fariam.
o Linguagem ubíqua, bounded contexts e Context Maps são os 3 pilares do DDD. Andam lado a
lado. Através da linguagem ubíqua é possivel identificar e delimitar os bounded context.
 A linguagem ubíqua não é a linguagem do negócio, não é um pattern. É a linguagem
utilizada pela equipe do projeto. Desenvolvedores pensam em classes, métodos,
componentes. Padrões GOF, SOLID. Tendem a achar correspondência entre um
conceito da vida real com programação. Entender quais objetos criar. Qual
relacionamento entre eles. Pensam em herança, polimorfismo, OOP. Os domains
experts não entendem esses termos. Seu repertório exclui idéias sobre componentes,
frameworks e persistência. Eles são especialistas do negócio. Conhecem e sabem como
a empresa deve funcionar. A Linguagem Ubíqua é uma linguagem de equipe.
Compartilhada por todos na equipe. Não importa papel. Se está no time, deve utilizar a
Linguagem Ubíqua. Se o negócio está em constante evolução a linguagem ubíqua
também. Não é estática. Evolui de acordo com a evolução do software.
 Bounded context é um delimitador do domínio. Dentro do limite, todos os termos e
frases da Linguagem Ubíqua têm um significado específico. E o modelo reflete a
Linguagem Ubíqua. Repare que Customer e Product aparecem duas vezes. Porém em
bounded contexts diferentes. Significa que possuem papéis e responsabilidades distintas
dentro de cada contexto. Perceba que para cada contexto Product possui características
distintas e destilando seus detalhes, também terá comportamentos únicos. Identificar
bounded context requer maturidade do negócio. Por isso a necessidade de trabalhar
em conjunto com os domains experts. Com o tempo e amadurecimento da linguagem
ubíqua o time cria mais condições de explorar os limites do contexto.
  Context Maps: é que o mapeamento dos Bounded Contexts. A partir do momento que
temos o Context Map definido, podemos avançar para a arquitetura contextual, que já é
uma forma mais técnica de entendimento. Os três tipos de arquitetura de software são:
 Web App Tier,
 Background Tier e
 Database Tier.
 Domain Model Patterns:
o Domain Model Patterns, que são padrões de desenvolvimento e estruturação de aplicações cujo
domínio é o principal foco, sendo que eles estão focados em:
 (Aggregate Objects) ou entidades de agregadores: Entidade principal desse contexto
(Objects Aggregate) / objetos agregadores: são diversas entidades que estão no
mesmo contexto e que se consomem. Essas possuem as propriedades, métodos,
validadores, para garantir que todas as informações que elas possuem estejam corretas.
Vale lembrar que não estamos falando em Banco de Dados. O DDD prega que as
entidades devem desconhecer a existência do Banco de Dados, diferentemente no caso
da utilização do Active Record onde a entidade conhece o Banco de Dados.
 (Value Objects) Objeto de valor: têm as seguintes características: são imutáveis,
possuem coleção de atributos, normalmente não possuem métodos setters, a entrada de
valor é por um construtor e possuem tipagem forte ao invés da utilização de dados
primitivos.
 Repositories (Repositorios): Os Repositórios possuem acesso direto a camada de
dados podendo persistir dados e realizar as consultas. Lembrando que devemos sempre
utilizar um repositório por agregação. Um repositório também pode consultar diretamente
serviços externos.
 Domain Services (Servicos de domínio): implementam a lógica de negócios a partir
da definição de um expert de domínio. Trabalham com diversos fluxos de diversas
entidades e agregações, utilizam os repositórios como interface de acesso aos dados e
consomem recursos da camada de infraestrutura, como: enviar email, disparar eventos,
entre outros.

Enterprise Content Management (ECM)

 O ECM é um conjunto de estratégias, métodos e ferramentas utilizados na coleta, gestão, acesso,

integração, medição e armazenamento de informações de uma empresa.
 Trata-se de gerenciamento de todo o ciclo de vida do conteúdo de uma organização. Pode ser incluindo
documentos do Word, planilhas do Excel, arquivos PDF e imagens.
 Ele centraliza o armazenamento, acesso, compartilhamento e mesmo edição de documentos, dados e
informações em múltiplos formatos.
 ele pode auxiliar diretamente na otimização dos processos de negócios, de forma a potencializar as ações e
melhorar a tomada de decisões.
 Desse modo, através de uma abordagem de serviços de conteúdo bem-sucedida, sua empresa pode lidar
com problemas comuns a algumas organizações, como no combate aos silos de informações. Desse modo,
seus funcionários podem acessar/fornecer as informações certas, para as pessoas certas e no momento
certo.
 ECM pode ser implementada em qualquer tipo de negócio, não importando o nicho nem o porte.
 O ECM serve para aprimorar a produtividade de uma empresa, melhorando a eficiência da relação entre os
funcionários e os conteúdos/informações que necessitam em seu dia a dia.
 ECM funciona baseado em 5 etapas/elementos:
o Capturar: Esse ponto trata da consolidação de informações, captando-as de várias maneiras
diferentes. Esses dados podem vir de aplicativos usados pela empresa, através do CRM, ERP e
em softwares de BPM. Para o processo ser eficiente, é necessário obter dados e disponibilizá-los
para consulta de uma forma estruturada, mantendo os arquivos organizados. Essas informações
capturadas podem incluir estatísticas, notas fiscais, faturas, planilhas, contratos, relatórios de
pesquisa e checklists.
o Gerenciar: O gerenciamento em ECM trabalha baseado em mais três subtópicos, que podemos
classificar como:
 Conectar;
 Modificar,
 Empregar informações.
O ideal é que esses pontos sejam gerenciados por meio de um de um software colaborativo,
baseado na nuvem, e que consigam ter maior mobilidade, com acesso remoto através de
dispositivos móveis e de quebra ainda ofereçam maior segurança da informação.
o Armazenar: Os conteúdos precisam estar armazenados em um repositório que acabe com o risco
da duplicidade de arquivos. Backups precisam ser feitos com frequência, para evitar a perda de
dados e as alterações de informações devem ter acesso ágil, com a última versão dos documentos
sempre disponível. Os seus colaboradores precisam visualizar e editar as informações com
facilidade. O uso de mecanismos de pesquisa e filtros pode ser bastante útil nesse quesito, para
que uma informação importante seja encontrada no momento em que mais se precisa dela.
o Preservar: A segurança da sua empresa é essencial.Por esse motivo, senhas, criptografia,
autenticação de dois fatores e outros mecanismos de preservação dos dados devem ser
 empregados da maneira mais eficiente possível. Para garantir essa segurança, o uso de backups
não só em um, mas em diversos servidores remotos, é uma providência que deve ser levada em
consideração para proteger o negócio.
o Entregar conteúdos e informações: A gestão de conteúdo ECM vai além da organização dos
diretórios na busca de informações. Integrações com sistemas de BPM podem permitir que os
dados e conteúdos já sejam encaminhados para quem precisa deles em suas rotinas diárias e
fluxos de trabalho. Assim, toda vez que um relatório de qualquer setor é enviado para a empresa,
ele pode ser disponibilizado automaticamente para os colaboradores que têm experiência sobre
aquele determinado tema e sabem aplicar o conteúdo, melhorando a tomada de decisão.
o Vantagens:
 Redução do uso de papel
 Organização de processos
 Centralização das informações
 Mitigação de riscos
 Otimização do espaço físico

Em um ECM (enterprise content management), a disponibilidade dos documentos a longo prazo

ocorre na etapa de armazenamento. (ERRADO)

kanban

 Seu principal objetivo era mapear todos os processos de abastecimento e fluxo. Assim, permitindo uma
diminuição dos desperdícios ou atrasos, que são bem comuns em indústrias e causam grandes perdas
financeiras.
 Uso de cartões coloridos para designar as diferentes etapas em que cada processo estava.
 Outro exemplo que podemos dar é relacionado com a quantidade de matérias-primas. Desse jeito, cada uma
tem uma cor e elas são divididas nas categorias:
o precisa comprar com urgência,
o comprar até data tal,
o suficiente para a produção.
 A verdade é que não existe apenas uma maneira de utilizar o método kanban, podendo se adaptar para as
diferentes necessidades da empresa ou de qualquer tipo de setores.
 Práticas:
o CARTÃO: O cartão representa uma ação, uma tarefa ou um item que será movido de acordo com
o andamento do processo. Ele é colorido para facilitar a identificação dos processos, já que as
cores podem representar:
 quem é o responsável pelo cartão,
 qual é o nível de prioridade,
 setor encarregado pela próxima ação,
 o cliente requerente.
o Colunas: Por sua vez, as colunas representam o status dos cartões, ou seja, são os locais para os
quais eles são movidos após haver uma mudança. No exemplo citado da linha de produção, por
exemplo, as colunas seriam “equipe 1”, “equipe 2” e assim por diante. Já no segundo exemplo
seria “precisa comprar com urgência”, “comprar até data tal” e “suficiente para a produção”. De
modo geral, normalmente as empresas utilizam três colunas:
 a ser feito,
 em execução,
 feito.
 Mas pode-se personalizar para as suas necessidades.
o Quadro: O último elemento do método kanban representa o local que organiza as colunas e os
cartões. Ele pode ser em um vidro no escritório, em um quadro branco ou, no caso de times
remotos, online.
 Vantagens:
o Melhora comunicação interna
o Maior autonomia para os colaboradores
o Ganho de produtividade
o Melhor priorização das tarefas

A implementação de um Kanban pressupõe a definição de um fluxo de trabalho pela equipe, o qual poderá ser
revisto, mediante a inclusão ou a retirada de estágios, à medida que o trabalho evoluir.(CERTO)

1.8 Gerenciamento de ciclo de vida de aplicações.

1.9 Desenvolvimento orientado por comportamento (BDD).

Behavior driven development (BDD) – Desenvolvimento orientado a Objetos

  O BDD é uma prática ágil que permite uma melhor comunicação entre desenvolvedores, analistas de
qualidade, áreas de negócio e pessoas não-técnicas, durante um projeto de software, descrevendo um ciclo
de iterações com saídas bem definidas e resultando na entrega de software testado e que funciona.

1.10 Desenvolvimento guiado por testes (TDD).

test-driven development (TDD)

 TDD é uma sigla para Test Driven Development, ou Desenvolvimento Orientado a Testes. A ideia do TDD é
que você trabalhe em ciclos. Estes ciclos ocorrem na seguinte ordem:
o RED: Primeiro, escreva um teste unitário que inicialmente irá falhar, tendo em vista que o código
ainda não foi implementado;
o GREEN: Crie o código que satisfaça esse teste, ou seja: implemente a funcionalidade em questão.
Essa primeira implementação deverá satisfazer imediatamente o teste que foi escrito no ciclo
anterior;
o REFACTOR: Quando o código estiver implementado e o teste satisfeito, refatore o código para
melhorar pontos como legibilidade. Logo após, execute o teste novamente. A nova versão do
código também deverá passar sem que seja necessário modificar o teste escrito inicialmente.
(Elimine a redundância)
 TDD é uma metodologia para desenvolvimento e escrita código.
 O TDD transforma o desenvolvimento, pois deve-se primeiro escrever os testes, antes de implementar o
sistema. Os testes são utilizados para facilitar no entendimento do projeto, segundo Freeman os testes são
usados para clarear a ideia em relação ao que se deseja em relação ao código.
 A ideia é que você utilize estes ciclos para testes unitários - testes estes que visam avaliar o
comportamento de classes e métodos em específico. Você irá identificar quais são os comportamentos
esperados dos métodos a serem desenvolvidos. Ao invés de implementar o código inicialmente, você irá criar
o código de teste ligado a essas classes e métodos que você deseja implementar. Como esse código ainda
não estará devidamente implementado, o teste irá falhar (red), para que em seguida você faça a
implementação dessa funcionalidade. Com a implementação, é esperado que esse teste passe (green). No
final, você pode melhorar esse código, evitando duplicidade e trechos de código desnecessários (refactor) e
irá fazer o teste novamente, onde ele deve passar. Assim você terá um código funcional e já devidamente
testado.
 Um sistema é um conjunto de unidades integradas, por este motivo é importante os testes unitários para ver
se no micromundo tudo funciona, mas também temos de testar a integração, ou seja, ao integrar dois ou
mais componentes, devemos realizar testes para verificar se a integração funciona.
 Benefícios:
o realizarmos alterações no código por conta de testes que não passaram, aumentando
substancialmente a possibilidade de introduzirmos problemas com estas alterações.
o Minimizar quantidades de bugs antes de liberar para cliente
o Aumentar a qualidade de software
o Escrevendo os testes na etapa inicial, pode até parecer que acabamos tendo uma tarefa a mais a
ser desempenhada; porém, no fim, seu software terá menos possibilidade de falhas, além de você
acabar desenvolvendo código com mais qualidade.
o Test Driven Development, ou TDD, também conhecido por Test-First, é um conjunto de técnicas
associadas com o XP e métodos ágeis.

• TDD reivindica um desenvolvimento incremental do código que inicia com testes, incluindo
frequentemente testes de regressão.

• Uma das regras do TDD é a seguinte: “se você não consegue escrever um teste para aquilo que
você está codificando, então você nem deveria pensar sobre codificar”.

• Esta técnica de desenvolvimento é antiga, mas tornou-se conhecida, após sua adoção em
metodologias ágeis de desenvolvimento, tornando assim, um desenvolvimento incremental, onde o
código é escrito para passar pelos testes já escritos previamente.

Mesmo TDD sendo uma prática do XP, esta não se encontra isolada no universo do XP. Abaixo,
segue uma lista de práticas que são complementares e/ou completadas usando-se o TDD:

• Programação em pares: a programação pareada melhora o TDD no momento em que o

programador que está codificando o código.

• Integração contínua: testes são um excelente recurso para esta prática, permitindo que sempre
seja feita uma integração.

• Design simples: codificando apenas o necessário para os testes, e removendo código duplicado,
automaticamente obtém-se um design adaptado para a necessidade atual.

• Refatoração: a regra de remoção de código duplicado é outra maneira de se fazer refatoração.

Mas os testes garantem ao desenvolvedor, que grandes mudanças feitas no sistema, não
alteraram o funcionamento do mesmo.
 • Entrega contínua: com testes realizados no sistema, têm-se mais confiança na
entrega de partes do sistema, e o código vai para produção mais rápido.
 Além disso, os testes devem seguir o modelo F.I.R.S.T.
o F (Fast) - Rápidos: devem ser rápidos, pois testam apenas uma unidade;
o I (Isolated) - Testes unitários são isolados, testando individualmente as unidades e não sua
integração;
o R (Repeateble) - Repetição nos testes, com resultados de comportamento constante;
o S (Self-verifying) - A auto verificação deve verificar se passou ou se deu como falha o teste;

T (Timely) - O teste deve ser oportuno, sendo um teste por unidade.Desenvolvimento orientado a TDD é um
conjunto de técnicas que se associam ao XP (extreme programming) para o desenvolvimento incremental do código
que se inicia com os testes. (CERTO)

"O desenvolvimento orientado a testes (TDD — test driven development) agrega uma técnica de design e análise
(?) em que a funcionalidade de teste vem como um valor agregado, (CERTO - a funcionalidade de teste vem com
um valor agregado nessa técnica, isto é, possui um valor maior do que normalmente possui em outras técnicas)
uma vez que os desenvolvedores tentam entender o objeto que estão prestes a construir (CERTO - Sim, os
desenvolvedores tentam entender o objeto que estão prestes a construir, para criarem os testos antes mesmo de
implementar as funcionalidades), concentrando-se nos resultados esperados da funcionalidade. (CERTO - fazem os
testes de acordo com o que esperam que seja a saída daquele trecho de código)".

 Teste de Release é o processo de testar um release particular de um sistema que se destina para uso fora da
equipe de desenvolvimento. Geralmente, o release de sistema é para uso dos clientes e usuários . Costuma ser
um processo de teste de caixa-preta, no qual os testes são derivados da especificação de sistema..
 Teste de Cenário é uma abordagem de teste de release em que você imagina cenários típicos de uso e os usa
para desenvolver casos de teste para o sistema. Um cenário é uma estória que descreve uma maneira de usar o
sistema. Cenários devem ser realistas, e usuários reais do sistema devem ser capazes de se relacionar com eles.
 Teste de regressão: Um conjunto de testes é desenvolvido de forma incremental enquanto um programa é
desenvolvido. Usado para verificar se as mudanças no programa não introduzem novos bugs.

Acceptance test-driven development (ATDD) ou Desenvolvimento Orientado a Testes de Aceitação:

 É uma prática de obtenção de requisitos de forma colaborativa aplicada por equipes ágeis, onde exemplos
concretos e testes automatizados são utilizados para especificar os requisitos, tornando-os mais claros, com
o objetivo de criar especificações executáveis. Eles são gerados em sessões de criação do backlog do
produto, com a participação da equipe, Product Owner, além dos demais interessados.
 Os 4 passos do ciclo de vida de ATDD:
o Debater os requisitos:
 As histórias de usuário (user story) são refinadas em um workshop ou em uma reunião
de preparação do backlog do produto (backlog grooming), antes da reunião de
planejamento da iteração/sprint. Em ambos os casos, os participantes são uma equipe
multifuncional, o Product Owner e, algum outro interessado que potencialmente tem mais
informações sobre as histórias.
 Após a obtenção dessas respostas a partir das perguntas coletadas pelo cliente, existe
um entendimento melhor do que o Product Owner espera que o produto faça ou não.
Então, pode-se começar a estruturar os testes de aceitação em colaboração com todos.
Fazemos isso em uma linguagem que todos entendam, por exemplo:
 usuário deve ser cadastrado no site; senão estiver, remeta-o para a página de
cadastro;
 usuário deverá estar logado; senão estiver, solicite o usuário e senha;
 usuário cadastrado e logado deverá confirmar o alerta para o e-mail que está
no cadastro.
o Refinar os testes de aceitação
 O próximo passo é organizar os testes de aceitação em um formato requerido pelo
framework de automação de testes tais como cucumber, FIT, etc
 Exemplo de testes de aceitação:
 o Desenvolver/Implementar o código com TDD:
 O próximo passo é implementar a funcionalidade para fazer com que o teste de
aceitação passe.
 E, para tanto, o desenvolvimento deve iniciar pelos testes unitários, incluindo todas as
condições propostas para as expectativas existentes. Um exemplo para um cenário é
exibido abaixo:


 Depois de codificados todos os testes unitários, eles são executados e passamos a uma
fase para ajustar aqueles que estão falhando (frameworks de testes unitários sinalizam
por meio de "barras de progresso" vermelha e verde (vide imagem abaixo), onde uma
barra vermelha é porque o teste está "quebrado" e verde é quando ele passa com
sucesso), partindo então para a implementação da história de usuário.
o Revisar/Apresentar resultados dos testes de aceitação
 Após os testes passarem com sucesso, a história é verificada pelo Product Owner,
normalmente em uma reunião de Review/Showcase, onde ele poderá aprová-la ou não.
O resultado pode levar à criação de uma nova história ou uma alteração nos testes
existentes, afim de contemplar novos cenários.
 Outra forma que também funciona bem, e não posterga a validação em uma reunião
específica, é a validação de cada história (Review), imediatamente após ela ser
desenvolvida pela equipe, de tal maneira que o Product Owner possa fazer isso com o
desenvolvedor ou o par de desenvolvedores que a finalizaram.

o Teste de Integração em diferentes abordagens:

 1 - Integração Descendentes: teste de integração descendente (top-down) é uma abordagem
incremental para a construção da arquitetura de software. Os componentes são integrados
movimentando-se de cima para baixo através da hierarquia de controle da aplicação, começando
com o módulo de controle principal (programa principal). Módulos subordinados ao módulo de
controle principal são incorporados à estrutura de uma maneira: primeiro-em-profundidade ou
primeiro-em-largura (depth-firstou breadth-first).
 1.1 - Breadth-first (largura): incorpora todos os componentes
diretamente subordinados a cada nível, movimentando-se
horizontalmente ao longo da arquitetura.
 1.2 -Depth-first (profundidade): integra todos os componentes num
caminho de controle principal da arquitetura. A escolha de um
caminho de controle principal é bastante arbitrária e depende das
características específicas da aplicação.
 2 - Integração Ascendentes: o teste de integração ascendente (bottom-up), como o nome diz,
começa a construção e o teste com módulos atômicos (isto é, componentes nos níveis mais baixos
na estrutura do programa). Devido aos componentes serem integrados de baixo para cima, a
funcionalidade proporcionada por componentes subordinados a um dado nível está sempre
disponível e a necessidade de pseudocontrolados (stubs) é eliminada. As rotinas escritas para tais
testes são conhecidas como drivers, pois sua função é acionar o código que deve ser testado. No
 teste up-down, a função inversa é fornecida pelos stubs que provêem dados para as rotinas de
nível superior, permitindo que se realizem os testes.

1.11 Integração contínua.

1.12 Diagrama Entidade Relacionamento (ER) ou MER

o O Modelo Entidade Relacionamento de um banco de dados é um tipo de modelagem
conceitual, o qual procura representar, de maneira abstrata, os objetos de um domínio de
negócios, descrevendo as suas características e relacionamentos.  
o Um diagrama entidade relacionamento (ER) é um tipo de fluxograma que ilustra como
“entidades” p. ex., pessoas, objetos ou conceitos, se relacionam entre si dentro de um
sistema.
o Um modelo E-R é uma maneira sistemática de descrever e definir um processo de negócio.
o Diagramas ER são mais utilizados para projetar ou depurar bancos de dados relacionais nas
áreas de engenharia de software, sistemas de informações empresariais, educação e
pesquisa.
o Também conhecidos como DERs, ou modelos ER, usam um conjunto definido de símbolos,
tais como retângulos, diamantes, ovais e linhas de conexão para representar a
interconectividade de entidades, relacionamentos e seus atributos.
o Eles espelham estruturas gramaticais, onde entidades são substantivos e relacionamentos
são verbos.

o Diagramas ER são compostos de:

 Entidades (RENTAGULO): Algo que pode ser definido e que pode ter dados
armazenados sobre ele — como uma pessoa, um objeto, conceito ou evento.
podem ser classificados como físicos ou lógicos, de acordo sua existência no
mundo real.
 Relacionamentos (LOSANGOS): Os relacionamentos em geral são
nomeados com verbos ou expressões que representam a forma como as
entidades interagem, ou a ação que uma exerce sobre a outra.
o O grau de um relacionamento é referente à quantidade de
entidades que estão presentes em um mesmo relacionamento.
 Atributos (ELIPSES): Atributos são as características que descrevem cada
entidade dentro do domínio. Os atributos podem ser classificados quanto à sua
função da seguinte forma:
o Descritivos: representam característica intrínsecas de uma
entidade, tais como nome ou cor.
o Nominativos: além de serem também descritivos, estes têm a
função de definir e identificar um objeto. Nome, código, número são
exemplos de atributos nominativos.
o Referenciais: representam a ligação de uma entidade com outra em
um relacionamento. Por exemplo, uma venda possui o CPF do
cliente, que a relaciona com a entidade cliente.
o Simples: um único atributo define uma característica da entidade.
Exemplos: nome, peso.
o Compostos (ELISPSE HIERARQUICO): para definir uma
informação da entidade, são usados vários atributos. Por exemplo, o
endereço pode ser composto por rua, número, bairro, etc.
o Monovalorado: Esse atributo possui apenas um valor para uma
determinada entidade. Por exemplo, na entidade “Pessoa”, cada
indivíduo pode ter apenas um valor de CPF.
o Multivalorado (ELIPSE DUPLO): Já o multivalorado permite que
um atributo de uma mesma entidade possa ter mais de um valor.
Um exemplo é o atributo “Telefone”, uma vez que uma pessoa pode
ter mais de um número de telefone.
o Armazenado: São aqueles previamente definidos e armazenados
em um banco de dados.
o Derivado: O derivado é aquele que não é armazenado, mas que
pode ser obtido através daqueles atributos armazenados. Por
 exemplo, suponha-se que o atributo “Data de Nascimento” seja
definido em um banco de dados. Com isso, o atributo “idade” pode
ser obtido através desse atributo previamente armazenado.
o

o Eles também descrevem a cardinalidade, que define as relações em termos de números:

o
 Define os atributos numéricos da relação entre duas entidades ou conjuntos de
entidades.
 A cardinalidade especifica o número mínimo e o máximo de instâncias que uma
entidade pode participar. (X,Y) onde X é mínima e Y é máxima)
 Os três principais relacionamentos cardinais são:
 um-para-um: (1,1)
 um-para-muitos: (1..N) ou (0,N)
 muitos-para-muitos: (N..N)

o Um modelo MER é normalmente implementado como um banco de dados. Nos casos de um

banco de dados relacional, que armazena dados em tabelas, as próprias tabelas representam
as entidades. Alguns campos de dados nestas tabelas apontam para índices em outras
tabelas. Tais ponteiros representam relacionamentos.
o Mapeamento de linguagem natural
 Componentes de ER podem ser equiparados a partes do discurso, como demonstrado
por Peter Chen. Isso mostra como um diagrama ER se compara a um diagrama de
gramática:
 Substantivo comum: tipo de entidade. Exemplo: estudante.
 Nome próprio: entidade. Exemplo: Sally Smith.
 Verbo: tipo de relacionamento. Exemplo: matricula-se. (Tal como em um
curso, o que seria um outro tipo de entidade.)
 Adjetivo: atributo para a entidade. Exemplo: aluno do segundo ano.
 Advérbio: atributo para o relacionamento. Exemplo: digitalmente.
o Modelos conceituais, lógicos e de dados físicos: Modelos ER e modelos de dados são
normalmente desenhadas em até três níveis de detalhe:
 Modelo de dados conceitual: a visão de mais alto nível que contém o mínimo de
detalhe. Seu valor é de mostrar um âmbito geral do modelo e retratar a arquitetura do
sistema. Para um sistema de alcance menor, pode não ser necessário desenhar. Em vez
disso, comece com um modelo lógico.
 Modelo de dados lógico: contém mais detalhes que um modelo conceitual e entidades
operacionais e transacionais mais detalhadas agora são definidas. O modelo lógico é
independente da tecnologia na qual ele será implementado.
 Modelo de dados físico: um ou mais modelos físicos podem ser desenvolvidos a partir
de cada modelo lógico. Modelos físicos devem mostrar detalhes de tecnologia
suficientes para produzir e implementar o banco de dados.
o Limitações de diagramas e modelos ER
 Apenas para dados relacionais: entenda que o objetivo é mostrar as relações.
Diagramas ER mostram apenas essa estrutura relacional.
 Não é para dados não estruturados : a menos que os dados sejam claramente
delineados em diferentes campos, linhas ou colunas, diagramas ER são, provavelmente,
de uso limitado. O mesmo vale para dados semiestruturados, pois apenas alguns dos
dados terão utilidade.
 Dificuldade ao integrar com um banco de dados existente: devido às diferentes
arquiteturas, o uso de modelos ER para integração com um banco de dados pode ser
dificultoso.

1.13 Notação BPMN.

BPM

o Processo: Processo é uma agregação de atividades e comportamentos executados por humanos ou

máquinas para alcançar um ou mais resultados.
o Negócio: O termo negócio refere-se a pessoas que interagem para executar um conjunto de atividades de
entrega de valor para os clientes e gerar retorno às partes interessadas.
o Processo de negócio: é um trabalho que entrega valor para os cliente ou apoia/gerencia os outros
processos que agregam valor. Esse trabalho pode ser ponta a ponta, interfuncional e até mesmo
interorganizacional.
o O gerenciamento de processos de negócio não é uma metodologia de trabalho que contém um
conjunto de ferramentas para melhoria dos processos. E SIM uma abordagem gerencial
adaptável, desenvolvida com a finalidade de sistematizar e facilitar processos organizacionais
individuais complexos, dentro e fora das empresas.
o Gerenciamento de processos de negócio – BPM: Disciplina gerencial que integra estratégias e objetivos
de uma organização com expectativas e necessidades de clientes, por meio do foco em processos ponta a
ponta. BPM engloba estratégias, objetivos, cultura, estruturas organizacionais, papéis, políticas, métodos e
tecnologias para analisar, desenhar, implementar, gerenciar desempenho, transformar, e estabelecer
governança de processos.
o Tipos de Processos:
o Principais: Qualquer processo que se relaciona com o cliente e está diretamente ligado ao
Negócio. Ex: Marketing, Fabricação de produtos, Suporte ao Cliente, Comercialização etc.
o Suporte: Processos que apoiam os processos principais e outros processos de suporte. Ex: Folha
de Pagamento, Pagamento de Contas, Suporte de TI, Compras, manutenção predial etc.
o Gestão: Processos que gerenciam os processos Principais ou de Suporte. Ex: Gerenciamento de
projetos, de custos, de atividades, da estratégia etc.
o Dono do Processo: Pode ser uma pessoa ou um grupo de pessoas com a responsabilidade e a prestação
de contas pelo desenho, execução e desempenho de um ou mais processos de negócio. A propriedade dos
processos pode ser uma responsabilidade em tempo integral ou parcial.
o Cliente: Todas as pessoas que consomem ou utilizam os produtos / serviços fornecidos por organizações
privadas, públicas ou sem fins lucrativos / Todo aquele que percebe valor nos produtos / serviços prestados.
o Modelagem de processos de negócios combina um conjunto de habilidades e técnicas que permite
compreender, comunicar e gerenciar os componentes de processos de negócio. Pode ter uma
perspectiva de ponta-a-ponta ou segmentada; • Desde a visão mais abstrata até a mais operacional
(depende do objetivo);
o Proposito da modelagem de processos:
o Documentar claramente os processos;
o Avaliar os padrões e conformidades requeridas;
o Servir de base para análise e identificação de melhorias;
o Desenhar novo processo para um processo existente;
o Descrever requisitos para nova operação do negócio;
o Cumprir com o decreto 4130/2017.
o BPMN (Business Process Model and Notation): Notação da Object Management Group (OMG) para
representar a modelagem de processos de negócio. Segundo a própria OMG – mantenedora da notação,
BPMN é uma notação gráfica que permite descrever as etapas e o fluxo ponta a ponta de um processo de
negócio.
o BPMS(Business Process Management Suite): Software/Sistema auxiliar na realização de BPM. Um BPMS
é uma ferramenta complexa que, em linhas gerais, é responsável pela realização de grande parte do ciclo de
vida do gerenciamento de processos de negócio.
o Objetivos BPMN:
o BPMN surgiu como resposta à necessidade de poder executar os processos;
o Anteriormente as ferramentas de BPM usavam suas próprias notações;
o BPMN é a chave para um entendimento comum dos processos entre TI e negócios;
o Semântica precisa e completa;
o Facilita a comunicação;
o Padronização e reutilização. (padrão adotado mundialmente).
o Notações:
 Piscina (pool): Os processos estão contidos dentro de uma piscina.
 Raia (lane): Definem as equipes de pessoas que realizam as atividades e tarefas; OU • Uma área
funcional pode ser responsável por muitas tarefas; São utilizadas como uma forma de organização e
uma ajuda para uma visualização gráfica do processo.
 Eventos: Um evento representa algo que ocorre ou pode ocorrer durante o curso de um processo.
Existem três tipos de eventos:

 Atividade: (Retângulo com bordas arredondadas) Representam o trabalho realizado dentro de

uma organização. Os tipos de atividades são:
 Desvio/Gateway (Losango): Os gateways são elementos utilizados para controlar pontos de
divergência e convergência de um fluxo. Os tipos de gateway são:


 Fluxo de sequência (Seta): Representam o controle do fluxo e a sequência das atividades. São
utilizados para representar a sequência dos objetos de um fluxo onde se encontram as atividades,
os gateways e os eventos.
 Fluxo de mensagem (seta pontilhada): Representam a interação entre várias entidades ou
processos distintos; • É usado para mostrar um fluxo de mensagem entre duas entidades que
estão preparadas para enviá-las e recebê-las; • Em BPMN isso é representado por dois “Pools”
diferentes conforme a figura abaixo:
 
 Sub-Processo:
o É uma atividade composta, incluída dentro de um processo
o É composta por um conjunto de atividades em uma sequência lógica (processo) para
garantir que essas atividades possam ser analisadas em um nível mais detalhado
o Pode ser observada de forma expandida ou minimizada.

 Boas práticas:
o Fluxo de sequência: Da esquerda para a direita OU de cima para baixo.
o Fluxos de mensagem como linhas verticais.
o Pontos de divergência e convergência devem ser abertos e fechados usando os
gateways apropriados
o Recomenda-se usar verbos no infinitivo para os nomes das atividades. Ex: “Aprovar
solicitação de viagem”
o Evitar uso de cargos e funções no nome de raias (lanes)
o Procure manter coerência entre os nomes das raias em um mesmo diagrama
o Não devem ser atribuídos ações de tarefas aos nomes dos gateways
o Evite usar mais de um evento de início
o Utilize quantos eventos de fim forem necessários
o Evitar cruzar os objetos de fluxo
o Procure agrupar conjunto de atividades em subprocessos sempre que necessário
o Utilize artefatos de dados, anotações e grupos com moderação

De acordo com a BPMN, o símbolo precedente descreve: Uma tarefa coreografia representa um participante inicial
que envia uma mensagem para um participante receptor. Tarefas de coreografia podem conter mensagens e outros
recursos. Tarefas de coreografia podem ser sequenciadas juntamente com outras tarefas de coreografia. Também é
possível vincular participantes de um modelo diferente à tarefa de coreografia. É possível especificar uma
mensagem inicial assim como a resposta do participante receptor, com ou sem uma mensagem.

Em BPMN, o símbolo representa um fluxo de informação que ultrapassa as fronteiras internas e

externas de uma organização. (CERTO)

Fluxos de mensagens são usados para mostrar a comunicação entre participantes, porém não podem se conectar a
objetos que estejam dentro da mesma pool. (CERTA)

setas tracejadas para conectar as figuras básicas, representando o controle do fluxo e a sequência das atividades.
(ERRADA)

fluxo de mensagem é para conectar objetos entre pools diferentes e processos que apesar de estar na mesma pool,
estão em lanes diferentes (ERRADA)

No fluxo de processos na notação BPMN, o ponto de ramificação mostrado na seguinte figura indica que todos os
fluxos de saída são ativados simultaneamente. (CERTO)

Por meio da modelagem de processos em BPMN, é possível entender, coletando-se dados, o que levou
determinado processo a não entregar ao cliente final o resultado esperado. Essa análise, conhecida como análise
da causa-raiz, permite identificar o problema por meio de redesenho do processo. (ERRADO) pois A análise de
causa raiz é uma técnica de análise dos processos que permite descobrir post mortem o que causou o
resultado.

Na modelagem de processos embasados na notação BPMN, um ponto de tomada de decisão é representado por
meio de um círculo. (ERRADO) pis decisão é LOSANGO

BPMN (Business Process Modeling Notation) é uma ferramenta responsável pela realização de grande parte do
ciclo de vida do gerenciamento de processos de negócio. (ERRADO) pois correto é BPMS.

O BPMN é uma metodologia que permite a construção de modelos lógicos para a automação de processos.
(ERRADA)

O BPMN (Bussiness Process Management Notation) registra um conjunto de notações utilizadas para o
mapeamento de processos. (Certa)

Ao fazer a modelagem de negócio de uma empresa, um analista identificou a necessidade de realizar a modelagem
dos processos. As linguagens gráficas destinadas a essa tarefa são:   a) BPMN, Diagrama de Atividades/UML e
EPC/Aris EPC (linguagem proprietária usada no programa ARIS)

A partir da implantação do BPM na organização, é possível avaliar como os processos são executados, o que
permite propor ajustes que visem à melhoria contínua deles. (CERTO)

No BPM, uma função de negócios descreve um grupo de atividades e competências especializadas; as atividades
são conjuntos de tarefas necessárias para entregar uma parte específica e definível de um produto ou serviço.
(CERTO)

A modelagem de processos de negócio em BPMN utiliza o mesmo diagrama de atividades da UML, que é usado
para modelagem de sistemas.(ERRADO)
1.14 Conceitos e ferramentas de DevOps.
 Significa Desenvolvedores e Operadores
 O DevOps é uma metodologia que visa a integração entre os setores de desenvolvimento e operações.
O objetivo é agilizar e otimizar a criação e o gerenciamento da estrutura das aplicações.
 O DevOps serve para organizar os processos internos de uma empresa, unindo aquilo que antes se
encontrava em isolamento. Assim, operações, desenvolvimento, qualidade e segurança atuam de forma
coordenada.
 É possível pensar na organização de uma forma mais sistêmica e focar nas necessidades do cliente.
 DevOps permite maior agilidade nas entregas.
 Com a junção das equipes, é possível controlar todo funil operacional, otimizando todas as fases de
desenvolvimento: do brainstorming até os testes finais.
 No DevOps, erros são valorizados, vistos como oportunidades de melhoria. A cultura que impera é de
experimentação. A colaboração, aqui, é a chave para tudo.
 Gera fluidez e produtos melhores.
 Não há silos de conhecimento ou produção.
 Não há um guia prático do que fazer, pois a metodologia se encaixa às necessidades do seu negócio.
 A cultura DevOps sustenta-se nos seguintes pilares:
o Integração Contínua: fácil transferência de conhecimento e experiências entre as áreas de
Desenvolvimento, Operações e Apoio.
o Implantação Contínua: liberação rápida e contínua de novas versões de software ou serviços.
o Feedback contínuo: feedbacks frequentes das equipes envolvidas em todas as fases do ciclo de
vida do software ou serviço.
 Vantagens:
o Minimização de conflitos
o Comunicação eficaz
o Confiabilidade e segurança
o Redução do tempo de entrega
o Aumento da qualidade
o Economia de recursos
o Aumento da motivação dos colaboradores
 Como implementar:
o Automação de tarefas repetitivas com tecnologia cloud computing
o Integração nas reuniões: Unir duas áreas: desenvolvimento e operação
o Dinamismo dos ambientes: Para garantir que estejam sempre disponíveis, os ambientes precisam
ser dinâmicos. Ou seja, devem ser criados sempre que necessário em processos automatizados. É
importante que o desenvolvimento tenha a infraestrutura ideal para seu trabalho sem intervenção
das operações.
 Exemplos de tecnologia DevOps:
o Slack: O Slack é um aplicativo essencial para times DevOps, seja àqueles no escritório como para
equipes remotas. A plataforma de comunicação oferece um dashboard simples, mas bem
completo, favorecendo a comunicação interna . As conversas em grupos se dão em canais
específicos, que podem ser personalizados. Assim, é possível dividir os setores, os gerentes e os
projetos em canais específicos, sem tumultuar.
o GIT: O Git é um sistema de controle de versão distribuído, o que significa que sua cópia local do
código é um repositório de controle de versão completo. Esses repositórios locais facilitam o
trabalho offline ou remoto. Assim, você confirma seu trabalho localmente e, em seguida, sincroniza
sua cópia do repositório com a cópia no servidor. Esse paradigma difere do controle de versão
centralizado, onde os desenvolvedores devem sincronizar o código com um servidor antes de criar
novas versões dele.
Com a solução Azure, da Microsoft, é possível criar e configurar fluxos de trabalho no seu
repositório. Assim, você pode testar, empacotar, lançar e implantá-los no Azure.
o Bamboo: O BamBoo é um server de CI e CD que automatiza compilações, testes e lançamentos
em um único fluxo de trabalho. Com a solução, é possível criar planos de compilação de vários
estágios, configurar gatilhos para iniciar compilações sobre confirmações e atribuir agentes para
suas compilações e implantações críticas.
o Docker: O Docker é uma ferramenta que possibilita a você empacotar uma aplicação (ou um
ambiente inteiro) em um container. Dessa forma, torna os projetos mais flexíveis ao “portabilizá-
los”, podendo utilizar o conteúdo empacotado em qualquer host que tenha o Docker. É uma
ferramenta essencial para reduzir o tempo de deploy.O motivo é simples: com o ambiente já
configurado, é possível replicá-lo quantas vezes você quiser,ou seja, com total flexibilidade para a
produção seguir em alta! As alterações efetuadas em arquivos ou diretórios dentro de um
container são isoladas e não podem ser vistas fora dele. O modelo de conectividade padrão do
docker é menos vulnerável a ataques de segurança do tipo negação de serviço (DoS) do que o
modelo de máquinas virtuais (VM), uma vez que os contêineres são uma camada de isolamento
entre os aplicativos e o kernel do host. (ERRADO) pois Docker permite criar e gerenciar redes
através de software. As redes Docker se comportam como redes físicas e os contêineres se
comportam como servidores conectados a estas redes. Ou seja, ainda precisa de segurança
como qualquer rede.

Para tornar a integração contínua mais efetiva no DevOps, é recomendável centralizar todos os commits
em uma máquina de integração. (CERTO)

O gerenciamento de desenvolvimento de software por meio do Scrum pode ser combinado com o ciclo de
vida do DevOps, haja vista que o DevOps combina práticas e ferramentas que aumentam a capacidade
de uma organização de distribuir aplicativos e serviços; logo, a integração contínua do software pode ser
realizada na sprint do Scrum junto com a operação dos serviços da organização.(CERTO)

A infraestrutura como código é uma prática DevOps caracterizada pela infraestrutura provisionada e
gerenciada por meio de técnicas de desenvolvimento de código e de software, como, por exemplo,
controle de versão e integração contínua. (CERTO)

A técnica de integração contínua, de uso fundamental para DevOps, estabelece que o código seja
 compilado para cada mudança e que sejam executados testes automatizados minimamente confiáveis. 
(CERTO)

DevOPS é um conjunto de ferramentas e práticas de trabalho para integração entre os colaboradores dos
grupos de desenvolvimento de código, de operações e de apoio, e pode ser utilizado na produção rápida
e segura de aplicações e serviços.(CERTO)
Devops é um termo criado para descrever um conjunto de práticas para integração entre as equipes de
desenvolvimento de softwares, operações (infraestrutura ou sysadmin) e de apoio envolvidas (como
controle de qualidade) e a adoção de processos automatizados para produção rápida e segura de
aplicações e serviços.

1.15 Técnicas de Integração e Implantação Contínua de Código (CI/CD).

o CI/CD nada mais é do que um método para entregar aplicações com frequência aos clientes. Ele prevê a
implementação da automação nas etapas de desenvolvimento de aplicações.
o O CI/CD se baseia em três conceitos básicos:
o Integração contínua (CI): (processo de automação para desenvolvedores). Ela é ideal para evitar
conflitos entre ramificações no repositório de controle de versão quando há desenvolvimento
simultâneo de várias aplicações. Para que seja bem-sucedida, requer desenvolvimento, testes e
consolidação frequentes de mudanças no código de uma aplicação. Esta é uma etapa importante
já que se inicia o ciclo (no desenvolvimento) do pipeline, e assim, é possível formalizar a
diminuição do tamanho do lote a cada contribuição frequente de código. Tudo é testado, incluindo
classes, funções e diferentes módulos que formam toda a aplicação. Se houver conflito entre os
códigos novos e existentes, a CI facilita a correção desses bugs com rapidez e frequência.
o Entrega/Deploy contínua (CD): Ambos tratam da automação de fases avançadas do pipeline,
mas podem ser usados de forma separada para ilustrar o nível de automação presente.
o Implantação contínua: A etapa final de um pipeline de CI/CD é a implantação contínua. Ela
automatiza o lançamento de uma aplicação para a produção e depende muito da automação
otimizada dos testes.
o Um dos grandes benefícios do CI/CD é solucionar os problemas gerados na integração de novos códigos
(famoso inferno de integração), dando mais tranquilidade e eficiência às equipes de operações e
desenvolvimento e Diminuir o risco da implantação de aplicações; Facilitar o lançamento das mudanças em
pequenas partes.

Ter como referência o conceito de entrega contínua ou CD (continuous delivery), realizada por um
processo integrado e automatizado de desenvolvimento, teste de software e operações. (CERTO)
2. Requisitos e Experiência do Usuário.

Engenharia dos requisitos:

 O planejamento é o primeiro estágio essencial no processo de gerenciamento de requisitos e determina o

nível de detalhamento requerido no gerenciamento de requisitos. (E não quando começa e termina o
gerenciamento de requisitos
 O intuito do modelo de análise é fornecer uma descrição dos domínios de informação, funcional e
comportamental necessários para um sistema baseado em computadores. O modelo se modifica
dinamicamente à medida que você aprende mais sobre o sistema a ser construído e outros
interessados adquirem um melhor entendimento sobre aquilo que eles realmente querem.
 Conceito Analise de Requisitos: É a encarregada por reunir dados necessários e indispensáveis que o
usuário precisa para resolver um problema. e atingir seus objetivos, da mesma maneira que definir as
expectativas de um usuário para certo projeto.
 Porque análise de requisitos:
o O levantamento e análise de requisitos (as condições reunidas) precisam ser detalhadas,
quantitativas e importantes para o projeto, uma vez que elas darão a referência para autenticar o
produto final, determinarão o acordo entre fornecedor e cliente a respeito do que o software de
análise de requisitos realizará e, portanto, diminuirão os custos de criação, pois condições mal
determinadas provocam um retrabalho. Sobre esse cenário, são importantes o envolvimento e a
comunicação frequentes com os usuários do software, uma vez que eles intervirão no resultado do
produto final.
o O estudo da viabilidade vem ANTES do levantamento de requisitos, por isso, não tem
como o estudo de viabilidade gerar relatórios a partir dos requisitos!
 Exemplos de funções de Analise de Requisitos:
o 1) Identificar o problema: nessa etapa está a descrição do sistema, o planejamento e o
relacionamento do analista com o usuário com o propósito de compreender o ponto de vista do
cliente sobre o problema.
o 2) Estudar o problema e o resumo da solução: com a compreensão do problema, realiza-se o
reconhecimento das informações necessárias para o usuário, detecta as informações necessárias
para o sistema e escolhe a melhor solução viável entre todas as soluções propostas.
 o 3) Modelar: método utilizado para a base do resumo da solução. O modelo apresenta ferramentas
que simplificarão a percepção do sistema, como as informações, funcionalidades e
comportamento.
o 4) Informar as condições: estabelecer as interfaces, funções, performance, o cenário e as
limitações do sistema.
o 5) Revisar: juntos, analista e cliente, analisarão o propósito do projeto com a intenção de cortar
possíveis repetições, omissões e inconsistências do sistema, adquirindo uma mesma perspectiva.
 Durante o processo de validação de requisitos, diferentes tipos de verificação devem ser efetuados com os
requisitos no documento de requisitos. Essas verificações incluem:
o 1. Verificações de validade. Um usuário pode pensar que é necessário um sistema para executar
determinadas funções. No entanto, maior reflexão e análise mais aprofundada podem identificar
funções necessárias, adicionais ou diferentes. Os sistemas têm diversos stakeholders com
diferentes necessidades, e qualquer conjunto de requisitos é inevitavelmente um compromisso da
comunidade de stakeholders.
o 2. Verificações de consistência. Requisitos no documento não devem entrar em conflito. Ou seja,
não deve haver restrições contraditórias ou descrições diferentes da mesma função do sistema.
o 3. Verificações de completude. O documento de requisitos deve incluir requisitos que definam
todas as funções e as restrições pretendidas pelo usuário do sistema.
o 4. Verificações de realismo. Usando o conhecimento das tecnologias existentes, os requisitos
devem ser verificados para assegurar que realmente podem ser implementados. Essas
verificações devem considerar o orçamento e o cronograma para o desenvolvimento do
sistema.
o 5. Verificabilidade. Para reduzir o potencial de conflito entre o cliente e o contratante, os
requisitos do sistema devem ser passíveis de verificação. Isso significa que você deve ser capaz
de escrever um conjunto de testes que demonstrem que o sistema entregue atende a cada
requisito especificado.
 Etnografia: técnica de observação E ENTREVISTA que pode ser usada para compreender os processos
operacionais e ajudar a extrair os requisitos de apoio para esses processos. Um analista faz uma imersão no
ambiente de trabalho; O trabalho do dia a dia é observado; Descobre requisitos implícitos; Pode ser
combinada com a prototipação;
 Para a correta aplicação da técnica de validação determinada, um moderador deve determinar que o autor
de um requisito apresente o requisito e forneça, entre outras informações, justificativas para suas decisões,
de modo a apoiar a discussão entre os participantes da sessão. Uso da técnica de Walkthroughs são
realizados através de uma execução passo a passo de um procedimento ou programa (no papel), com a
finalidade de encontrar erros.
 A Disponibilização da Função de Qualidade (QFD) identifica três requisitos:
o Requisitos Normais: são os coletados em reuniões com o cliente.
o Requisitos Esperados: são os implícitos e fundamentais. Ex: são aqueles que o cliente não
precisa dizer, pois se subentende que o software deverá prover.
o Requisitos Fascinantes: que vão além da expectativa dos clientes.

Um modelo de projeto visa possibilitar o entendimento e o refino dos requisitos. O foco durante o projeto são
apenas os requisitos funcionais. As classes no projeto são conceituais e são especificadas sem considerar a
linguagem de programação que será usada na implementação.(ERRADO) pois a análise é algo mais geral, já o
PROJETO precisa de mais detalhamento, inclusive com considerações sobre como a solução será implementada

2.1 Elicitação e Gerenciamento de Requisitos, design thinking.

 Elicitação de requisitos é uma fase do projeto onde são extraídas informações do cliente sobre o que ele
deseja que seja construído. É a fase em que o profissional de TI entende a necessidade do cliente e o
orienta. É o momento de conversa com o usuário, de sentimento sobre o que este espera que seja entregue
a ele. Na elicitação de requisitos são percebidas as necessidades do sistema e as características que esse
sistema deve ter.
 Requisitos não-funcionais são os requisitos relacionados ao uso da aplicação em termos de desempenho,
usabilidade, confiabilidade, segurança, disponibilidade, manutenção e tecnologias envolvidas.
 Requisito funcional define uma função de um sistema de software ou seu componente.
 O plano para a implementação dos requisitos funcionais é detalhado no projeto do sistema.
 Já o plano para a implementação de requisitos não funcionais é detalhado na arquitetura do sistema.
 O documento de requisitos deve ser elaborado a partir da análise de viabilidade do software, seguida de
análise, especificação e validação de requisitos.
 Tipos de requisitos:
o Requisitos Normais: refletem os objetivos e metas estabelecidos para um produto ou sistema
durante reuniões com o cliente. Se esses requisitos estiverem presentes, o cliente fica satisfeito.
Exemplos de Requisitos Normais poderiam ser tipos de displays gráficos solicitados, funções de
sistema específicas e níveis de desempenho definidos.
 o Requisitos Esperados: estão implícitos no produto ou sistema e podem ser tão fundamentais que
o cliente não os declara explicitamente. Sua ausência será causa de grande insatisfação.
Exemplos de Requisitos Esperados: facilidade na interação homem-máquina, confiabilidade e
correção operacional global e facilidade na instalação do software.
o Requisitos Fascinantes: esses recursos vão além da expectativa dos clientes e demonstram ser
muito satisfatórios quando presentes. Por exemplo, o software para um novo celular vem com
recursos-padrão, mas junto vem um conjunto de capacidades não esperadas. Exemplos de
Requisitos Fascinantes: tecla multitoque e correio de voz visual
o

Situação hipotética: Como forma de obter os requisitos de apoio para desenvolver um sistema a
ser implementado em determinado setor de uma organização, um analista propôs que se
observasse o trabalho do dia a dia, anotando-se as tarefas realizadas no referido
setor.Assertiva: Para o cenário proposto, é ideal a utilização da técnica de ETNOGRAFIA,
também chamada de técnica de observação, na qual um analista social se insere no ambiente
de trabalho onde o sistema será implantado e analisa como as pessoas trabalham no seu dia a
dia.

 Existem dois tipos de documentos:

o Documento de Definição de Requisitos, ou somente Documento de Requisitos: deve ser
escrito de maneira que o cliente possa entender, i.e., na forma de uma listagem do quê o cliente
espera que o sistema proposto faça. Ele representa um consenso entre o cliente e o
desenvolvedor sobre o quê o cliente quer. (Trata de requisitos de usuários)
o Documento de Especificação de Requisitos: redefine os requisitos de usuário em termos mais
técnicos, apropriados para o desenvolvimento de software, sendo produzido por analistas de
requisitos. (Trata de requisitos de sistema)
 As atividades do processo de elicitação de requisitos são :

1. Descoberta de requisitos. Essa é a atividade de interação com os stakeholdersdo sistema para

descobrir seus requisitos. Os requisitos de domínio dos stakeholderse da documentação também são
descobertos durante essa atividade. Existem várias técnicas complementares que podem ser usadas para
descoberta de requisitos, que discuto mais adiante.

2. Classificação e organização de requisitos. Essa atividade toma a coleção de requisitos não

estruturados, agrupa requisitos relacionados e os organiza em grupos coerentes. A forma mais comum de
agrupar os requisitos é o uso de um modelo de arquitetura do sistema para identificar subsistemas e associar
requisitos a cada subsistema. Na prática, a engenharia de requisitos e projeto da arquitetura não podem ser
atividades completamente separadas.

3. Priorização e negociação de requisitos. Inevitavelmente, quando os vários stakeholders estão

envolvidos, os requisitos entram em conflito. Essa atividade está relacionada com a priorização de requisitos
e em encontrar e resolver os conflitos por meio da negociação de requisitos. Normalmente, os stakeholders
precisam se encontrar para resolver as diferenças e chegar a um acordo sobre os requisitos.

4. Especificação de requisitos. Os requisitos são documentados e inseridos no próximo ciclo da espiral.

Documentos formais ou informais de requisitos podem ser produzidos

 LEMBRETE: Não há nenhuma atividade de identificação, rastreabilidade e mudanças em requisitos.

 As técnicas estáticas de verificação centram-se na análise manual ou automatizada do código-
fonte do programa, enquanto a validação dinâmica tem por objetivo identificar defeitos no
programa e demonstrar se ele atende a seus requisitos.
 O processo de engenharia de requisitos, segundo Sommerville, é composto pelas seguintes
etapas e correspondentes artefatos gerados:
o 1a Etapa: Estudo de viabilidade. Artefato: relatório de viabilidade.
o 2a Etapa: Elicitação de requisitos. Artefato: Modelos de sistema
o 3a Etapa: Especificação de requisitos. Artefato: Requisitos de usuário e sistema
o 4a Etapa: Validação de requisitos. Artefato: Documento (formal) de requisitos.
o (ATENCAO: Mas na visão espiral, tem-se Elicitação, Especificação, Validação (Revisão,
protototipação, Estudos de viabilidade)
 A rastreabilidade de requisitos pode ser de 3 tipos:
o a) rastreabilidade de origem: que relaciona o requisito com o stakholder, que visa identificar a origem
do requisitos em caso de necessidade de alterações nele.
o b) rastreabilidade de requisitos: que relaciona os requisitos interdependentes, para identificação do
grau de impacto da alteração do requisitos nos demais selecionados; e
o c) rastreabilidade de projeto: que relaciona o requisito com demais elementos do projeto, que os
anteriores como arquitetura, módulos executáveis, e etc, permite identificar o grau de impacto de
mudança no requisito em relação ao projeto como um todo.
 Ferramenta/Técnica de Gestão de Melhoria de Processos
 o Modelo AS/IS: é a definição da situação atual do processo organizacional ou de negócios. Os
participantes desse mapeamento são os usuários envolvidos no dia a dia do processo (key users).
Nesse contexto, uma boa prática é solicitar ao executor do processo que relate como executá-lo, ou
então é feito um questionário para levantar as informações. Destacamos que, justamente por mostrar
como os processos funcionam no presente, o processo AS IS indica o que pode ser melhorado (e não
como fazê-lo).
o Modelo To/Be: é a definição da situação futura do processo organizacional ou de negócios, ou seja,
onde se quer chegar. Ele esclarece como, estruturalmente, pode-se alcançar o estado desejado nos
processos.
o É também onde documentamos o que ficou definido do mapeamento com o auxílio de ferramentas que
agregam valor ao processo, como tecnologias BPM (Business Process Management). Os participantes
dessa definição geralmente são pessoas que possuem experiências com o mesmo tipo de processo.
Além disso, estão aptas a contribuírem na otimização dos processos para melhor aderência às práticas,
aos objetivos da organização e aos sistemas de apoio.
o Objetivos do AS/IS e TO/BE:
o Enquanto o mapeamento de processos AS IS tem como vantagem ajudar a equipe a
visualizar precisamente os processos de uma organização – bem como as áreas de risco – o
TO BE tem como benefício a modelagem do impacto de mudanças futuras no processo antes
de realmente realizá-las.
o Tenha em mente que a ferramenta AS IS/TO BE deve focar no amadurecimento do processo
de modo que ao final da etapa TO BE ele esteja:
o Cada vez mais aderente aos objetivos estratégicos da organização e
o Estruturado de forma a simplificar e trazer eficácia aos processos e suas atividades , sejam
elas no âmbito estratégico ou operacional.
o Para que estes objetivos sejam alcançados, é fundamental o envolvimento e engajamento de
todos os participantes e o foco diário na melhoria contínua, além da adoção de uma solução
eficiente de Gestão de Processos.
o Etapas do mapeamento:
o Defina os usuários chaves e/ou dono do processo
o Identifique e mapeie processos (levantamento do processo AS IS)
 1 – Definir usuários-chave:
 2 – Reunião de Kick-off: trata-se de uma reunião geral com os usuários-chave
 3 – Coleta de anexos: usuário mostrar esse passo na reunião inicial.
 4 – As entrevistas: o ponto principal aqui é a coleta de dados e a identificação de
micro processos no ambiente alvo, que pode ser uma atividade em específico, um
processo de um cliente etc.
o Redesenhe processos (modelagem do processo TO BE): Uso da ferramenta BPM
o Consenso com o cliente: Etapa de ratificação do cliente
o Analise de Efetividade: Pesquisa de satisfação e utilizar indicadores de eficiência x eficácia de
produtividades das saídas mapeadas

• Tipos de Requisitos:

o Requisitos do Sistema: Funcionais ou seja, necessidades do cliente, descrevem o que o sistema

deve fazer. são restrições sobre as funções ou serviços oferecidos pelo sistema. Esses requisitos
consideram as declarações de serviços, a forma do sistema reagir.
o Requisitos de Software: Não funcionais, aquele que descreve não o que o sistema fará, mas COMO ele
fará. Estão diretamente relacionados às funções específicas fornecidas pelo sistema. e como ele deve se
comportar em determinadas situações.
o os requisitos de sistema devem ser elicitados antes, pois irão servir para encontrar os requisitos
de software. Ambos os requisitos devem ser consistentes, não ambíguos e verificáveis. 
 Uma entrevista pode ser aberta ou fechada
o Entrevista Aberta, não existe um roteiro a ser seguido, o entrevistador explora vários assuntos e busca
uma compreensão mais ampla das necessidades;
o -Entrevista Fechada, o entrevistado responde a um conjunto de perguntas específicas e pré formuladas
(Tem Roteiro)
 Tipos de Entrevistas: Podem ser classificadas de acordo com dois aspectos: controle do informante e a
uniformidade de estímulos apresentados;
o Nas entrevistas não-estruturadas, o entrevistador segue o informante, mas faz perguntas ocasionais
para ajustar o foco ou para clarificar aspectos importantes. O pesquisador tem geralmente um guia com
os tópicos a serem cobertos na entrevista, mas não tem uma ordem para perguntar sobre estes tópicos;
o Nas entrevistas semi-estruturadas, este guia contém sugestões de perguntas e dicas (prompts) a
serem usados pelo pesquisador para garantir que todos os tópicos de interesse serão abordados;
o Nas entrevistas estruturadas, o entrevistador quer ter certeza que ele faz as mesmas perguntas para
cada informante. As perguntas estão claramente definidas; No questionário, as perguntas e as
respostas já estão definidas. Um questionário pode ser respondido face a face ou remotamente;
 Os critérios de qualidade segundo o padrão IEEE 830 referente à gerência de qualidade de requisitos são:
 o Correção: um documento de requisitos é considerado correto se todos os requisitos representam algo
que deve estar presente no sistema que está sendo desenvolvido, ou seja, os requisitos reais do
usuário devem coincidir com os requisitos identificados. Esta não é uma tarefa trivial e parte de seu
sucesso está associada a uma boa atividade de validação dos requisitos.
o Não ambiguidade: um conjunto de requisitos é não ambíguo quando somente pode ser interpretado
por todos os envolvidos em um projeto de uma única maneira.
o Completude: um conjunto de requisitos é dito completo quando descreve todas as demandas de
interesse dos usuários. Estas demandas incluem requisitos funcionais, de desempenho, restrições,
atributos e interfaces externas.
o Consistência: um conjunto de requisitos é dito consistente se nenhum subconjunto destes requisitos
entra em conflito com os demais requisitos do sistema.
o Verificabilidade: um requisito é verificável se existe uma forma efetiva, em termos de tempo e custo,
para que pessoas ou ferramentas indiquem se um sistema cumpre o requisito (IEEE). Em quase todas
as situações, é difícil provar de forma conclusiva que um requisito é cumprido por um software.
Entretanto, escrever bem o requisito pode ajudar a aumentar a confiança na avaliação.
o Modificabilidade: um conjunto de requisitos é modificável quando seu estilo e estrutura é tal que as
alterações podem ser realizadas de forma simples e consistente com os demais requisitos.
 Do ponto de vista de evolução os requisitos se dividem em duas classes:

1. Requisitos Permanentes. São requisitos relativamente estáveis derivados da atividade central da

organização e que se relacionam diretamente ao domínio do sistema.

2. Requisitos Voláteis. São requisitos que provavelmente irão mudar durante o processo de
desenvolvimento do sistema ou depois que o sistema estiver em operação. Esses requisitos são divididos
em:

o Requisitos Mutáveis: requisitos que mudam devido a mudanças no ambiente no qual a

organização está operando.
o Requisitos Emergentes : requisitos que surgem à medida que a compreensão do sistema
pelo cliente progride durante o desenvolvimento do sistema.
o Requisitos Consequentes : requisitos que resultam da introdução do sistema de
computador. A introdução do sistema de computador pode mudar os processos da
organização e criar novas formas de trabalho que geram novos requisitos.
o Requisitos de Compatibilidade: requisitos que dependem de sistemas ou processos de
negócios específicos dentro de uma organização. À medida que eles mudam, os
requisitos de compatibilidade do sistema encomendado ou entregue podem também
evoluir.

2.2 Storytelling.
o Storytelling é a arte de contar, desenvolver e adaptar histórias utilizando elementos específicos —
personagem, ambiente, conflito e uma mensagem — em eventos com começo, meio e fim, para transmitir
uma mensagem de forma inesquecível ao conectar-se com o leitor no nível emocional.
o Principais elementos do Storytelling:
o Mensagem: É comum separarmos o storytelling em duas partes:
 story: a história e a mensagem a serem transmitidas;
 telling: a forma como essa mensagem é apresentada.
 Caso a mensagem seja forte, é possível que ela surta efeito mesmo com um telling
fraco. Mas, caso ela seja fraca, dificilmente você conseguirá salvar o seu conteúdo com
técnicas para contá-la.
 A ideia passada é o que pode transformar e marcar a vida das pessoas.Textos, histórias
e palestras que deixam a audiência entusiasmada momentaneamente existem aos
montes, mas conteúdos que marcam de verdade e fazem com que você continue
lembrando deles são escassos. Esses são os que conseguem conciliar as duas partes
do storytelling, ao trabalhar bem os próximos três elementos com a mensagem.
o Ambiente: Simplesmente porque os eventos precisam acontecer em algum lugar, tê-lo bem
descrito facilita que o público embarque na jornada.
o Personagem: O personagem é quem percorre toda a jornada e sofre uma transformação que leva
à transmissão da mensagem.
o Conflito: O principal fator que deixa a audiência interessada na história é o conflito: o desafio que
surge para o personagem a fim de motivá-lo a percorrer toda a jornada. Um conflito muito simples
não desperta interesse, pois não gera identificação. Afinal, onquistas muito fáceis não costumam
ser valorizadas. Ele deve ser mais elaborado e também não pode ser facilmente superado. Nesse
caso, teríamos uma história romantizada, que pode até despertar emoções, mas dificilmente gera
identificação. Portanto, o conflito deve ser elaborado e de difícil superação, a ponto de exigir a
transformação do personagem para que seja superado.

2.3 Análise de personas (papéis, perfis etc.) de usuários de software.

3. Arquitetura de Aplicações.
3.1 Padrão arquitetural Model-View-Controller (MVC).

o MVC é o acrônimo de Model-View-Controller (em português: Arquitetura Modelo-Visão-Controle - MVC) é um

padrão de projeto de software, ou padrão de arquitetura de software.
o focado no reuso de código e a separação de conceitos em três camadas interconectadas, onde a
apresentação dos dados e interação dos usuários (front-end) são separados dos métodos que interagem
com o banco de dados (back-end).
o tornou-se popular para projetar aplicações web e até mesmo para aplicações móveis, para desktop e para
outros clientes
o Componentes da MVC:
o Camada de modelo ou da lógica da aplicação (Model):
 Modelo é a ponte entre as camadas Visão (View) e Controle (Controller),
 consiste na parte lógica da aplicação, que gerencia o comportamento dos dados através
de regras de negócios, lógica e funções.
 Esta fica apenas esperando a chamada das funções, que permite o acesso para os
dados serem coletados, gravados e, exibidos.
 É o coração da execução, responsável por tudo que a aplicação vai fazer a partir dos
comandos da camada de controle (Controller) em um ou mais elementos de dados,
respondendo a perguntas sobre o sua condição e a instruções para mudá-las. O modelo
sabe o que o aplicativo quer fazer e é a principal estrutura computacional da arquitetura,
pois é ele quem modela o problema que está se tentando resolver.
 Modela os dados e o comportamento por trás do processo de negócios. Se preocupa
apenas com o armazenamento, manipulação e geração de dados. É um
encapsulamento de dados e de comportamento independente da apresentação.
o Camada de apresentação ou visualização (View)
 Visão pode ser qualquer saída de representação dos dados, como uma tabela ou um
diagrama. É onde os dados solicitados do Modelo (Model) são exibidos.
 É possível ter várias visões do mesmo dado, como um gráfico de barras para
gerenciamento e uma visão tabular para contadores.
 A Visão também provoca interações com o usuário, que interage com o Controle
(Controller). O exemplo básico disso é um botão gerado por uma Visão, no qual um
usuário clica e aciona uma ação no Controle.
 A abordagem MVC separa a View e Model por meio de um protocolo
inserção/notificação (subscribe/notify). Uma View deve garantir que sua expressão reflita
o estado do Model. Sempre que os dados do Model mudam, o Model altera as Views
que dependem dele. Em resposta, cada View tem a oportunidade de modificar-se”.
Adiciona os elementos de exibição ao usuário: HTML, ASP, XML, Applets. É a camada
de interface com o usuário. É utilizada para receber a entrada de dados e apresentar
visualmente o resultado.
o Camada de controle ou controlador (Controller)
 Controle é o componente final da tríade, faz a mediação da entrada e saída,
comandando a visão e o modelo para serem alterados de forma apropriada conforme
o usuário solicitou através do mouse e teclado.
 O foco do Controle é a ação do usuário, onde são manipulados os dados que o usuário
insere ou atualiza, chamando em seguida o Modelo.
 O Controle (Controller) envia essas ações para o Modelo (Model) e para a janela de
visualização (View) onde serão realizadas as operações necessárias.
o Um caso prático é uma aplicação web em que a visão é um documento HTML (ou derivado) gerado pela
aplicação. O controlador recebe uma entrada GET ou POST após um estímulo do utilizador e decide como
processá-la, invocando objetos do domínio para tratar a lógica de negócio, e por fim invocando uma visão
para apresentar a saída
o Vantagens do modelo MVC:
o Como o modelo MVC gerencia múltiplos views usando o mesmo modelo é fácil manter, testar e
atualizar sistemas compostos;
o É muito simples adicionar novos clientes apenas incluindo seus views e controles;
o Torna a aplicação escalável;
o É possível ter desenvolvimento em paralelo para o modelo, visualizador e controle pois são
independentes;
o Facilita o reuso do código;
o Melhor nível de sustentabilidade, pois facilita a manutenção da aplicação;
o Fácil transformação da interface, sem que haja necessidade de modificar a camada de negócio;
o Melhor desempenho e produtividade, graças a estrutura de pacotes modulares ;
o A arquitetura modular permite aos desenvolvedores e designers desenvolverem em paralelo;
o Partes da aplicação podem ser alteradas sem a necessidade de alterar outras.
o Desvantagens do modelo MVC:
o Necessita de um tempo maior para explorar e modelar o sistema;
o Requer mão-de-obra especializada;
 o À medida que o tamanho e a complexidade do projeto crescem, a quantidade de arquivos e pastas
continuará aumentando também. Os interesses de UI (interface do usuário) (modelos, exibições,
controladores) se localizam em várias pastas, que não são formadas em grupos por ordem
alfabética.

O modelo de arquitetura modelo-visão-controlador (MVC) é responsável por encapsular as

funcionalidades e os objetos de conteúdo. (CERTO)

Os elementos que compõem o padrão MVC representam as funcionalidades e os dados do sistema

(Model), sua forma de exibição ao usuário(VIEW) e a entrada de dados dos usuários(Controler). (CERTO)

De forma coerente com a orientação recebida do gestor, o padrão de projeto Observer pode ser adotado
para aprimorar a implementação do MVC.(CERTO) O padrão de projeto Observer é responsável por
observar e notificar a mudança de estado entre objetos distintos através de uma dependência um-para-
muitos. Este padrão possui duas formas de implementação: uma delas é fazendo uso das classes nativas
do JDK, enquanto a outra parte do princípio que o programador desenvolva suas próprias classes. Por
fim, o artigo apresenta um pequeno projeto onde há a união do padrão Observer com o MVC.

Na arquitetura modelo-visão-controlador (MVC), o controlador contém o conteúdo e a lógica de

processamento da aplicação (ERRADO)

O MVC é capaz de gerenciar múltiplos visualizadores e ter desenvolvimento em paralelo para o modelo,
com visualizadores e controles independentes. (CERTO)

O padrão MVC está relacionado à arquitetura da aplicação e, no escopo desse modelo, não está prevista
a comunicação de componentes. (ERRADO)

MVC (model-view-controller) é um padrão de arquitetura de software para implementar interfaces com o

usuário. Nessa arquitetura, o controller é responsável por (executar uma solicitação de entrada.)

Em uma aplicação de votação online desenvolvida em três camadas do tipo MVC, o controller é
responsável por transformar eventos gerados pela view em ações de negócio, alterando o model.

A arquitetura ilustrada na figura a seguir, a ser executada, por exemplo, por meio de um browser instalado
em dispositivos móveis, descreve uma arquitetura MVC (model-view-controller) que pode ser aplicada
com a utilização de REST e JavaScript. (CERTO)

O padrão MVC separa um aplicativo em três componentes principais: modelo, exibição e controlador;
sendo o modelo o componente que manipula e responde à entrada e à interação do usuário. (ERRADO) é
o controller

No padrão MVC, a camada de controle é responsável pelo controle da persistência dos controles da
aplicação. (ERRADO) é o MODEL

3.2 Sistemas de N camadas.

Cliente-Servidor

o Cliente-servidor é um modelo computacional que separa clientes e servidores, sendo interligados entre si

geralmente utilizando-se uma rede de computadores. Cada instância de um cliente pode enviar requisições
de dado para algum dos servidores conectados e esperar pela resposta. Por sua vez, algum dos servidores
disponíveis pode aceitar tais requisições, processá-las e retornar o resultado para o cliente. Apesar do
conceito ser aplicado em diversos usos e aplicações, a arquitetura é praticamente a mesma.
o foi criado tendo como base a descentralização dos dados e recursos de processamento, em oposição ao
modelo Centralizado utilizado na época em que o Mainframe dominava absoluto.
o No modelo Cliente/Servidor, conforme indicado pela figura abaixo, em uma rede de computadores, existem
uma ou mais máquinas que atuam como Servidores, disponibilizando recursos para as demais máquinas, as
quais atuam como Clientes.
 o
o A máquina servidor é um host que está executando um ou mais programas de servidor que partilham os
seus recursos com os clientes.
o Um cliente não compartilha de seus recursos, mas solicita o conteúdo de um servidor ou função de serviço.
Os clientes, portanto, iniciam sessões de comunicação com os servidores que esperam as solicitações de
entrada.

Sistemas de 2 Camadas

o No modelo de duas camadas, temos um programa que é instalado no Cliente, programa esse que faz acesso
a um Banco de dados que fica residente no Servidor de Banco de dados. Na maioria dos casos, a máquina
do Cliente é um PC rodando Windows, e a aplicação Cliente é desenvolvida utilizando-se um dos ambientes

conhecidos
o No modelo de 2 camadas, a aplicação Cliente é responsável pelas seguintes funções:
o Apresentação: O Código que gera a Interface visível do programa, que é utilizada pelo usuário
para acessar a aplicação, faz parte da aplicação Cliente. Todos os formulários, menus e demais
elementos visuais, estão contidos no código da aplicação Cliente. Caso sejam necessárias
alterações na interface do programa, faz-se necessária a geração de uma nova versão do
programa, e todos os computadores que possuem a versão anterior, devem receber a nova
versão, para que o usuário possa ter acesso as alterações da interface. Aí que começam a surgir
os problemas no modelo de 2 camadas: Uma simples alteração de interface, é suficiente para
gerar a necessidade de atualizar a aplicação, em centenas ou milhares de computadores. O
gerenciamento desta tarefa, é algo extremamente complexo e de custo elevado.
o Lógica do Negócio: Aqui estão as regras que definem a maneira como os dados serão acessados
e processados, as quais são conhecidas como “Lógica do Negócio”. Fazem parte das Regras do
Negócio, desde funções simples de validação da entrada de dados, como o cálculo do digito
verificador de um CPF, até funções mais complexas, como descontos escalonados para os
maiores clientes, de acordo com o volume da compra. Alterações nas regras do negócio são
bastante freqüentes, ainda mais com as repetidas mudanças na legislação do nosso país. O
gerenciamento desta tarefa, é algo extremamente complexo e de custo elevado.
o A outra camada, vem a ser o Banco de dados, o qual fica armazenado em Servidor da rede. Uma
aplicação desenvolvida em Visual Basic, a qual acessa um Banco de dados em um servidor
Microsoft SQL Server, é um típico exemplo de uma aplicação em 2 camadas.
o Resumindo:
o Sistemas em camadas surgiram para:
 Melhor aproveitar os PCs da empresa
 Oferecer sistemas com interfaces gráficas amigáveis
 Integrar o desktop e os dados corporativos
o Em outras palavras, permitiram aumentar a escalabilidade de uso de Sistemas de Informação
o Os primeiros sistemas cliente-servidor eram de duas camadas
 Camada cliente trata da lógica de negócio e da UI
 Camada servidor trata dos dados (usando um SGBD)

Sistemas de 3 Camadas

o Modelo em três camadas, derivado do modelo ‘n’ camadas, recebe esta denominação quando um
sistema cliente-servidor é desenvolvido retirando-se a camada de negócio do lado do cliente.
o O desenvolvimento é mais demorado no início comparando-se com o modelo em duas camadas pois é
necessário dar suporte a uma maior quantidade de plataformas e ambientes diferentes. Em contrapartida, o
retorno vem em forma de respostas mais rápidas nas requisições, excelente performance tanto em sistemas
que rodam na Internet ou em intranet e mais controle no crescimento do sistema.
o A idéia básica do modelo de 3 camadas, é “retirar” as Regras do Negócio do cliente e centralizá-las em um
determinado ponto, o qual é chamado de Servidor de Aplicações. O acesso ao Banco de dados é feito
através das regras contidas no Servidor de Aplicações. Ao centralizar as Regras do Negócio em um único
 ponto, fica muito mais fácil a atualização destas regras. O cliente não tem acesso direto ao Banco de dados,
sem antes passar pelo servidor de aplicações.

o
o Com isso as três camadas são as seguintes:
o Apresentação: Continua no programa instalado no cliente. Alterações na Interface do programa,
geram a necessidade de atualizar a aplicação em todos os computadores, onde esta está sendo
utilizada. Porém cabe ressaltar, que alterações na interface, são menos frequentes do que
alterações nas regras do negócio.
o Lógica: São as regras do negócio, as quais determinam de que maneira os dados serão utilizados.
Esta camada foi deslocada para o Servidor de aplicações. Desta maneira, quando uma regra do
negócio for alterada, basta atualizá-la no Servidor de aplicações. Após a atualização, todos os
usuários passarão a ter acesso a nova versão, sem que seja necessário reinstalar o programa em
cada um dos computadores da rede. Vejam que ao centralizar as regras do negócio em um
Servidor de aplicações, estamos facilitando a tarefa de manter a aplicação atualizada.
o Dados: Nesta camada temos o servidor de Banco de dados, no qual reside toda a informação
necessária para o funcionamento da aplicação. Cabe ressaltar, novamente, que os dados somente
são acessados através do Servidor de aplicação, e não diretamente pela aplicação Cliente.

Sistemas de 4 Camadas (Web based)

o A idéia básica do modelo de 4 camadas, é retirar a apresentação do cliente e centralizá-las em um

determinado ponto, o qual na maioria dos casos é um servidor Web.

o Próprio Cliente deixa de existir como um programa que precisa ser instalado em cada computador da rede. O
acesso a aplicação, é feito através de um Navegador web.
o Para acessar a aplicação, o cliente acessa o endereço da aplicação, utilizando o seu navegador. Por
exemplo http://www.empresa-abc.com/sistemas/cadastro.asp . Todo o acesso do cliente ao Banco de dados,
é feito de acordo com as regras contidas no Servidor de aplicações. O cliente não tem acesso direto ao
Banco de dados, sem antes passar pelo servidor de aplicações. Com isso as quatro camadas são as
seguintes:
o Cliente: Nesta caso o Cliente é o Navegador utilizado pelo usuário, quer seja o Internet Explorer,
quer seja o Netscape Navigator, ou outro Navegador qualquer.
o Apresentação: Passa para o Servidor Web. A interface pode ser composta de páginas HTML,
ASP, ou qualquer outra tecnologia capaz de gerar conteúdo para o Navegador. Com isso
alterações na interface da aplicação, são feitas diretamente no servidor Web, sendo que estas
alterações estarão, automaticamente, disponíveis para todos os Clientes. Com isso não existe a
necessidade de reinstalar a aplicação em todos os computadores da rede cada vez que uma
alteração for feita na camada de apresentação. Fica muito mais fácil garantir que todos estão
acessando a versão mais atualizada da aplicação. A única coisa que o cliente precisa ter instalado
na sua máquina, é o Navegador. O acesso ao Banco de dados, é feito através do Servidor de
aplicações.
o Lógica: São as regras do negócio, as quais determinam de que maneira os dados serão utilizados.
Esta camada está no Servidor de aplicações. Desta maneira, quando uma regra do negócio for
alterada, basta atualizá-la no Servidor de aplicações. Após a atualização, todos os usuários
passarão a ter acesso a nova versão, sem que seja necessário reinstalar o programa em cada um
dos computadores da rede. Vejam que ao centralizar as regras do negócio em um Servidor de
aplicações, estamos facilitando a tarefa de manter a aplicação atualizada.
 o Dados: Nesta camada temos o servidor de Banco de dados, no qual reside toda a informação
necessária para o funcionamento da aplicação.
o Os servidores de Aplicação, servidor Web e servidor de Banco de dados, não precisam, necessariamente,
ser servidores separados, isto é, uma máquina para fazer o papel de cada um dos servidores. O conceito de
servidor de Aplicação, Web ou Banco de dados, é um conceito relacionado com a função que o servidor
desempenha. Podemos ter, em um mesmo equipamento, um Servidor de aplicações, um servidor Web e um
servidor de Banco de dados.

Arquitetura de N Camadas

o Uma arquitetura de N camadas divide um aplicativo em camadas lógicas e camadas físicas.

o Camadas são uma maneira de separar responsabilidades e gerenciar dependências. Cada camada tem
uma responsabilidade específica. Uma camada superior pode usar os serviços em uma camada inferior,
mas não o oposto.
o As camadas são separadas fisicamente, sendo executadas em computadores separados. Uma camada
pode chamar diretamente a outra camada ou usar mensagens assíncronas (fila de mensagens).
Embora cada camada possa ser hospedada em sua própria camada, isso não é necessário. Várias
camadas podem ser hospedadas na mesma camada.
o Separar fisicamente as camadas melhora a escalabilidade e a resiliência, mas também aumenta a
latência da comunicação de rede adicional.
o Um aplicativo de N camadas pode ter uma arquitetura de camada fechada ou um arquitetura da camada
aberta:
o Em uma arquitetura de camada fechada, uma camada somente pode chamar a próxima
camada imediatamente abaixo.
o Em uma arquitetura de camada aberta, uma camada pode chamar qualquer uma das
camadas abaixo dela.
o Uma arquitetura de camada fechada limita as dependências entre camadas. No entanto, ele
poderá criar o tráfego de rede desnecessário se uma camada simplesmente passar as
solicitações para a próxima camada.
o Arquiteturas de N camadas normalmente são implementadas como aplicativos IaaS (infraestrutura como
serviço), com cada camada em execução em um conjunto separado de VMs.
o Considere uma arquitetura de N camadas para:
o Aplicativos Web simples.
o Migrar um aplicativo local para o Azure com o mínimo de refatoração.
o Desenvolvimento unificado de aplicativos em nuvem e locais.

o
o Cada camada consiste em duas ou mais VMs, colocadas em um conjunto de disponibilidade ou
conjunto de dimensionamento de máquinas virtuais. Várias VMs oferecem resiliência no caso de falha
da VM. Balanceadores de carga são usados para distribuir solicitações entre as VMs em uma camada.
Uma camada pode ser dimensionada horizontalmente adicionando mais VMs ao pool.

Na arquitetura em três camadas, a camada de apresentação define a lógica da interface do usuário. (CERTO)
Atenção pegadinha da palavra LOGICA

A principal característica da arquitetura em três camadas é a criação de aplicativos estáticos por meio do
isolamento das camadas, mas de forma a manter a dependência básica entre todas elas. (ERRADO) dinâmico

Em software desenvolvido com uma arquitetura em camadas, a manutenção das interfaces das camadas
permite o desacoplamento entre elas. (CERTO) Em uma arquitetura em camadas, cada camada só conhece a
camada de baixo, de que faz uso. A comunicação entre elas é feita pela interface da camada acionada. Dessa
forma, se a interface de uma camada é mantida, a camada acima dela não "toma conhecimento" de alterações
ou da forma de implementação de tal camada. Isso permite um desacoplamento entre as camadas.

A arquitetura em três camadas tem como principal característica ser composta por uma coleção de
computadores autônomos com, no mínimo, três sistemas operacionais diferentes, interligados por uma rede
OSI e equipados com software que permita o compartilhamento dos recursos do sistema: hardware, software e
dados. (ERRADO)
 Na arquitetura de 3 camadas, entrada do usuário, verificação, lógica de negócio e acesso a banco de dados
estão todos presentes em um mesmo lugar, onde essas camadas são organizadas. (ERRADA)

3.3 Microsserviço.
o Uma arquitetura de microsserviços consiste em uma coleção de pequenos serviços autônomos.
o Cada serviço é independente e deve implementar uma única funcionalidade comercial em um contexto
limitado. Um contexto limitado é uma divisão natural em uma empresa e fornece um limite explícito dentro do
qual um modelo de domínio existe.

o
o Os microsserviços são pequenos, independentes e fracamente acoplados. Uma única equipe pequena de
desenvolvedores pode escrever e manter um serviço.
o Cada serviço é uma base de código separado, que pode ser gerenciado por uma equipe de desenvolvimento
pequena.
o Os serviços podem ser implantados de maneira independente. Uma equipe pode atualizar um serviço
existente sem recompilar e reimplantar o aplicativo inteiro.
o Os serviços são responsáveis por manter seus próprios dados ou o estado externo. Isso é diferente do
modelo tradicional, em que uma camada de dados separada lida com a persistência de dados.
o Os serviços comunicam-se entre si por meio de APIs bem definidas. Detalhes da implementação interna de
cada serviço ficam ocultos de outros serviços.
o Suporte à programação poliglota. Por exemplo, os serviços não precisam compartilhar a mesma pilha de
tecnologia, bibliotecas ou estruturas.
o Uma arquitetura de microsserviços é um estilo moderno de arquitetura para web services, o que nos remete
a outra arquitetura: a SOA. A SOA é uma alternativa à abordagem tradicional de construção de aplicações
autossuficientes, as quais chamamos de monolíticos.
o Se forem construídos corretamente, os serviços independentes não afetarão uns aos outros, ou seja: se um
deles falhar, o restante da aplicação permanecerá em funcionamento, ao contrário do modelo monolítico.
o Vantagens:
o Redução do tempo para POC: Os desenvolvedores podem construir microsserviços usando as
ferramentas que melhor se adequa ao valor de negócios que pretendem fornecer. Combine isso
com o isolamento completo dos dados e você tem uma fórmula para prototipagem hiper-rápida.
o Propriedade de uma equipe: Ao dividir o valor comercial em uma coleção de microsserviços, uma
pequena equipe horizontal pode assumir a propriedade total de um microsserviços. Isto os capacita
e motiva a entregar um excelente produto. Em contraste, em grandes monólitos, os
desenvolvedores são jogados de tarefa em tarefa; raramente eles sentem que suas contribuições
são individualmente significativas.
o Escalável: Construído e publicado independentemente de outros elementos de aplicativo, um
microsserviços pode ser escalonado conforme a necessidade da organização (o que inclui a
redução de escala).
o Reutilizável: Uma vez construído, o microsserviços está disponível para qualquer consumidor. E
como pode ser escalado conforme necessário, um microsserviços também pode lidar com a carga
de trabalho adicional.
o Tolerante a falhas: Ao isolar seus servidores de dados e aplicativos de outros componentes, os
microsserviços podem falhar sem causar um desligamento total do produto. Como os
microsserviços são produtos menores que são lançados, gerenciados e escalonados de forma
independente, é mais fácil introduzir tolerância a falhas com este tipo de arquitetura. Torna-se mais
fácil criar um sistema mais tolerante a falhas, introduzindo tolerância a falhas nas partes menores
que constituem o sistema, ou seja, é muito mais fácil criar gradientes de experiência quando um ou
mais serviços falham sem causar uma interrupção total do sistema completo.
o Mitigação de riscos: Por definição, os microsserviços fornecem um valor comercial. E eles
mitigam o risco permanecendo independentes de outros componentes. Desta forma, o alinhamento
de seu desenvolvimento com os interesses da organização é inerente ao seu design.
o Cobrimos alguns dos benefícios dos microsserviços e, sem dúvida, é possível compreender os
prós do uso de tal arquitetura. Múltiplas equipes podem ter pipelines de integração
contínua/entrega contínua (CI/CD) independentes enquanto capitalizam diferentes habilidades,
fornecedores e tecnologia.
o Desvantagens:
o Dependência de rede: Os microsserviços se comunicam exclusivamente através de protocolos de
rede padrão, o que significa que uma interrupção de rede de qualquer tipo (muitas vezes fora do
controle de uma organização) irá interferir nas operações comerciais. E, conforme o número de
microsserviços implantados cresce, cresce também o risco de uma interrupção da rede, colocando
um desses serviços em risco. Por outro lado, a rede também significa que a latência é introduzida
no sistema, e isso precisa ser contabilizado. Nenhum usuário final gosta de esperar segundos para
ver o saldo de suas contas simplesmente porque as comunicações em rede se tornaram mais
lentas.
o Sobrecarga: Com os microsserviços, você divide um produto grande em uma constelação de
produtos menores. Como resultado, há uma sobrecarga criada no gerenciamento desta
constelação. Esta é, de fato, uma das razões pelas quais muitas organizações não estão prontas
para adotar plenamente os microsserviços. Além disso, cada microsserviços requer seus próprios
processos DevOps. À medida que o número de microsserviços dentro de uma organização cresce,
cresce também a quantidade de manutenção e monitoramento necessários para mantê-los.
o Muitas dependências: Imagine centenas de componentes de aplicativo contando um
microsserviços com um contrato estabelecido (especificação de API). E agora imagine que a
equipe de microsserviços queira reprojetar (ou mesmo modificar ligeiramente) suas especificações.
Não só a organização deve coordenar esta mudança através de uma miríade de equipes, mas
também deve rastrear quem depende de quem em todo momento.
o Contratos rígidos: Indo mais direto ao ponto acima, os desenvolvedores devem ter o cuidado de
definir uma especificação de API de microsserviços robusta o suficiente para fornecer valor
comercial muito tempo após o lançamento inicial. Esse tipo de previsão é raro, se impossível em
algumas organizações, que torna os microsserviços uma venda mais difícil.
o Muito fácil de lançar: Este é um cenário de ponto forte como ponto fraco. A capacidade de
implementar e incorporar microsserviços de forma tão simples pode levar ao excesso de zelo.
Aplicar tantos microsserviços antes que uma organização compreenda totalmente as
compensações pode levar a uma reprojeção falhada ou mal executada.
o Integridade de dados. Cada microsserviço deve ser responsável pela própria persistência de
dados. Assim, a consistência dos dados pode ser um desafio. Adote consistência eventual quando
possível.
o Gerenciamento. Ter êxito com microsserviços requer uma cultura DevOps madura. Registro em
log correlacionado entre serviços pode ser desafiador. Normalmente, o registro em log deve
correlacionar várias chamadas de serviço para uma operação de um único usuário.
o Controle de versão. As atualizações de um serviço não devem interromper os serviços que
dependerem delas. Vários serviços podem ser atualizados a qualquer momento, portanto, sem
design cuidadoso, você pode ter problemas com compatibilidade com versões anteriores ou
futuras.
o Conjunto de qualificações. Os microsserviços são sistemas altamente distribuídos. Avalie
cuidadosamente se a equipe tem as habilidades e a experiência para ser bem-sucedida.

Em uma arquitetura de microsserviço, caso sejam criados vários sistemas, a falha de algum deles não
afetará os demais sistemas. (CERTO)

Um princípio básico dos microsserviços é que cada serviço gerencia seus próprios dados, sendo
responsável pelo armazenamento particular desses dados e também pela execução em seus próprios
processos.(CERTO)

Sobre a arquitetura de microsserviços, é correto afirmar que ela: facilita e acelera o deploy por permitir
que serviços sejam atualizados, independentemente do resto do sistema.
Uma das vantagens da utilização de uma arquitetura de microsserviços é a possibilidade de isolamento
de eventuais falhas no software. (CERTO)

Uma arquitetura de microsserviços consiste em uma coleção de pequenos serviços autônomos, cada qual
independente e com a atribuição de implementar uma única funcionalidade. (CERTO)

No contexto de microsserviços, trata-se de uma abstração da arquitetura da web. Resumidamente,

consiste em princípios/regras/constraints que, quando seguidos, permitem a criação de um projeto com
interfaces bem definidas, dessa forma, permitindo, por exemplo, que aplicações se comuniquem. (REST
API)

Situação hipotética: Deseja-se programar um sistema distribuído com componentes de sistemas

autônomos, ou seja, implementar o sistema na SOA (arquitetura orientada a serviços), sendo essa a
única informação disponível. Assertiva: Nessa situação, ainda que a SOA agregue componentes de
sistemas que são serviços autônomos e que ela utilize protocolos como o SOAP (Standard Object Access
Protocol), a SOA não permite a execução em computadores geograficamente distribuídos. (ERRADO)
Não há restrição geográfica para utilização do SOA, inclusive, essa seria uma vantagem plausível na
aplicação desta arquitetura.

Situação hipotética: Uma empresa possui um grande sistema com todas as suas funcionalidades em
uma aplicação que acessa um banco de dados. A aplicação foi desmembrada em várias outras, em
 formatos de contêineres que podem ser provisionados, iniciados e parados sob demanda em ambientes
de homologação e desenvolvimento, porém, em produção, o deploy é feito manualmente. Assertiva:
Nessa situação, configura-se um ambiente que possui práticas de entrega contínua. (CERTO)

3.4 Arquitetura orientada a eventos.

o Consiste em uma arquitetura orientada a eventos de produtores de eventos que geram um fluxo de
eventos, e consumidores dos eventos que escutam eventos.

o
o Os eventos são entregues quase em tempo real, para que os consumidores possam responder
imediatamente conforme os eventos ocorrem. Os produtores são dissociados dos consumidores – um
produtor não sabe quais consumidores estão escutando. Os consumidores também são separados uns dos
outros; e cada consumidor vê todos os eventos. Isso difere do padrão de Consumidores Concorrentes,
onde os consumidores removem mensagens de uma fila, e uma mensagem é processada apenas uma vez
(presumindo que não haja erros).
o Um evento controlado por arquitetura pode usar um dos dois modelos:
o Pub/sub: a infraestrutura de mensagens acompanha o controle de assinaturas. Quando um evento
é publicado, ele envia o evento para cada assinante. Depois que um evento é recebido, ele não
pode ser reproduzido e não será exibido para assinantes novos. (MAILING LIST)
o Streaming de eventos: eventos são gravados em um registro. Os eventos são estritamente
ordenados (dentro de uma partição) e duráveis. Os clientes não assinam o fluxo, em vez disso, um
cliente pode ler a partir de qualquer parte do fluxo. O cliente é responsável por avançar a sua
posição no fluxo. Isso significa que um cliente pode participar a qualquer momento e pode
reproduzir eventos. (Ex: NETFLIX)
o No lado do consumidor, há algumas variações comuns:
o Processamento de eventos simples. Um evento dispara imediatamente uma ação no
consumidor. Por exemplo, você pode usar as Azure Functions com um gatilho de Barramento de
Serviço para que uma função seja executada sempre que uma mensagem é publicada em um
tópico do Barramento de Serviço.
o Processamento de eventos complexos. Um consumidor processa uma série de eventos,
procurando padrões nos dados de eventos usando uma tecnologia, como o Azure Stream Analytics
ou o Apache Storm. Por exemplo, você pode agregar as leituras de um dispositivo incorporado em
uma janela de tempo e gerar uma notificação se a média móvel ultrapassar um certo limite.
o Processamento de fluxo de eventos. Use uma plataforma de fluxo de dados, como o Hub IoT do
Azure ou o Apache Kafka, como um pipeline para ingestão de eventos e os encaminhe para os
processadores de fluxo. Os processadores de fluxo agem para processar ou transformar o fluxo.
Pode haver vários processadores de fluxo para subsistemas diferentes do aplicativo. Esta
abordagem é uma boa opção para cargas de trabalho de IoT.

3.5 Mediate APIs.

o A API Mediation Layer fornece um único ponto de acesso para APIs REST de serviço de mainframe. A
camada oferece recursos corporativos semelhantes à nuvem, como alta disponibilidade, escalabilidade,
descoberta de API dinâmica, segurança consistente, uma experiência de logon único e documentação. 
o A API Mediation Layer facilita a comunicação segura entre microsserviços fracamente acoplados por
meio do API Gateway. 
o A API Mediation Layer consiste em três componentes:
o Gateway: O Gateway fornece comunicação segura entre serviços API fracamente acoplados. Os
serviços que compõem o ecossistema de serviço API ML estão localizados atrás de um gateway
(proxy reverso). Todos os usuários finais e aplicativos de cliente API interagem por meio do
Gateway. Cada serviço é atribuído a um ID de serviço exclusivo que é usado no URL de acesso .
Com base no ID do serviço, o Gateway encaminha as solicitações de entrada da API para o
serviço apropriado. Várias instâncias de gateway podem ser iniciadas para atingir alta
disponibilidade. O URL de acesso ao gateway permanece inalterado. O Gateway é construído
usando a tecnologia Netflix Zuul e Spring Boot.
o Discovery Service: O Discovery Service permite que você determine a localização e o status das
instâncias de serviço em execução no ecossistema API ML.  O Discovery Service é o repositório
central de serviços ativos no ecossistema API ML. O Discovery Service coleta e agrega
informações de serviço continuamente e serve como um repositório de serviços ativos. Quando um
serviço é iniciado, ele envia seus metadados, como a URL original, service Id atribuído e
informações de status para o Serviço de descoberta. Os microsserviços de back-end registram-
se neste serviço diretamente ou usando um cliente Eureka. Vários habilitadores estão disponíveis
para ajudar na integração de serviços de várias arquiteturas de aplicativos, incluindo aplicativos
Java simples e aplicativos Java que usam a estrutura Spring Boot. O Discovery Service é baseado
na tecnologia Eureka e Spring Boot. O protocolo HTTPS pode ser ativado durante a configuração
do API ML e é altamente recomendado. Além de criptografar a comunicação, a configuração
HTTPS para o Discovery Service permite maior segurança para o registro do serviço. Sem HTTPS,
os serviços fornecem um nome de usuário e senha para registro no ecossistema API ML. Ao usar
HTTPS, apenas serviços confiáveis que fornecem certificados HTTPS assinados por uma
autoridade de certificação confiável podem ser registrados.
o Catálogo: O Catálogo fornece uma interface fácil de usar para visualizar todos os serviços
descobertos, suas APIs associadas e a documentação do Swagger de uma maneira amigável. O
Catálogo de API é o catálogo de serviços de API publicados e sua documentação associada. O
Catálogo fornece as APIs REST e uma interface de usuário (IU) da web para acessá-los. A IU da
web segue o componente de IU Swagger padrão da indústria para visualizar a documentação da
API no formato OpenAPI JSON para cada serviço. Um serviço pode ser implementado por uma ou
mais instâncias de serviço, que fornecem exatamente o mesmo serviço para alta disponibilidade ou
escalabilidade. O acesso ao Catálogo de APIs pode ser protegido com um Enterprise z / OS
Security Manager, como IBM RACF, ACF2 ou Top Secret. Somente usuários que fornecem
credenciais de mainframe adequadas podem acessar o Catálogo. A autenticação do cliente é
implementada por meio da API zOSMF.
o Principais recursos:
o Acesso consistente: o roteamento de API e padronização de URLs de serviço de API por meio do
componente Gateway fornece aos usuários uma maneira consistente de acessar APIs de
mainframe em um endereço predefinido.
o Descoberta dinâmica: O serviço de descoberta determina automaticamente a localização e o status
dos serviços API.
o Alta disponibilidade: a API Mediation Layer foi projetada com alta disponibilidade de serviços e
escalabilidade em mente.
o Redundância e escalabilidade: o rendimento do serviço de API é facilmente aumentado ao iniciar
várias instâncias de serviço de API sem a necessidade de alterar a configuração.
o Apresentação dos serviços: O componente Catálogo API fornece acesso fácil aos serviços API
descobertos e sua documentação associada de uma maneira amigável. O acesso ao conteúdo do
Catálogo de APIs é controlado por meio de um recurso de segurança z / OS.
o Comunicação criptografada: API ML facilita a comunicação segura e confiável entre componentes
internos e serviços API descobertos.
 3.6 Arquitetura Cloud Native.

o É uma arquitetura para a criação de aplicações nativas em nuvem, em ambientes que proporcionam
benefícios para o desenvolvimento e uso da aplicação, gerando ganho de tempo para a empresa, que pode
direcioná-lo a aprimorar produtos e proporcionar uma melhor experiência ao usuário.
o Os aplicativos nativos da nuvem devem ser orientados a microsserviços para facilitar a manutenção e a
agilidade;
o Eles devem ser armazenados em contêineres para que possam funcionar da melhor forma em qualquer
ambiente;
o Os aplicativos nativos da nuvem devem ser orquestrados dinamicamente, para que contêineres individuais
possam operar juntos de forma eficaz para formar uma aplicação completa, permitindo maior eficiência e
escalabilidade
o Eles devem ser construídos usando as estruturas e linguagens mais adequadas para tarefas específicas, em
vez de adotar uma única estrutura ou linguagem para toda a arquitetura
o Os aplicativos nativos da nuvem devem ser gerenciados usando processos DevOps ágeis.
o Eles devem ser desenvolvidos primeiro para dispositivos móveis, implementando um design centrado no
usuário.
o Por fim, os aplicativos nativos da nuvem podem ser vulneráveis a ameaças de segurança específicas da
nuvem e podem exigir ferramentas ou plataformas de segurança especializadas.
o Benefícios da computação nativa em nuvem. A arquitetura nativa da nuvem oferece certos
benefícios e vantagens em relação às soluções de computação tradicionais:
 Os aplicativos nativos da nuvem são serviços independentes postos juntos como
contêineres. Isso significa que eles têm o potencial de escalar - aumentar ou diminuir -
muito rápido.
 Por causa da conteinerização nativa da nuvem, serviços específicos podem ser
adicionados ou removidos sem afetar os outros aspectos da aplicação.
 Os aplicativos nativos da nuvem podem ser enviados de forma excepcionalmente rápida
e atualizados de forma quase constante. Isso resulta não apenas em um tempo de
entrada no mercado mais rápido, mas também em uma melhor experiência do cliente.
 Os aplicativos nativos da nuvem são mais fáceis de gerenciar.
 E, para finalizar, graças à conteinerização, às ferramentas de suporte e padrões de
nuvem, o custo de operação de uma infraestrutura cloud native é geralmente menor do
que o custo de transição dos aplicativos não-cloud pré-existentes para um ambiente de
nuvem.
 Arquiteturas cloud native aprimoram nossa capacidade de praticar DevOps e Entrega
Contínua (Continuous Delivery), e elas exploram as características da infraestrutura na
nuvem (Cloud Infrastructure).
o Quais as principais características do cloud native?
o Microsserviços: Serviços que podem funcionar de modo independente formam as aplicações, que
podem funcionar sem interrupção enquanto os programadores programam os microsserviços.
o Containers: Esses serviços são contidos em “compartimentos”, o que facilita o acesso a eles.
Também fica mais fácil escalá-los, excluí-los, criá-los ou migrá-los pra outros ambientes.
o Entrega contínua: A criação da aplicação é otimizada com entregas contínuas desses serviços. O
tempo e o custo de desenvolvimento também são menores, do mesmo modo que a escalabilidade
pode ser feita de acordo com o tamanho do projeto e com a adoção de automações.
o DevOps: Já deu pra identificar o quanto o cloud native é alinhada ao DevOps? Ela ajuda a
maximizar a colaboração entre os desenvolvedores e o time de TI, agilizando o teste e o
lançamento do software. O cloud native funciona de um modo mais orgânico. Dá pra dizer que
esse é um modelo mais próximo da biologia do que da física, como a Bio-IoT.

3.7 Padrões de design de software.

3.8 Técnicas de componentização de software.

o componentização de software como uma unidade de software que, quando unida a outras unidades, foram
um sistema ainda maior, que proporciona mais agilidade durante o desenvolvimento de um software.
o componentização de software é uma abordagem arquitetural baseada na divisão de sistemas de software em
unidades menores, denominadas componentes.”
o Uma das grandes vantagens do desenvolvimento baseado em componentes é a otimização de investimentos
e tempo dos desenvolvedores. Isso pode acarretar também em um custo mais razoável tanto para produção
do software quanto para o usuário final, por exemplo. 
o Vantagens da componentização:
o Facilidade de conversão tecnológica;
o Base para modelo de camadas;
o Contribui à integração de informações entre canais de acesso;
o Manutenção e atualização mais fáceis;
o

3.9 Padrões de projeto (design patterns) e anti-patterns.

 Design patterns ou padrões de design são soluções já testadas para problemas recorrentes no
desenvolvimento de software, que deixam seu código mais manutenível e elegante, pois essas soluções se
baseiam em um baixo acoplamento.
 O uso de Design Patterns deixará seu código mais fácil de ser mantido e testado, além da segurança de
serem soluções já testadas repetidamente e que foram adotadas por terem dado certo.
 Conhecido como GANG OF FOUR (GOF)
 Benefícios:
o um bom ganho de produtividade para os desenvolvedores.
o Seu uso também contribui para a organização e manutenção de projetos, já que esses padrões se
baseiam em baixo acoplamento entre as classes e padronização do código.
o Além disso, com a padronização dos termos, as discussões técnicas são facilitadas. É mais fácil
falar o nome de um design pattern em vez de ter que explicar todo o seu comportamento.
 Agruparam os Design Patterns em três tipos diferentes:
o Creational (Criação): Como o próprio nome sugere, esses padrões nos ajudam na criação de
objetos, eles abstraem a criação de um objeto ajudando a tornar o sistema independente de como
os objetos são criados:
 Abstract Factory: permite que um cliente crie famílias de objetos sem especificar suas
classes concretas;
 Builder: encapsular a construção de um produto e permitir que ele seja construído em
etapas;
 Factory Method: as subclasses decidem quais classes concretas serão criadas.
 Prototype: permite você criar novas instancias simplesmente copiando instancias
existentes;
 Singleton: assegura que somente um objeto de uma determinada classe seja criado em
todo o projeto; um sistema que necessite de um único objeto de uma classe, após o
programa instanciar o objeto, não deve ter permissão de criar objetos adicionais dessa
classe.
o Structural (Estrutura): O trabalho deles é lidar com a composição de classes ou objetos,
facilitando o design do sistema, identificando maneiras de realizar o relacionamento entre as
entidades.
 Adapter: envelopa um objeto e fornece a ele uma interface diferente; converte uma
interface em outra.
 Bridge: permite criar uma ponte para variar não apenas a sua implementação, como
também as suas abstrações; Desacoplar uma abstração de sua implementação para que
ambas possam variar independentemente
 Composite: Os clientes tratam as coleções de objetos e os objetos individuais de
maneira uniforme; Um cliente que precisa tratar, de maneira uniforme, objetos individuais
e suas composições.
 Decorator: envelopa um objeto para fornecer novos comportamentos; oferecem uma
alternativa flexível ao uso de herança para estender uma funcionalidade, com isso
adiciona-se uma responsabilidade ao objeto e não à classe
 Façade: simplifica a interface de um conjunto de classes;
 Flyweight: uma instancia de uma classe pode ser usada para fornecer muitas
“instancias virtuais”;
 Proxy: envelopa um objeto para controlar o acesso a ele;
o Behavioral (Comportamental): Os padrões de comportamento definem a maneira como classes
ou objetos interagem e distribuem responsabilidades:
 Chain of Responsibility: permite dar a mais de um objeto a oportunidade de processar
uma solicitação;
 Command: encapsula uma solicitação como um objeto;
 Interpreter: permite construir um intérprete para uma linguagem;
 Iterator: fornece uma maneira de acessar seqüencialmente uma coleção de objetos sem
expor a sua implementação;
 Mediator: centraliza operações complexas de comunicação e controle entre objetos
relacionados;
 Memento: permite restaurar um objeto a um dos seus estados prévios, por exemplo,
quando o usuário seleciona um “desfazer”;
 Observer: permite notificar outros objetos quando ocorre uma mudança de estado.
 State: encapsula comportamentos baseados em estados e usa a delegação para
alternar comportamentos;
 Strategy: encapsula comportamentos intercambiáveis e usa a delegação para decidir
qual deles será usado;
 Template Method: As subclasses decidem como implementar os passos de um
algoritimo;
  Visitor: permite acrescentar novos recursos a um composto de objetos e o
encapsulamento não é importante;

O padrão Iterator oferece uma forma flexível de uso de herança para estender uma funcionalidade. (ERRADO)
Iterator é um padrão comportamental que fornece uma maneira de acessar sequencialmente uma coleção de
objetos sem expor a sua implementação. É o Decorator Decorators: oferecem uma alternativa flexível ao uso de
herança para estender uma funcionalidade, com isso adiciona-se uma responsabilidade ao objeto e não à classe

Um cliente que precisa tratar, de maneira uniforme, objetos individuais e suas composições deve utilizar, para essa
finalidade, o padrão Facade. (ERRADA) Para tratar de maneira uniforme objetos individuais em estruturas de
árvores que representem hierarquias partes-todo, o padrão composite é mais adequado que o decorator.

O propósito do padrão Adapter é separar uma abstração de sua implementação, para que as duas possam variar e
ser independentes. (ERRADO) Desacoplar uma abstração de sua implementação para que ambas possam variar
independentemente é o padrão BRIDGE

um sistema que necessite de um único objeto de uma classe, após o programa instanciar o objeto, não deve ter
permissão de criar objetos adicionais dessa classe.(CERTO)

Um certo padrão de projeto (design pattern) de criação utiliza métodos para criar objetos sem que o chamador
precise especificar a classe exata desses objetos, e sem invocar seu construtor diretamente. O método que define a
classe a ser instanciada pode estar especificado em uma interface e ser codificado em classes que a implementam,
ou então ser implementado em uma classe base e opcionalmente redefinido (overriden) em uma classe filha. Esse
padrão de projeto é conhecido como (Factory Method.)Os padrões de projeto de software são classificados de
acordo com a funcionalidade. Assim, eles podem ser de criação, estrutural e comportamental. Assinale a alternativa
que contém um exemplo de padrão de cada tipo. (Builder, Bridge e Observer.)

ESTUDAR MELHOR APÓS ESTUDAR ORIENTADO A OBJETOS

3.10 Padrões de arquitetura de aplicações corporativas (Patterns of Enterprise Applications Architecture).

PEAA

3.11 Arquitetura de Sistemas WEB e WEB Standards (W3C).

3.12 Arquitetura Orientada a Serviços (SOA).

o Arquitetura Orientada a Serviços (SOA) não é uma tecnologia, não é uma metodologia, não é um serviço,
mas é um conceito de arquitetura corporativo que promove a integração entre o negócio e a TI por meio de
conjunto de interfaces de serviços acoplados.
o Tanto a orquestração quanto a coreografia, no paradigma SOA, arranjam serviços diferentes para serem
executados em uma ordem preestabelecida. A diferença é que a orquestração possui um orquestrador
único que define a ordem de realização dos serviços, fazendo com que os mesmos não necessitem
conhecer uns aos outros. Na coreografia, é necessário que os serviços saibam da existência uns dos
outros, para, então, serem executados em uma ordem preestabelecida.
o Arquitetura orientada a serviços (SOA) é um tipo de design de software que torna os componentes
reutilizáveis usando interfaces de serviços com uma linguagem de comunicação comum em uma rede.
o Um serviço é uma unidade ou conjunto de funcionalidades de software independente, que foi desenvolvido
para concluir uma tarefa específica, como recuperar determinadas informações ou executar uma operação.
o Ele contém as integrações de dados e o código necessários para executar uma função de negócios
completa. Esses serviços podem ser acessados remotamente e é possível interagir com eles e atualizá-los
de maneira independente.
o No estilo de arquitetura orientada a serviços, a comunicação entre os serviços é realizada por um sistema de
"baixo acoplamento". Essa é uma maneira de interconectar componentes, também chamados de
"elementos", em um sistema ou rede para que transmitam informações ou coordenem processos
empresariais e reduzam as dependências entre eles.
o Ao expor serviços usando protocolos de rede padrão, como SOAP, JSON, ActiveMQ ou Apache Thrift, para
enviar solicitações ou acessar dados, a SOA facilita a vida dos desenvolvedores, pois eles não precisam
fazer a integração do zero. Em vez disso, eles podem usar padrões chamados enterprise service buses
(ESBs), que realizam a integração entre um componente central e sistemas de back-end e depois os tornam
acessíveis como interfaces de serviços. Isso também ajuda os desenvolvedores a reutilizar funções
existentes, em vez de recriá-las.
o Vantagens em comparação com abordagem monolítica:
o Time to market acelerado e maior flexibilidade: a reutilização de serviços faz com que seja mais
fácil e rápido montar aplicações. Os desenvolvedores não precisam sempre começar do zero,
como no caso das aplicações monolíticas.
o Uso de infraestrutura legada em novos mercados: com a SOA, é mais fácil para os
desenvolvedores escalar ou ampliar o uso de uma funcionalidade para plataformas ou ambientes
novos.
 o Redução de custos resultante da maior agilidade e eficiência no desenvolvimento.
o Fácil manutenção: como todos os serviços são autossuficientes e independentes, é possível
modificá-los e atualizá-los conforme a necessidade, sem afetar os outros serviços.
o Escalabilidade: como a SOA permite executar serviços usando vários serviços, plataformas e
linguagens de programação diferentes, há uma grande melhoria na escalabilidade. Além disso, a
SOA usa um protocolo de comunicação padronizado, o que permite às empresas reduzir a
interação entre clientes e serviços. Com a redução no nível de interação, é possível escalar
aplicações com menos urgência e aborrecimentos.
o Maior confiabilidade: por ser mais fácil fazer o debug de serviços menores do que um grande
código, a SOA permite criar aplicações mais confiáveis.
o Maior disponibilidade: os recursos da SOA estão disponíveis para todos.
o Funções da SOA: A base de uma arquitetura orientada a serviço é constituída de três funções.
o Provedor de serviços: Um provedor de serviços cria serviços web e os oferece para um registro
de serviços. Ele é responsável pelos termos de uso desse serviço.
o Broker ou registro de serviços: Um broker de serviços ou registro de serviços é responsável por
oferecer informações solicitadas sobre o serviço. O broker pode ser público ou privado.
o Solicitante ou cliente de serviços: Um solicitante de serviços encontra um serviço no broker ou
no registro de serviços. Então, conecta-se ao provedor de serviços para recebê-lo.
o Diferença SOA e Microserviços
o A principal característica que os diferencia é o escopo: a SOA é uma abordagem de arquitetura
adotada pela empresa como um todo, enquanto os microsserviços são uma estratégia de
implementação da equipe de desenvolvimento para cada aplicação.
o A comunicação entre os componentes também é diferente: A SOA usa ESB, enquanto os
microsserviços comunicam-se uns com os outros de maneira stateless, por meio de APIs
independentes de linguagem. Devido liberdade de escolha de ferramentas, os microsserviços são
mais tolerantes e flexíveis.
o Serviços web na SOA podem ser oferecidos por provedores como aplicações SaaS. Os usuários
interagem com o software por meio de um navegador da web no computador ou em dispositivos
mobile. Eles também podem usar APIs, como REST ou SOAP, para conectar o software a outras
funções.
o Tipos de serviços SOA podem ser classificados como:
o Entity Services, empregados em operações de CRUD (inclusão, exclusão, alteração e / ou
consulta a informações);
o Utility Services, contemplando funcionalidades que não estejam diretamente relacionadas ao
negócio (log, envio de e-mail, etc.);
o Task Services, utilizados na automação de processos de negócio. Tais estruturas costumam
implementar a composição de serviços, com o consumo de Entity e/ou Utility Services;
o Orchestrated Task Services, os quais incorporam lógica de orquestração e controlam o fluxo em
composições de serviços que envolvam Entity, Utility e Task Services.
o Princípios de Design de Serviços:: São conceitos e padrões fornecem a base para a implementações de
soluções orientadas a serviço. A finalidade desta seção é apresentar em detalhes os seguintes princípios:
o Contrato Padronizado: Serviços mais antigos costumam fazer uso do protocolo SOAP (Simple
Object Access Protocol), um formato de comunicação baseado em XML. No caso específico de
serviços REST, os formatos JSON e XML substituem SOAP. A comunicação com tais estruturas
se dá por meio de requisições HTTP, além da utilização de classes POCO (Plain Old CLR Objects)
em aplicações criadas com a tecnologia ASP.NET Web API.
o Acoplamento: Um baixo nível acoplamento entre as diferentes partes de uma aplicação é uma
característica mais do que desejável, já que representa uma medida de quão bem estruturado tal
software se encontra. A implementação de uma solução orientada a serviços contribui para um
menor acoplamento, com isto acontecendo graças à separação de funcionalidades de negócio em
serviços específicos. O acoplamento representa o nível de dependência entre recursos ou
serviços. é possível extrair impactos significantes nos valores de entrega, autonomia e
confiabilidade do serviço como um todo, além da redução significativa da capacidade de
composição de um serviço e valor estratégico para o negócio.
o Abstração: O conceito de abstração refere-se à ideia de caixa preta, ou seja, à ocultação de
detalhes técnicos (infraestrutura em uso, bancos de dados, mecanismos de controle de acesso
etc.). Aplicações que venham a consumir um serviço não necessitam conhecer detalhes internos
da implementação deste, mas sim que funcionalidades tal estrutura disponibiliza para uso. deve
ser genérico o bastante para se adaptar ao máximo de composições possíveis, mas ao
mesmo tempo não pode ser abstrato demais ao ponto de o consumidor não saber do que se
trata o serviço, favorecendo o cenário de redundância de recursos, desperdício financeiro e
atraso da TI
o Reusabilidade; A implementação de um novo serviço deve levar em conta a possibilidade de
reuso do mesmo. Logo, chances consideráveis de utilização de um Web Service imediatamente
ou, até mesmo, a médio prazo constituem boas justificativas para a adoção deste tipo de
estratégia. O reuso de recursos está associado à necessidade de adaptação do serviço a
diferentes tipos de requisições e ambientes ,
o Autonomia do serviço; A ideia de autonomia está ligada à independência de um serviço em
relação a influências externas. Logo, um nível alto de autonomia é uma característica
 extremamente desejável na implementação de serviços. cada serviço deve ser responsável pelo
seu ambiente em tempo de execução e projeto, no entanto, em composições complexas, à
medida com que o serviço aproxima-se do topo da cadeia de composição, o nível de autonomia é
automaticamente comprometido. Em contrapartida é possível afirmar que quanto menor for a
posição do serviço na composição, maior será sua autonomia.
o Independência de Estado; Serviços devem ser, sempre que possível, implementados de forma a
evitar o armazenamento de informações de estado em memória (stateless). Essa característica
está ligada a questões de performance, impactando diretamente na escalabilidade (capacidade de
se adequar a demandas crescentes) de um sistema. Por padrão SOA, serviços não devem
guardar estado, simples assim! A adesão à arquitetura orientada a serviços por si só gera uma
série de desafios e mudanças organizacionais e tecnológicas. Dentre estas mudanças destaca-se
o esforço em infraestrutura. Serviços reutilizáveis e composições complexas por si só já
aumentam consideravelmente a carga de processamento de infraestrutura e complexidade
do projeto, se adicionar uma pitada de armazenamento de estado poderia ser o divisor de águas
entre o sucesso e o fracasso a longo prazo. O excesso de dados em memória influenciaria
diretamente na escalabilidade e disponibilidade do serviço, ferindo o princípio de autonomia
do serviço.
o Visibilidade; A visibilidade de um serviço está relacionada à capacidade de outras aplicações
descobrirem o mesmo, bem como interpretarem a estrutura que o mesmo expõe.Em serviços
SOAP esta característica encontra-se ligada ao uso dos padrões UDDI (Universal Description,
Discovery and Integration) e WS-MetadataExchange (especificação que regula a geração de
documentos XML com a estrutura de um serviço). Já serviços REST costumam expor sua estrutura
através de páginas descritivas. No caso específico do ASP.NET Web API, um site descrevendo as
APIs REST e suas funcionalidades pode ser criado automaticamente (através da seleção de um
template específico no Visual Studio). Outra alternativa seria a utilização da solução conhecida
como Swagger (http://swagger.io/). um serviço deve ser de fácil interpretação e descoberta ao
mesmo tempo em que o mesmo deve ser genérico o bastante para servir à diversas causas. O
serviço deve ser sim o mais abstrato possível, mas não ao ponto de perder sua identidade.
o Capacidade de Composição; A noção de composição está diretamente ligada à questão do
reuso, envolvendo a criação de novos serviços a partir da combinação de outros já existentes. Um
serviço implementado desta forma tende a possuir uma menor autonomia, estando sujeito às
interferências que ocorrerem nos componentes dos quais depende.Composições podem ser
primitivas ou complexas.Uma composição primitiva envolve a troca simplificada de mensagens
entre dois ou mais serviços. Já composições complexas contam com uma lógica mais elaborada,
representando em muitos casos um processo de negócio. Orchestrated Task Services constituem
um exemplo deste tipo de composição
o Granularidade. A granularidade diz respeito ao escopo abrangido pelas capacidades de um
serviço. Do ponto de vista prático, esta característica é determinada com base na quantidade de
funcionalidades encapsuladas por um serviço. Levando em conta tal fator, a granularidade pode
ser classificada em fina (fine-grained) e grossa (coarse-grained).Serviços com granularidade fina
possuem um maior potencial de reuso, sendo que os Entity e Utility Services constituem bons
exemplos deste tipo de implementação.
Já a granularidade grossa resulta numa menor possibilidade de reaproveitamento, uma vez que
implica em alguma forma de acoplamento com outras construções. Contudo, isto não representa
um mau design. Task e Orchestrated Task Services costumam ser exemplos típicos desta
granularidade.
o Abordagens
o Abordagem top-down: Essa abordagem identifica a necessidade de um serviço através da
análise de processos de negócio ou das interações com entidades externas. Ela normalmente é
realizada pelo analista de negócio em conjunto com arquiteto de sistemas e tem como principal
benefício o alinhamento mais natural com o negócio. Se o serviço (ou as capacidades necessárias)
já existir em um sistema legado, será necessário procurá-lo e extraí-lo. Se o serviço ainda não
existir, é necessário construí-lo.
o Abordagem bottom-up: serviços (ou capacidades) identificados através dos pontos de integração
entre sistemas ou das funcionalidades já disponíveis nos sistemas atuais. Nessa abordagem corre-
se o risco de criar serviços que não representam uma função de negócio ou que tenham
acoplamento com a implementação. Porém, pode ser uma boa opção quando existem muitos
problemas de integração spaghetti ou se deseja preparar para substituição de algum sistema de
back-end.
o O Modelo de maturidade para SOA reflete as proficiências de negócio e técnica disponíveis para a
concepção de soluções. Cada nível define uma graduação em relação a capacidade da organização (física,
as competências, habilidades e atitudes de seus colaboradores) baseada em processos mais ou menos
avançados e experimentados.
o Nível 1 - Processo de desenvolvimento tradicional: determina um processo de
desenvolvimento que não utiliza uma abordagem orientada a serviços como modelo de solução
tecnológica. Nesse nível, a organização não está interessada em utilizar soluções SOA como
estratégia de alinhamento.
o Nível 2 - Processo de desenvolvimento orientado a serviços, apoiado por soluções de TI
simples: determina um processo de desenvolvimento SOA apoiado por soluções e serviços Web
dentro de uma arquitetura composta por serviços simples sem a colaboração esperada em
 soluções de grande porte (sincronismo de dados, serviços de autenticação e funcionalidades
simples).
o Nível 3 - Processo de desenvolvimento orientado a serviços, apoiado por soluções de TI
compostas: determina um processo de desenvolvimento SOA apoiado pela colaboração e
orquestração de sistemas e serviços de TI que interagem para fornecer soluções lógica e
semanticamente complexas.
o Nível 4 - Processo de automação do negócio pelo uso de soluções de TI compostas:
determina um processo de desenvolvimento onde a organização utiliza todo o potencial
fornecido pelas soluções orientadas a serviços compostas para automatizar e otimizar o
alinhamento estratégico entre a TI e o negócio.

No caso de um novo serviço de informação necessitar de obter dados de uma aplicação legada via web, sem
acesso direto a base de dados, tal demanda pode ser atendida no padrão SOA, por meio de uma API (application
programming interface) que utilize o método POST. (ERRADO) Errado! É GET!!!

REST, ou Representational State Transfer, é um protocolo de comunicações sem estado. Que alternativa melhor
representa o corpo de uma chamada REST que deseja saber o saldo de um cliente bancário identificado como
cliente 23232? ( http://app.banco.com/contascorrentes/saldo/cliente/23232)

Na arquitetura orientada a serviço (SOA), as características de baixo acoplamento e interoperabilidade corroboram

sua adequação ao desenvolvimento de sistemas que demandem respostas em tempo real. (ERRADO) SOA não é
bom para tempo-real. (Um benefício da utilização de arquitetura orientada a serviços (SOA) é o baixo nível de
disponibilidade dos serviços.)

SOA é um estilo arquitetônico de software usado para construir soluções empresariais baseadas em serviços Web.
São características dos serviços desse estilo: (REUSO E DESCOBERTA DINAMICA) pois Reuso: a lógica é
dividida no serviço com a intenção de reuso; Descoberta: serviços são projetados para ser exteriormente descritos,
para que possam ser encontrados e avaliados através de mecanismos de descobertas disponíveis.

Com a SOA (service oriented architecture), os clientes e componentes podem ser escritos em diferentes linguagens
de programação e podem usar vários protocolos de mensagens. (CERTO)

O objetivo da arquitetura orientada a serviços é realizar uma separação entre a lógica de integração de negócios e a
implementação. Nessa arquitetura, os serviços são funções e(ou) processos de negócios individuais,
compartilhados e reutilizáveis, que podem fazer parte da composição de outros serviços pela integração e(ou)
orquestração de tais serviços. (CERTO)

Na implantação de SOA, os serviços disponibilizados devem lidar com processos de negócio, encapsulando todas
as funções que sejam necessárias para a sua execução e gerando independência em relação a outros serviços.
(ERRADO) Como SOA é orientada a serviços, são encapsuladas as funcionalidades não específicas a nenhum
aplicativo ou processo de negócio, ou seja, as funcionalidade são genéricas, o que favorece a reutilização em
outros projetos.

API (application program interface) pode ser usada para integrar sistemas, de forma que um dos lados seja
consumidor de um serviço provido pelo outro lado, desde que tais serviços tenham sido implementados por meio de
SOA. (ERRADO) Então, quando se implementa uma API, não existe a obrigação de usar arquitetura SOA. 

A respeito da arquitetura orientada a serviços, assinale a alternativa correta. (Um protocolo de comunicação precisa
ser estabelecido para que haja comunicação entre diferentes sistemas com diferentes linguagens de programação.)

São características da arquitetura SOA as abaixo relacionadas, EXCETO: promover pouco acoplamento entre os
componentes de software para que possam ser reutilizados.

“SOA (Service-Oriented Architecture) é baseada no paradigma conhecido como “_____ - ______ - ______” a fim de
que os serviços possam ser publicados, buscados e consumidos por qualquer sistema.” (Find/ Bind/ Execute)
Tecnicamente falando, o processo recomenda que os provedores de serviços registrem informações em um registro
central, com suas características, indicadores, e aspectos relevantes às tomadas de decisões. O registro é utilizado
pelo cliente para determinar as características dos serviços necessários, e se o mesmo estiver disponível no
registro central, como por exemplo por um catálogo de serviços, o cliente poderá utilizá-lo, sendo este oficializado
através de um contrato que enderece este serviço.

No modelo operacional triangular de SOA, o registro determina o comportamento da organização na divulgação e o

procedimento do cliente para identificar o serviço.(CERTO)

Uma arquitetura orientada a serviços é: uma arquitetura para a criação de aplicações de negócios, como um
conjunto de componentes caixa-preta, fracamente acoplados, orquestrados para oferecer um nível de serviço bem
definido, vinculando processos de negócios.

Uma Arquitetura SOA não faz abstração de plataformas e tecnologias de infraestrutura. (ERRADO) Abstração:
encapsulamento da lógica interna de um serviço por meio de sua interface. Ao separar interface de implementação,
o serviço age como uma caixa preta e expõe aos seus consumidores somente informações sobre as operações
disponíveis.

O uso de SOA tem como benefício a flexibilidade para substituição de sistemas de back-end e de infraestrutura com
um menor impacto sobre o sistema. (CERTO)
Uma estratégia que forja uma forma de pensar, um sistema de valores que leva a tomadas de decisões
concretas e que define o uso de serviços para suportar os requisitos dos usuários de software denomina-se
SSOA

Nos projetos SOA, a modelagem de serviço produz definições conceituais de serviço que são chamadas de
blueprints.(ERRADO)
O blueprint é uma forma de visualizarmos diferentes tipos de componentes de serviços. O SOA Blueprint possui
como objetivos:

o Requisitos dos princípios de desenho

o Tarefas específicas dos princípios de desenhos
o Interação de Serviços
o Detalhes do cenário de integração
o Modelos para tarefas específicas

O blueprint não se preocupa e não se preocupará com a modelagem de serviço apenas, como afirma o item, mas
ele é um conjunto mais amplo e a modelagem está inserida dentro do seu contexto.

Ou seja, o blueprint é uma espécie de descrição esquematizada dos princípios e conceitos do SOA, não tem a ver
com a modelagem de um serviço específico, mas uma definição geral.
Assim, o erro do item está em afirmar que o blueprint é específico para a modelagem de serviços, que como vimos
acima não é. Conforme vimos o blueprint pode ser utilizado para atingir vários outros objetivos.

A implementação de uma arquitetura orientada a serviços é um processo padronizado pela própria arquitetura,
sendo igual para todas as empresas, o que as torna possuidoras da mesma aparência real da SOA após sua
implementação. (ERRADO) SOA é uma filosofia

Na SOA, uma composição de serviço pode ser comparada, por exemplo, a um aplicativo tradicional, pois seu
escopo funcional normalmente se associa à automação de um processo de negócio da empresa.(CERTO)

3.13 Barramento de Serviços Corporativos (ESB).

o Um ESB, ou barramento de serviços corporativos, é um padrão pelo qual um componente centralizado

executa a integração aos sistemas back-end e, em seguida, disponibiliza aquelas integrações como
interfaces de serviço.
o Ele realiza a tradução de modelos de dados, conectividade profunda, roteamento e potencialmente
composição de diversas solicitações e disponibiliza estes como uma única interface de serviço para
reutilização por novos aplicativos.
o O padrão ESB é tipicamente implementado usando um tempo de execução e conjunto de ferramentas
especialmente projetados que são bem adequados às capacidades acima, garantindo a melhor produtividade
possível.
o Em teoria, é possível implementar uma SOA sem um ESB, mas os proprietários de aplicativos teriam que
encontrar sua própria maneira única de expor as interfaces de serviço, o que é muito trabalho (mesmo se as
interfaces sejam eventualmente reutilizáveis) e cria um desafio de manutenção significativo no futuro. Na
verdade, os ESBs foram, eventualmente, considerados um elemento de facto de qualquer implementação de
SOA, tanto que os dois termos são, por vezes, usados de maneira sinônima, gerando confusão.

3.14 Interoperabilidade entre aplicações.

3.15 Conceitos básicos sobre servidores de aplicações.
3.16 Conteinerização de Aplicação. (Docker)

o Docker é uma plataforma de código aberto.

o É utilizado por desenvolvedores, pois ele permite a utilização de recursos isolados para desenvolver e testar
um software.
o Ele utiliza as bibliotecas do sistema operacional servidor em que foi instalado.
o O docker separa os recursos e compartilha as bibliotecas de kernel em comum com outros containers. Isso
garante uma facilidade de adaptação do docker, assegurando a portabilidade.
o O Docker é uma ferramenta open source que permite a criação de ambientes virtuais por meio de Linux
Containers, sendo uma das vantagens dos contêineres Docker fornecer uma virtualização em nível de
sistema operacional, o que isola as aplicações em execução e não utiliza tantos recursos da máquina
quanto as máquinas virtuais.
o O Docker permite “empacotar” uma aplicação ou sistema dentro de um container, sendo que este container
pode posteriormente ser executado em qualquer máquina que tenha o Docker instalado. O conteúdo dos
containers é isolado, não sendo visualizado fora (Os Containers Docker utilizam file systems de atualização
tipo copy-on-write, que permitem o uso de uma imagem de file system como camada base para a execução
de múltiplos containers. As alterações efetuadas em arquivos ou diretórios dentro de um container são
isoladas e não podem ser vistas fora dele)
 o Docker permite criar e gerenciar redes através de software: As redes Docker se comportam como redes
físicas e os contêineres se comportam como servidores conectados a estas redes. Ou seja, ainda precisa de
segurança como qualquer rede.
o Modularidade Camadas:
o Cada arquivo de imagem Docker é composto por uma série de camadas. Elas são combinadas em
uma única imagem. Uma nova camada é criada quando há alteração na imagem. Toda vez que um
usuário especifica um comando, como executar ou copiar, uma nova camada é criada.
o O Docker reutiliza essas camadas para a construção de novos containers, o que torna o processo
de criação muito mais rápido. As alterações intermediárias são compartilhadas entre imagens, o
que melhora ainda mais a velocidade, o tamanho e a eficiência. O controle de versões é inerente
ao uso de camadas. Sempre que é realizada uma nova alteração, é gerado um changelog
integrado, o que fornece controle total sobre as imagens do container.
o Reversão:
o Toda imagem possui camadas. Não gostou da iteração atual de uma imagem? Simples, basta
reverter para a versão anterior. Esse processo é compatível com uma abordagem de
desenvolvimento ágil e possibilita as práticas de integração e implantação contínuas (CI/CD) em
relação às ferramentas.
o Implantação rápida
o Ao criar um container para cada processo, é possível compartilhar rapidamente esses processos
similares com novos aplicativos. Como não é necessário inicializar um sistema operacional para
adicionar ou mover um container, o tempo de implantação é substancialmente menor. Além disso,
com a velocidade de implantação, é possível criar dados e destruir os criados pelos containers sem
nenhuma preocupação e com facilidade e economia.
o Kubernetes:
o Permite gerenciamento e orquestração de vários containers segregados em centenas de partes
o Segurança:
o Para usar e executar os containers Docker, é provável que você use o daemon do Docker, um
ambiente de execução persistente para containers. O daemon do Docker requer privilégios de raiz.
Portanto, é necessário ter um cuidado maior ao escolher as pessoas que terão acesso a esse
processo e o local onde ele residirá. Por exemplo, um daemon local tem menos chances de sofrer
um ataque do que um daemon em um local mais público, como um servidor web.

O Docker possibilita que uma imagem com todos os aplicativos e configurações realizadas em um contêiner sejam
transferidos para outro host, bastando que este tenha o Docker instalado. Assinale a alternativa que apresenta o
nome dessa operação. (PORTABILIDADE).

O modelo de conectividade padrão do docker é menos vulnerável a ataques de segurança do tipo negação de
serviço (DoS) do que o modelo de máquinas virtuais (VM), uma vez que os contêineres são uma camada de
isolamento entre os aplicativos e o kernel do host. (ERRADO)

As alterações efetuadas em arquivos e diretórios copiados de uma camada base para dentro de um container
docker, por padrão, são vistas pelos múltiplos containers do mesmo sistema de arquivos. (ERRADA) não são vistas

A equipe de desenvolvimento de sistemas de um tribunal de contas está guiando a implantação de um Webservice

REST. A implantação será dividida nos seguintes grupos distintos de containers Docker: - Grupo A: responsável
pela execução da aplicação do Webservice REST - Grupo B: responsável pela execução do Sistema Gerenciador
de Banco de Dados utilizado pelo Webservice REST Os Grupos A e B terão seu próprio contexto de
armazenamento e rede a serem orquestrados por um cluster de Kubernetes. Para que a conexão de rede entre os
containers dos Grupos A e B seja bem-sucedida pelo orquestrador, independentemente dos endereços IP a eles
atribuídos, deverá ser configurado um novo (SERVICE)
Uma imagem de contêiner tem como característica a imutabilidade, ou seja, ela não muda após a sua construção;
no entanto, ela pode ser configurada.(CERTO)

3.17 Frameworks de persistência de dados.

o Dados são quaisquer valores atribuídos a algo relacionados à nossa análise.

o Esses dados, quando analisados isoladamente, não fazem muito sentido. Mas, quando devidamente
organizados, analisados e interpretados podem se transformar em uma informação útil.
o Conceito Persistência de dados:
o Persistência de dados como a garantia de que um dado foi salvo e que poderá ser recuperado
quando necessário no futuro. Esse conceito existe na computação para referenciar o ato de
salvar os dados.
o Mantendo o registro de dados processados pelos sistemas, e transformando-os em dados
persistentes, geramos insumos para análises futuras que vão possibilitar a tomada de decisões
estratégicas por empresas para alavancar seus negócios.
o Técnicas de persistência de dados
o O termo persistência de dados em si refere-se a qualquer forma de armazenamento de dados que
for necessária em nosso sistema.
 o O mais usual é utilizar um banco de dados, mas nada impede que sejam utilizadas outras
ferramentas, como uma planilha no Excel, um arquivo de texto, etc. Tudo depende do propósito
dos dados persistentes e de seu contexto.
o No entanto, caso seja necessário fazer uma boa análise de dados, é interessante que os dados
estejam armazenados em locais que te darão maior poder de recuperação e organização, por isso
a recomendação de utilizar um bom banco de dados.
o Para gerenciar e manipular os bancos de dados, existem os Sistemas Gerenciadores de Banco de
Dados (SGBDs). São os SGBDs que vão permitir que aqueles dados sejam organizados e
persistidos, e posteriormente analisados para geração de informações úteis para tomadas de
decisões.
o Existem muitos tipo de bancos de dados e várias alternativas de SGBDs para cada um deles.
o Framework de acesso a bancos de dados persistentes: Existe uma gama de frameworks que podemos
utilizar em nossas aplicações e sistemas para facilitar o acesso ao banco de dados e, assim, persistir e
manipular os dados
o Esses frameworks são conhecidos como ferramentas de mapeamento-objeto-relacional (ORM),
e levam esse nome basicamente por proporcionarem um mapeamento de classes em tabelas de
bancos de dados de forma mais simples e clara.
o Exemplos de framework:
 Entity Framework: o Entity Framework é a principal ferramenta de persistência de
dados no universo .NET. O EF, como também é conhecido, dispões de três
metodologias para desenvolvermos o acesso ao banco de dados:
 Database First: nesta metodologia, já dispomos de um banco de dados e o
mapeamento na aplicação é feito a partir dele. É um método visual em que é
feita uma engenharia reversa, carregando quais classes representarão o
banco de dados na aplicação;
 Model First: nesta abordagem, também há um método visual, mas nele
podemos modelar nosso banco e gerar a base a partir dele;
 Code First: essa abordagem se diferencia das demais pelo fato de o trabalho
de mapeamento ser todo feito programaticamente. Primeiro implementamos
classes que representam nossas tabelas do banco de dados e, então,
deixamos que o próprio EF crie o banco de dados pra gente posteriormente;
 Hibernate: o Hibernate é o framework de ORM escrito em Java, mas também possui sua
versão em .NET, o NHibernate. Ele facilita o mapeamento da base de dados em nosso
modelo fazendo uso de arquivos XML ou anotações Java.

3.18 Mapeamento objeto-relacional.

3.19 Serviços de mensageria.

3.20 Padrões: SOAP, REST, XML, XSLT, UDDI, WSDL, JSON, RMI, XML-HttpRequest.

SOAP:

 Foi originalmente definido como Simple Object Access Protocol

 Definido como padrão baseado em XML para prestação de chamadas de procedimento internet (Não aceita
JSON e outros formatos).
 Pode ser utilizado sob protocolo HTTP
 Por causa da verbosidade do formato XML , SOAP pode ser mais lento do que as tecnologias concorrentes
tipo middleware CORBA
 Pode ser utilizado numa estrutura que já foi definida.
 Desvantagens: Maior quantidade de dados
 Não é necessário utilizar SOAP com HTTP (HyperText Transfer Protocol), porque há uma especificação para
usá-lo com SMTP (Simple Mail Transfer Protocol ).
 SOAP é um protocolo leve destinado à troca de informações estruturadas em um ambiente distribuído e
descentralizado. Uma mensagem SOAP, por exemplo, é um documento XML composto de três partes
obrigatórias: envelope, cabeçalho e corpo.
 Uma mensagem SOAP é codificada como um documento XML, consistindo em:
um elemento obrigatório <Envelope>, que contém um elemento opcional <Header> e um elemento <Body>
obrigatório. O elemento <Fault>, contido no <Body>, é usado para relatar erros.
o <Envelope>: É o elemento raiz do documento XML. Pode conter declarações de namespaces e
também atributos adicionais como o que define o estilo de codificação (encoding style).
o <Header>: É um cabeçalho que carrega informações adicionais, como por exemplo, se a
mensagem deve ser processada por um determinado nó intermediário. Deve ser o primeiro
elemento do Envelope.
o <Body>: é um subelemento obrigatório do envelope SOAP, que contém informações destinadas
para o destinatário final da mensagem
o <Fault> é um subelemento do corpo SOAP, que é usado para relatar erros.

REST:
  O padrão REST define um conjunto de restrições e propriedades baseado em HTTP
 REST é um estilo de arquitetura. Ele fornece padrões para a comunicação entre sistemas. REST não é um
padrão exclusivo para HTTP. Embora as bases do REST e do HTTP sejam as mesmas. Soluções de busca
de dados não estruturados.
 Usa menor quantidade de dados
 REST não tem mecanismo de recuperação de falhas para falhas de comunicação e nem suporta
mecanismos de privacidade de dados e integridade
 Na arquitetura REST, os clientes enviam solicitações para recuperar ou modificar recursos e os servidores
enviam respostas para essas solicitações.
 REST é o acrônimo de REpresentational State Transfer. Esse padrão é descrito em seis restrições
(princípios do REST).
o Uniform Interface: Este principio é definido por quatro restrições:
 Identificar os recursos (URI)
 Manipular recursos através de representações (Verbos HTTP).
 Mensagens auto-descritivas, cada requisição deve conter informações suficientes para o
server processar a informação.
 HATEOAS - Hypermedia As The Engine Of Application State. Esta restrição diz que a
response deve conter links de conteúdos relacionados ao resource. Por exemplo:
o Stateless: O servidor não mantém estado. Cada solicitação do client deve conter informações
necessárias para o server entender a solicitação. O estado da sessão é mantido inteiramente no
client.
o Cacheable: A resposta de uma solicitação deve implicitamente ou explicitamente informar se o
dado pode ser mantido em cache ou não. O cache deve ser mantido e gerenciado pelo Client.
o Client-server: Separar as responsabilidade do frontend do backend. Esse é um conceito bem
comum. Separar o front do back há ganhos significativos em testes, escalabilidade com reflexos
até na organização dos times dentro da empresa.
o Code on Demand (Opcional): o REST permite que a funcionalidades do client seja estendida
baixando e executando applets ou scripts.
o Layered system - O sistema deve ter uma arquitetura em camadas. A camada acima não pode
ver além da camada imediatamente abaixo dela.

JSON

 O JSON (JavaScript Object Notation) não é um protocolo de transporte de informações como o HTTP. Ele é
somente uma forma bem leve de representação e troca de informações. Ele tem a única função de levar
informações de um lado para o outro. Nós podemos utilizar o JSON para transportar informações entre
mensagens HTTP.
 O XML também é uma forma de representação de informações. Porém, é uma forma mais “pesada” e
verbosa de representação, já que preza pela “legibilidade” das informações a serem representadas.

XML

 É uma outra forma de representação de informações assim como JSON.

 O XML, sigla para eXtensible Markup Language, é um tipo de linguagem de marcação que define regras
para codificar diferentes documentos. É muito utilizado para a criação de Notas Fiscais Eletrônicas, também
chamadas de NF-e, por armazená-las e ainda garantir uma assinatura digital.
 Mais pesado em relação ao JSON
 Essa codificação interna é feita pelo uso de marcadores ou tags.
 A principal característica do XML, de criar uma infraestrutura única para diversas linguagens, é que
linguagens desconhecidas e de pouco uso também podem ser definidas sem maior trabalho e sem
necessidade de serem submetidas aos comitês de padronização.
 Sua filosofia seria incorporada por vários princípios importantes:
o Separação do conteúdo da formatação
o Simplicidade e legibilidade, tanto para humanos quanto para computadores
o Possibilidade de criação de tags sem limitação
o Criação de arquivos para validação de estrutura (chamados DTDs)
o Interligação de bancos de dados distintos
o Concentração na estrutura da informação, e não na sua aparência
 O XML é um formato para a criação de documentos com dados organizados de forma hierárquica, como se
vê, frequentemente, em documentos de texto formatados, imagens vetoriais ou bancos de dados.
 A XML usa um subconjunto da DTD (Document Type Definition) que ´ é um conjunto de declarações de
marcação que definem um tipo de documento para uma linguagem de marcação da família da SGML (SGML,
XML, HTML). Uma Definição de Tipo de Documento (DTD) define os blocos de construção lícitos de um
documento XML. Define a estrutura do documento com uma lista de elementos lícitos e atributos. Uma DTD
pode ser declarada em uma linha dentro de um documento XML ou na forma de uma referência externa.
Uma DTD (Document Type Definition) pode, ser definida como um conjunto de regras que define quais tipos
de dados e entidades farão parte de um documento XML. Estas regras serão utilizadas para que o
analisador sintático verifique se o documento está correto ou não.
 Vantagens:
 o É baseado em texto simples
o Suporta Unicode, permitindo que a maior parte da informação codificada em linguagem humana
possa ser comunicada
o Pode representar as estruturas de dados relevantes da computação: listas, registros, árvores
o É auto-documentado (DTDs e XML Schemas): o próprio formato descreve a sua estrutura e nomes
de campos, assim como valores válidos
o A sintaxe restrita e requerimentos de parsing tornam os algoritmos de análise mais eficientes e
consistentes
o Sem automação: editores txt antigos, tais como vi
o Com recurso automático de destaque: a maior parte dos editores txt modernos oferece recursos
para destaque de XML (distinção visual entre tag, atributo e conteúdo)
o Com recursos de validação e análise sintática: ferramentas um pouco mais sofisticadas, orientadas
a programadores, tais como as IDEs, ou orientadas a conteúdo, tais como editores XHTML, ambos
vem se adaptando para lidar com outros formatos XML, interpretando DTD, XSLT ou XSD

XSLT (eXtensible Stylesheet Language for Transformation - Linguagem de Folhas de estilo Extensível para
Transformações)
 é uma linguagem de marcação XML usada para criar documentos XSL que, por sua vez, definem a
apresentação dos documentos XML nos browsers e outros aplicativos que os suportem.
 atua como as folhas de estilos CSS: apenas determina como o browser deve apresentar o documento XML
ao qual ele está associado ou anexado (de uma forma bem parecida com a usada para associar uma folha
de estilos CSS a um documento (X)HTML).

WSDL

 WSDL é uma notação XML para descrever um serviço da web. Uma definição WSDL indica a um cliente
como compor uma solicitação de serviço da web e descreve a interface que é fornecida pelo provedor de
serviços da web.
 Uma definição WSDL é dividida em seções separadas que especificam a interface lógica e os detalhes
físicos de um serviço da web. Os detalhes físicos incluem informações de terminal, como número da porta
HTTP e informações de ligação que especifica como a carga útil SOAP é representada e qual transporte é
utilizado.
 RPC – Remote Procedure Calls (em português, chamada de procedimentos remotos) é um modelo que
define a forma como são realizadas as chamadas a operações remotas através de web services.
 Por meio de um WSDL você informa ao cliente como cada serviço em um end-point deve ser invocado: quais
os parâmetros e tipo de dados de cada parâmetro é esperado, e qual o tipo de dado do retorno será enviado
como resposta.
 Além de descrever cada serviço (que pode ser comparado analogamente à um método a ser executado no
programa servidor), também descreve como podem ser encontrados. Seus elementos básicos são:
o <types>: aqui deverão ser descritos os tipos de dados suportados pelo serviço em questão
o <message>: aqui devem ser especificados os padrões de entrada e saída de dados dos web
services
o <portType>: aqui devem ser descritos os agrupamentos lógicos das operações. São as operações
executadas pelo web service
o <binding>: aqui devem ser apresentados os protocolos de comunicação que os web services
utilizam
o <operation>: região que permite a especificação das assinaturas dos métodos disponibilizados
o <definitions>: elemento padrão de todos os documentos WSDL. Permite efetuar descrições sobre
schemas e namespaces
 Como citado no primeiro parágrafo, WSDL é utilizado diretamente com SOAP, quando um cliente realiza uma
chamada de serviço por meio de SOAP (é um protocolo utilizado para a troca de informações.),
primeiramente ele solicita o WSDL para entender como se dará esta negociação.
 REST trabalha sobre o protocolo HTTP puro, portanto não depende do protocolo SOAP para realizar a
comunicação, em consequência não necessita usar uma WSDL. Apenas os verbos HTTP são utilizados.
Neste caso, para um cliente solicitar serviços REST, ele necessita de antemão conhecer o caminho e
interface deles. Significa dizer que o desenvolvedor precisará de manual ou guia de programação para usar
uma API REST.
 Logo, o WSDL é uma interface de acesso a um webservice e o SOAP é o protocolo utilizado para trocar
mensagens entre o webservice e aplicação.Não existe relação nenhuma entre WSDL e REST. São
abordagens totalmente diferentes.

Protocolo HTTP:

 O HTTP é um protocolo de comunicação. Através dele o cliente e o servidor conseguem se comunicar,

seguindo um conjunto de regras bem definidas (por isso chamamos de protocolo). Por exemplo, se
estivermos falando de uma aplicação web, o cliente é o navegador, ele envia um pedido para o servidor web
usando o protocolo HTTP, com base nesse pedido, se tudo estiver correto, o servidor responde também
usando o mesmo protocolo o conteúdo solicitado.
  REQUEST: A Request ou requisição traduzindo diretamente para português, é o pedido que um cliente
realiza a nosso servidor. Esse pedido contém uma série de dados que são usados para descrever
exatamente o que o cliente precisa.
 METODOS HTTP: Tanto GET como POST como DELETE,UPDATE na verdade são métodos HTTP. Eles
indicam para o servidor qual a ação que o cliente deseja realizar. Quando realizamos uma requisição
obrigatoriamente precisamos informar um método.
o GET – é usado quando o cliente deseja obter recursos do servidor
o POST – é usado quando o cliente deseja enviar dados para processamento ao servidor, como os
dados de um formulário, por exemplo.
 RESPONSE: A Response (resposta) nada mais é do que a resposta que o servidor envia ao cliente. Essa
resposta pode conter os dados que realmente o cliente esperava receber ou uma resposta informando que
alguma coisa deu errado.
 Código 200,404,301,etc: Esses números são os chamados códigos HTTP. Quando o cliente faz uma
requisição ele espera uma resposta. O servidor pode realmente responder o que o cliente esperava ou
devolver outra informação, justamente nesse ponto entram os códigos HTTP. O servidor utiliza um código
desse na resposta para indicar o que aconteceu.
 A comunicação entre o cliente e o servidor é feita através de “mensagens HTTP”: o tráfego de dados
entre um cliente e um servidor é feito através de porções de informação chamadas mensagens. Em uma
“rodada” de comunicação, nós temos duas mensagens envolvidas: a mensagem enviada pelo cliente
solicitando algo, chamada de request; e a resposta do servidor para a solicitação realizada, chamada de
response. Estes dois componentes são essenciais para que a comunicação ocorra seguindo o protocolo
HTTP e não é possível ter um request sem que depois haja um response e vice-versa;
 O protocolo HTTP por definição não é “keep alive”: por padrão, uma conexão HTTP só dura até o
momento em que o ciclo request-response é concluído. Logo após este ciclo, a conexão é automaticamente
encerrada, ou seja: a conexão morre. Caso algum novo conteúdo precise ser trafegado entre o cliente e o
servidor, uma nova conexão é aberta. Hoje, até existe maneiras de se modificar esse comportamento
utilizando-se algumas flags na requisição (uma destas flags se chama justamente keep-alive), mas é
importante destacar que o protocolo originalmente não foi planejado para essa finalidade;
 O protocolo HTTP é utilizado de maneira assíncrona na maioria dos clientes: requisições HTTP são
assíncronas por definição do lado dos clientes. Isso quer dizer que, se você precisa disparar duas
requisições para baixar dois conteúdos distintos, o cliente pode disparar essas requisições ao mesmo tempo,
sendo que cada uma delas pode ser respondida em um tempo diferente.

UDDI

 Conhecido como Universal Description, Discovery and Integration

 É um serviço de diretório onde empresas podem registrar (publicar) e buscar (descobrir) por serviços Web
(Web Services).
 é ainda um framework de plataforma independente (desenvolvido na plataforma .NET) para descrever e
integrar os serviços de negócios usando a Internet, possibilitando assim uma exposição controlada dos
serviços da empresa.
 A comunicação é realizada através do SOAP e as interfaces web service são descritas por WSDL.
 UDDI consiste de duas partes:
o UDDI é uma especificação técnica para construir um diretório distribuído de negócios (businesses)
e serviços na Web. A informação UDDI é armazenada dentro de um formato específico XML,
definido por WSDL e XML Schema. A especificação inclui detalhes de uma API própria para
buscar dados existentes ou publicar novos dados.

o UDDI Business Registry, também conhecido como “UDDI cloud services” é uma implementação
operacional completa da especificação UDDI. Tal parte habilita qualquer um a buscar dados UDDI
existentes, e também, a qualquer empresa registrar-se a si própria e seus respectivos serviços.
 Um serviço de registro UDDI é um Web Service que gerencia informação sobre provedores, implementações
e metadados de serviços. Provedores de serviços podem utilizar UDDI para publicar os serviços que eles
oferecem. Usuários de serviços podem usar UDDI para descobrir serviços que lhes interessem e obter os
metadados necessários para utilizar esses serviços podem ter três partes:
o "páginas brancas" descrevem a companhia: nome, endereço, contatos, etc.
o "páginas amarelas" incluem as categorias, baseada em taxonomias padrões.
o "páginas verdes" descrevem a interface para o serviço em nível de detalhe suficiente para se
escrever uma aplicação que use o Web service.
 A especificação UDDI define:
o APIs SOAP utilizadas para publicar e obter informações de um registro UDDI
o Esquemas XML do modelo de dados do registro e do formato das mensagens SOAP
o Definições WSDL das APIs SOAP
o Definições de registro UDDI (modelos técnicos - tModels) de diversos sistemas de identificação e
categorização, que podem ser utilizados para identificar e categorizar registros UDDI

RMI

 Conhecido como RMI (Remote Method Invocation)

  é uma interface de programação que permite a execução de chamadas remotas no estilo RPC em aplicações
desenvolvidas em Java.
 É uma das abordagens da plataforma Java para prover as funcionalidades de uma plataforma de objetos
distribuídos.
 Através da utilização da arquitetura RMI, é possível que um objeto ativo em uma máquina virtual Java possa
interagir com objetos de outras máquinas virtuais Java, independentemente da localização dessas máquinas
virtuais
 O funcionamento de RMI consiste basicamente em dois programas, segundo a arquitetura cliente-servidor,
onde um seria o cliente e outro o servidor. O servidor instancia objetos remotos, o referência com um nome e
faz um "vinculo" dele numa porta, onde este objeto espera por clientes que invoquem seus métodos. Já o
cliente referencia remotamente um ou mais métodos de um objeto remoto. RMI fornece os mecanismos para
que a comunicação entre cliente e servidor seja possível. Esse tipo de aplicação geralmente é denominada
como Aplicação de Objeto Distribuído.
 Uma das principais vantagens do RMI é sua capacidade de baixar o código de um objeto, caso a classe
desse objeto não seja definida máquina virtual do receptor. Os tipos e o comportamento de um objeto,
previamente disponíveis apenas em uma máquina virtual, agora podem ser transmitidos para outra máquina
virtual, possivelmente remota. Essa funcionalidade do RMI permite que o código da aplicação seja
atualizado dinamicamente, sem a necessidade de compilar novamente o código.

RPC

 Chamada remota de procedimento (RPC, acrônimo de Remote Procedure Call) é uma tecnologia de
comunicação entre processos que permite a um programa de computador chamar um procedimento em
outro espaço de endereçamento (geralmente em outro computador, conectado por uma rede). O
programador não se preocupa com detalhes de implementação dessa interação remota: do ponto de vista do
código, a chamada se assemelha a chamadas de procedimentos locais.
 RPC é uma tecnologia popular para a implementação do modelo cliente-servidor de computação distribuída.
 No modelo RPC, o processo de invocação ocorre de maneira similar. Uma Thread é responsável pelo
controle de dois processos: invocador e servidor. O processo invocador primeiro manda uma mensagem
para o processo servidor e aguarda (autobloqueia) uma mensagem de resposta. A mensagem de invocação
contém os parâmetros do procedimento e a mensagem de resposta contém o resultado da execução do
procedimento. Uma vez que a mensagem de resposta é recebida, os resultados da execução do
procedimento são coletados e a execução do invocador prossegue.
 Do lado do servidor, um processo permanece em espera até a chegada de uma mensagem de invocação.
Quando uma mensagem de invocação é recebida, o servidor extrai os parâmetros, processa-os e produz os
resultados, que são enviados na mensagem de resposta. O servidor, então, volta a esperar por uma nova
mensagem de invocação.

XMLRequest
 XMLHttpRequest é um objeto que fornece funcionalidade ao cliente para transferir dados entre um cliente e
um servidor. Ele fornece uma maneira fácil de recuperar dados de um URL sem ter que fazer uma
atualização de página inteira. Isso permite que uma página da Web atualize apenas uma parte do conteúdo
sem interromper o que o usuário esteja fazendo. XMLHttpRequest é usado constantemente na programação
de AJAX.
 O objeto XMLHttpRequest é o sonho do desenvolvedor , porque você pode:
o Atualizar uma página da web sem recarregar a página
o Solicitar dados de um servidor após o carregamento da página
o Receba dados de um servidor após o carregamento da página
o Envie dados para um servidor em segundo plano

3.21 Streaming de Dados.

 Streaming é o nome dado à tecnologia que é capaz de transmitir dados através da internet sem a
necessidade de baixar o conteúdo em um dispositivo.
 Os arquivos transmitidos com mais frequência envolvem imagem e áudio, sendo vídeos curtos, longos e
músicas, porém, as opções são vastas, podendo incluir até mesmo textos e apresentações de slides.
 Como funciona: Assim como outros sistemas de envios de dados através da internet, arquivos do tipo áudio
e vídeo são divididos em pequenas partes e enviados separadamente pela rede. Assim que um dispositivo
recebe esse pacote, o player irá juntá-los em seu formato original.
 Este envio, diferente de textos e imagens estáticas, requer um transporte mais rápido, para que os usuários
não sintam que o arquivo está pela metade. Muitos reprodutores utilizam a função de buffer, que carrega o
vídeo ou a música antes mesmo de ela ser reproduzida, dando uma melhor sensação de continuidade.
 Quando há problemas na conexão, alguns players acabam alterando a qualidade do conteúdo reproduzido,
para ajustá-lo, evitando pausas incômodas, tendo que esperar pelo carregamento.
 Uso de diversos protocolos específicos para streaming:
o Streaming HLS: HTTP Live Streaming. Na prática, o HLS é um protocolo de streaming que
fornece mídia visual e de áudio aos espectadores pela Internet. Mais atual, robusto e qualidade
o HDS: HTTP Dynamic Streaming. Este protocolo foi projetado especificamente para compatibilidade
com o plug-in do navegador de vídeo Flash da Adobe.
 o RTMP: A Macromedia desenvolveu o RTMP (Real-Time Messaging Protocol – protocolo de
mensagens em tempo real) em meados dos anos 2000. Projetado para transmitir áudio e vídeo,
muitos conhecem esse protocolo simplesmente como Flash.
o MSS significa Microsoft Smooth Streaming (Streaming Suave). Como o nome indica, é a versão da
Microsoft de um protocolo de transmissão ao vivo.
o MPEG-DASH: DASH significa Dynamic Adaptive Streaming (streaming dinâmico adaptativo) para
HTTP. O MPEG-DASH vem com várias vantagens. Primeiro de tudo, é o primeiro protocolo de
streaming padrão internacional baseado em HTTP. Esse recurso ajudou a acelerar o processo de
adoção generalizada.

3.22 Arquitetura Publish-Subscribe.

 Permite a um aplicativo anunciar eventos para vários consumidores de seu interesse assincronamente, sem
acoplar os remetentes aos destinatários.
 Conhecido como pub/sub Messaging
 Em aplicativos distribuídos baseados em nuvem, normalmente, os componentes do sistema precisam
fornecer informações a outros componentes à medida que os eventos acontecem.
 Mensagens assíncronas são uma maneira eficiente de dissociar os remetentes dos consumidores e evitar o
bloqueio do remetente até receber uma resposta. No entanto, usar uma fila de mensagens dedicadas para
cada consumidor não é algo bom quando há vários consumidores. Além disso, talvez alguns consumidores
tenham interesse em apenas um subconjunto das informações.
 Um sistema assíncrono de mensagem que contém:
o Um canal de entrada de mensagens usado pelo remetente. O remetente insere os eventos nas
mensagens, usando um formato de mensagem conhecido, e envia essas mensagens por meio do
canal de entrada. O remetente nesse padrão também é chamado de publicador.
o Um canal de saída de mensagens por consumidor. Os consumidores são conhecidos como
assinantes.
o Um mecanismo para copiar cada mensagem do canal de entrada para os canais de saída de todos
os assinantes interessados nessa mensagem. Essa operação normalmente é tratada por um
intermediário, como um agente de mensagem ou barramento de evento.
 Vantagens:
o Ela separa subsistemas que ainda precisam se comunicar. Os subsistemas podem ser
gerenciados independentemente e as mensagens podem ser gerenciadas corretamente mesmo se
um ou mais destinatários estiverem offline.
o Ela aumenta a escalabilidade e melhora a capacidade de resposta do remetente. O remetente
pode enviar rapidamente uma única mensagem para o canal de entrada, e voltar às
responsabilidades de processamento principais. A infraestrutura de mensagens é responsável por
garantir que as mensagens sejam entregues aos assinantes interessados.
o Isso aumenta a confiabilidade. Mensagens assíncronas ajudam na execução tranquila dos
aplicativos sob cargas maiores e lidam com falhas intermitentes com mais eficiência.
o Ela permite o processamento agendado ou adiado. Os assinantes podem esperar para ver as
mensagens em um horário de pouco movimento, ou as mensagens podem ser roteadas ou
processadas de acordo com um agendamento específico.
o Ela permite uma integração mais simples entre sistemas com plataformas diferentes, linguagens
de programação ou protocolos de comunicação, bem como entre sistemas locais e aplicativos em
execução na nuvem.
o Ela facilita fluxos de trabalho assíncronos em toda a empresa.
o Ela melhora a capacidade de teste. Os canais podem ser monitorados, e as mensagens
inspecionadas ou registradas como parte de uma estratégia de teste geral de integração.
o Ela proporciona uma separação das preocupações com seus aplicativos. Cada aplicativo pode se
concentrar em suas funcionalidades principais, enquanto a infraestrutura de mensagens lida com
tudo que é necessário para rotear de forma confiável as mensagens para vários consumidores.

4. Linguagens de Programação.
4.1 Características estruturais das linguagens de programação.

 No passado escrevia-se programas utilizando apenas linguagens de baixo nível que é

composto por uma série de instruções de máquina que determinam quais operações o
processador deve executar. Essas instruções são convertidas para a linguagem que o
processador entende, que é a linguagem binária (sequência de bits 0 e 1), que é categorizada
como First-generation programming language (1GL), em livre tradução: linguagem de
programação de primeira geração. Ex: Assembly e Binário
 Linguagem de alto nível: novas linguagens surgiram e, cada vez mais, aproximavam-se da
linguagem humana. Isso abriu “fronteiras” para que uma enorme gama de novos
desenvolvedores se especializasse. Tais linguagens são denominadas como sendo de alto
nível.C, Python, Java, etc
 Quanto mais próxima da linguagem da máquina, mais baixo nível é a linguagem. Quanto mais
próxima da linguagem humana, mais alto nível ela é.
 Paradigmas de uma linguagem de programação:
o O paradigma de uma linguagem de programação é a sua identidade. Corresponde a
um conjunto de características que, juntas, definem como ela opera e resolve os
problemas. Algumas linguagens, inclusive, possuem mais de um paradigma, são as
chamadas multi paradigmas.
o Alguns dos principais paradigmas utilizados hoje no mercado:
 Funcional:
 O foco desse paradigma está na avaliação de funções. Ex: função f(x)
Algumas das linguagens que atendem a esse paradigma: F# (da
Microsoft), Lisp, Heskell, Erlang, Elixir, Mathematica.
 É possível desenvolver de forma “funcional” mesmo em linguagens
não estritamente funcionais. Por exemplo, no PHP, que é uma
linguagem multi paradigma, teríamos:
 Lógico:
 Também é conhecido como “restritivo”. Muito utilizado em aplicações
de inteligência artificial. Esse paradigma chega no resultado esperado
a partir de avaliações lógico-matemáticas. Se você já estudou lógica
de predicados, confortável se sentirá em entender como uma
linguagem nesse paradigma opera.
 Principais elementos desse paradigma:
o Proposições: base de fatos concretos e conhecidos.
o Regras de inferência: definem como deduzir proposições.
o Busca: estratégias para controle das inferências.
 Ex: Prolog
 Declarativo:
 O paradigma declarativo é baseado no lógico e funcional. Linguagens
declarativas descrevem o que fazem e não exatamente como suas
instruções funcionam.
 Linguagens de marcação são o melhor exemplo: HTML, SQL, XML,
XSLT, XAML
 Imperativo
 “programação procedural” ou em “programação modular”
 Linguagens clássicas como C, C++, PHP, Perl, C#, Ruby etc,
“suportam” esse paradigma.
 Ele é focado na mudança de estados de variáveis (ao contrário dos
anteriores).
 Orientado a objetos
 Na orientação a objetos utilizamos uma lógica bem próxima do mundo
real, lidando com objetos, estruturas que já conhecemos e sobre as
quais possuímos uma grande compreensão.
 O paradigma orientado a objetos tem uma grande preocupação em
esconder o que não é importante e em realçar o que é importante.
Nele, implementa-se um conjunto de classes que definem objetos.
Cada classe determina o comportamento (definido nos métodos) e
estados possíveis (atributos) de seus objetos, assim como o
relacionamento entre eles.
 Esse é o paradigma mais utilizado em aplicações comerciais e as
principais linguagens o implementam: C#, Java, PHP, Ruby, C++,
Python etc.
 Orientado a eventos
 Toda linguagem que faz uso de interface gráfica é baseada nesse
paradigma. Nele, o fluxo de execução do software é baseado na
ocorrência de eventos externos, normalmente disparados pelo
usuário.
 O usuário, ao interagir, decidirá em qual momento digitar, clicar no
botão de “salvar” etc. Essas decisões dispararão eventos. O usuário
é, então, o responsável por quando os eventos acontecerão, de tal
forma que fluxo do programa fica sensivelmente atrelado à
ocorrências desses eventos.
 Linguagens de programação que fazem uso de paradigma: Delphi,
Visual Basic, C#, Python, Java etc.
 Compilador é um programa de sistema que traduz um programa descrito em uma linguagem de
alto nível para um programa equivalente em código de máquina para um processador. Executa
análise e síntese, ou seja, analisar e traduzir.
 Interpretador: Enquanto um compilador analisa todo o código a fim de traduzi-lo de uma vez
(muitas vezes, o resultado é um arquivo executável ou uma biblioteca), o interpretador faz esse
trabalho de conversão aos poucos, sempre que uma declaração ou função é executada.
 “Quatro Pilares do PC”, ou bases do PC, que são:

• Decomposição: envolve identificar um problema (que pode ser complexo) e quebrá-lo em pedaços
menores de mais fácil análise, compreensão e solução
• Reconhecimento de Padrões: Cada um desses problemas menores pode ser analisado
individualmente em profundidade, identificando problemas parecidos que já foram solucionados
anteriormente
• Abstração: focando apenas nos detalhes que são importantes, enquanto informações irrelevantes são
ignoradas
• Algoritmos: Passos ou regras simples podem ser criados para resolver cada um dos subproblemas
encontrados

O que é Programação Estruturada?

 A programação estruturada é uma técnica de programação, independente da linguagem de programação,

que tem como objetivo construir programas claros, legíveis, eficientes e de fácil manutenção.
 A programação estruturada impõe uma disciplina rígida de programação que faz uso de três estruturas de
controle para a construção da lógica de um programa. Os três tipos de estrutura de controle são a
sequencia, a seleção e a repetição. Com apenas estes três tipos de estrutura de controle é possível
construir programas sem o uso de desvios incondicionais tipo GOTO.

"Para mapear a representação da herança do paradigma orientado a objetos para o modelo relacional podemos utilizar
três maneiras diferentes. A primeira é simplesmente criar uma tabela para cada classe. A segunda forma é criar uma
única tabela para toda a hierarquia de classes. Por último, pode-se criar uma tabela para cada classe concreta."

Para mapear a representação da herança do paradigma orientado a objetos para o modelo relacional, uma
alternativa válida é copiar os atributos herdados em todas as tabelas criadas a partir das classes herdeiras, sem
gerar uma tabela para representar a superclasse. (CERTO)

CESPE 2011 - A linguagem de montagem constitui uma versão da linguagem de máquina; cada instrução é
representada por uma cadeia de texto que descreve o que a instrução faz. Nesse processo, o montador é o
elemento que converte instruções em linguagem de montagem para linguagem de máquina. (CERTO)

CESPE 2018 - Compilador é o programa que traduz o código fonte de uma linguagem de programação de alto nível
para uma linguagem de programação de baixo nível. (CERTO)

CESPE - 2013 - Interpretador é um tradutor de linguagem que executa o programa fonte de imediato, em vez de
gerar um código objeto a ser executado após o término da tradução, enquanto o compilador recebe um programa
fonte e produz programa equivalente na linguagem alvo. No caso da linguagem Java, os processadores combinam
compilação e interpretação. (CERTO)

O pensamento computacional utiliza quatro dimensões interdependentes e de grande importância

durante o processo de formulação de soluções computacionalmente viáveis. Essas dimensões são
decomposição, reconhecimento de padrões, abstração e algoritmos.

Na programação estruturada, as estruturas características da técnica de modularização são

procedimento e função.

A repetição é uma das estruturas de controle básico utilizadas na programação estruturada. (CERTO)

4.2 Orientação a objetos.

Modelos de objeto descrevem o sistema em termos de classes de objetos

Uma classe de objeto é uma abstração sobre um conjunto de objetos com atributos em comum e os
serviços(operações) fornecidos por cada objeto

Vários modelos de objetos podem ser produzidos

 Modelos de herança
 Modelos de agregação
 Modelos de interação

Classe:

 Representa alguma estrutura do mundo real (molde) com a qual nosso código terá que lidar. Ex:
Carro
 Uma classe especifica a estrutura de um objeto, sem informar quais serão seus valores. Em
contrapartida, um objeto corresponde à ocorrência (instância) de uma classe num determinado
momento.
 Atributos: São características de um molde ou estrutura do mundo real. Ex: As características de um Carro
tais como Marca/ Modelo/ Cor / Placa / Outros
 Métodos: São ações que um molde pode desempenhar. Ex: um carro pode ter as seguintes ações: Ligar;
Acelerar; Desligar; Frear; etc
 No final, os métodos e atributos ficam agrupados em uma classe.
 A classe Carro, se fosse representada pelo diagrama de classes UML, poderia ficar da seguinte maneira:

 Objetos: Objetos são como variáveis que criamos para utilizar as nossas classes , seja para
definir seus atributos, como também para invocar seus métodos. Ex: É o encadeamento
coordenado entre escritas e leituras de atributos com a invocação de métodos que dá a tônica de
uma aplicação escrita com uma linguagem orientada a objetos.
Objetos são instâncias de classes e possuem:

o Identidade: Que é responsável por distinguir um objeto dos outros, isto é, eles são únicos,
mesmo que sejam instâncias de uma mesma classe e que tenham os mesmos valores
variáveis.

o Comportamento (operações): Se refere a como os objetos reagem em relação a mudança

de estado e troca de mensagens, isto é, é um conjunto de atividades externamente
observáveis do objeto.

o Estado (propriedades): Reflete os valores correntes dos atributos do objeto em um

determinado momento.

Em resumo, identidade é o que torna o objeto único, estado se refere aos seus atributos e comportamento se
refere aos seus métodos e procedimentos.

Objeto é definido como instância de uma classe. Em outras palavras, é uma ocorrência específica de uma
classe (que é a planta ou esquema que indica como os objetos são criados).
Perceba que a partir deste molde, nós podemos especificar vários carros… Poderíamos ter um
Fiat Línea prata com a placa ABC-1234, um Volswagen Gol preto com a placa DEF-4567 ou
mesmo um Hyundai HB20 branco com a placa GHI-8901… Todos eles são carros, já que
derivam do mesmo molde: todos eles têm marca, modelo, cor e placa, além de poderem ser
ligados, desligados, freados e acelerados, atributos e métodos todos estabelecidos pela classe
Carro.
// Pacotes e demais estruturas omitidas para clareza...
public class Carro {
public String modelo;
public String marca;
public String cor;
public String placa;

public void ligar() {

System.out.println("O veículo ligou!");
}

public void desligar() {

 System.out.println("O veículo desligou!");
}
}
// ...
Carro gol = new Carro();
gol.modelo = "Gol";
gol.marca = "Volkswagen";

Carro linea = new Carro();

linea.modelo = "Línea";
linea.marca = "Volkswagen";

# gol e linea são instancias de tipo classe Carro portanto estes objetos tem todos os atributos e métodos previstos pela classe Carro.
gol.ligar();
gol.desligar();
linea.ligar();
linea.desligar();

Encapsulamento (PROTEGE/BLINDA CONTRA ACESSOS INDEVIDOS). Conhecido como atributo de

visibilidade

 O encapsulamento visa esconder atributos e métodos de nossas classes que não deveriam ser acessados
por outras estruturas.
 O encapsulamento nas linguagens orientadas a objetos é definido através de algo que chamamos de atributo
de visibilidade. Estes atributos de visibilidade estabelecem justamente o quão acessível nossos atributos e
métodos são com relação às demais estruturas do nossos códigos.
 Existem três atributos de visibilidade básicos e comuns às linguagens orientadas a objeto em geral:
o public: a estrutura é visível a partir de qualquer lugar no código, inclusive em outras classes fora a
classe que define o atributo ou método em si;
o private: a estrutura é visível somente pela classe que define a estrutura em si. Estruturas externas,
como outras classes, não conseguem acessar o método ou atributo que esteja marcado com este
atributo de visibilidade;
o protected: a estrutura é visível somente na classe-mãe e nas classes-filhas.
 É exatamente o que precisamos: o atributo ligado deveria ser acessível em tese só pela própria classe Carro,
o que permitiria somente aos métodos ligar() e desligar() alterarem o indicador de funcionamento do carro da
maneira correta. Isso evitaria que nós acessássemos o atributo do lado de fora, causando a falha no código.

public class Carro {

public String modelo;

public String marca;
// ...
private boolean ligado;

// Contrutor - new Quando um construtor é explicitamente definido, o construtor padrão

implícito deixa de existir
public Carro() {
ligado = false;
}

public void ligar() {

ligado = true;
System.out.println("O veículo ligou!");
}

public void desligar() {

ligado = false;
System.out.println("O veículo desligou!");
}

public void acelerar() {

if (!ligado){
throw new Exception("O carro não pode ser acelerado, pois ele está desligado."); // Erro: o carro está desligado!
}
System.out.println("O carro foi acelerado");
}
}

Carro gol = new Carro();

gol.ligado = true; // Essa linha causará um erro de compilação, pois o atributo "ligado" não é mais acessível externamente
 Método de acesso:
o ele provê um tipo de acesso indireto a um atributo encapsulado. Com relação ao encapsulamento,
nós temos dois tipos de métodos de acesso basicamente:
 get: métodos que permitem ver o valor de um atributo;
 set: métodos que permitem alterar o valor de um atributo.
o É uma prática recorrente em linguagens orientadas a objeto (principalmente no Java) envolver
todos os atributos com métodos de acesso do tipo get e set, evitando o acesso direto aos
atributos.
o Apesar de ser uma prática comum, é importante dizer que só o fato de utilizarmos métodos de
acesso não garante o encapsulamento de nenhuma estrutura. O que garante este encapsulamento
é a definição de visibilidade correta de cada um dos atributos e métodos e o estabelecimento dos
métodos de acesso de maneira correta. Por exemplo: não criamos um método set para o atributo
ligado, pois ele só pode ser alterado pela própria classe.
 public class Carro {

private String modelo;

private String marca;
// ...
public boolean ligado;

public void setModelo(String modelo) {

this.modelo = modelo;
}

public String getModelo() {

return modelo;
}

public void setMarca(String marca) {

this.marca = marca;
}

public String getMarca() {

return marca;
}

public Carro() {
ligado = false;
}

public void ligar() {

ligado = true;
System.out.println("O veículo ligou!");
}

public void desligar() {

ligado = false;
System.out.println("O veículo desligou!");
}

public void acelerar() {

if (!ligado){
throw new Exception("O carro não pode ser acelerado, pois ele está desligado."); // Erro:
o carro está desligado!
}
System.out.println("O carro foi acelerado");
}

public boolean estaLigado() {

return ligado;
}
}

Herança

 O reaproveitamento de código e a possibilidade de se evitar código duplicado são objetivos das linguagens
orientadas a objetos.
 Quando temos a herança sendo utilizada, as classes podem assumir um dos dois papéis:
o Classe-mãe, classe-base ou super-classe: é a classe que serve de base para as demais
classes. Em nosso exemplo, a classe Veiculo é uma super-classe;
o Classe-filha ou sub-classe: é a classe que herda outra determinada classe. No nosso exemplo,
as classes Carro e Bicicleta são sub-classes.
 Nesse exemplo, se fôssemos aplicar o conceito de herança, nós teríamos três classes:
o A classe Carro, com tudo que um carro possui de características e ações;
o A classe Bicicleta, com tudo que uma bicicleta possui de características e ações;
o Uma nova classe chamada Veiculo, com tudo que existe de comum entre Carro e Bicicleta.


o No exemplo acima, para que as classes Carro e Bicicleta conseguissem usufruir das estruturas
comuns estabelecidas na classe Veiculo, elas precisariam herdar a classe Veiculo através de
comando EXTENDS do java.

public class Veiculo {

 private String modelo;
private String marca;

public void setModelo(String modelo) {

this.modelo = modelo;
}

public String getModelo() {

return modelo;
}

public void setMarca(String marca) {

this.marca = marca;
}

public String getMarca() {

return marca;
}

public void acelerar() {

// ???
}

public class Carro extends Veiculo {

public boolean ligado;

public Carro() {
ligado = false;
}

public void ligar() {

ligado = true;
System.out.println("O veículo ligou!");
}

public void desligar() {

ligado = false;
System.out.println("O veículo desligou!");
}

public void acelerar() {

if (!ligado){
throw new Exception("O carro não pode ser acelerado, pois ele está desligado."); // Erro: o carro está desligado!
}
System.out.println("O carro foi acelerado");
}

public boolean estaLigado() {

return ligado;
}
}

public class Bicicleta extends Veiculo {

public void acelerar() {

System.out.println("A bicicleta acelerou!");
}

}
LEMBRETE: Java não oferece HERANCA MULTIPLA e apenas SIMPLES, porém é possível
implementar herança múltipla através do comando IMPLEMENTS (conceito de implements
(implementar uma ou mais interfaces), para com isso emular a herança múltipla.)

Abstração

o É o ponto de partida para criação de programas utilizando POO. Trata-se da capacidade de extrair dos
personagens ou dos itens presentes no contexto, suas principais características, criando desta forma,
objetos. É a captura das principais características do personagem ou item envolvido do contexto para que
elas possam ser facilmente descritas em uma classe que gerará um objeto.
o Abstrair quer dizer é a forma de concentrarmos apenas nos aspectos essenciais do nosso cenário. (Não é
coletar TODAS as informações de um contexto)
o No exemplo anterior, nós esbarramos em um problema de abstração: todo veículo é capaz de acelerar,
independente de ser um carro ou bicicleta. Sendo assim, nós não podemos remover o método acelerar() da
nossa classe Veiculo, já que todo veículo tem esse comportamento. Mas, a própria classe Veiculo não
“sabe” como acelerar.
o Quem sabe como acelerar é a classe Carro(que sabe como um carro acelera) e a classe Bicicleta (que sabe
como uma bicicleta acelera). Para resolver esta situação, poderíamos tornar o método acelerar() abstrato:
isso vai desobrigar a classe Veiculo a definir uma implementação para este método (já que a classe Veiculo
não sabe como acelerar), mas obriga as classes-filha (no caso, as classes Carro e Bicicleta) a
definirem seus comportamentos de aceleração.
o Toda Classe abstrata não pode ser instanciada

// Classe abstrata (não pode ser instanciada)

public abstract class Veiculo {

private String modelo;

private String marca;
 public void setModelo(String modelo) {
this.modelo = modelo;
}

public String getModelo() {

return modelo;
}

public void setMarca(String marca) {

this.marca = marca;
}

public String getMarca() {

return marca;
}

// Método abstrato: a classe Veiculo sabe que ela tem que acelerar, mas não sabe como fazer isso.
// A responsabilidade passa a ser das classes-filha
public abstract void acelerar();

public class Carro extends Veiculo {

public boolean ligado;

public Carro() {
ligado = false;
}

public void ligar() {

ligado = true;
System.out.println("O veículo ligou!");
}

public void desligar() {

ligado = false;
System.out.println("O veículo desligou!");
}

// Aqui, a classe Carro define como ela deve exercer o ato de acelerar
@Override
public void acelerar() {
if (!ligado){
throw new Exception("O carro não pode ser acelerado, pois ele está desligado."); // Erro: o carro está
desligado!
}
System.out.println("O carro foi acelerado");
}

public boolean estaLigado() {

return ligado;
}
}

public class Bicicleta extends Veiculo {

// Aqui, a classe Bicicleta define como ela deve exercer o ato de acelerar
@Override
public void acelerar() {
System.out.println("A bicicleta acelerou!");
}

Metaclasse

Em orientação a objetos, uma metaclasse é uma classe cujas instâncias também são classes e não objetos
no sentido tradicional. Assim como classes definem o comportamento de certos objetos, metaclasses
definem o comportamento de certas classes e suas instâncias. Metaclasse é uma classe que descreve
outra classe, isto é, ela é uma classe cujas instâncias são classes. Portanto, uma metaclasse guarda a
metainformação de uma classe.

Poliformismo:

 Estruturas polimórficas são estruturas que conseguem mudar seu comportamento interno em determinadas
circunstâncias.
 Mesmo nome, com funções diferentes
 Polimorfismo é o princípio pelo qual duas ou mais classes derivadas de uma mesma superclasse
podem invocar métodos que têm a mesma identificação, assinatura, mas comportamentos distintos,
 especializados para cada classe derivada, usando para tanto uma referência a um objeto do tipo da
superclasse.
 Existem dois tipos de polimorfismo:
o sobrecarga de métodos (overload) é um conceito do polimorfismo que consiste basicamente em
criar variações de um mesmo método, ou seja, a criação de dois ou mais métodos com nomes
totalmente iguais em uma classe. A Sobrecarga permite que utilizemos o mesmo nome em mais de
um método contanto que suas listas de argumentos sejam diferentes para que seja feita a
separação dos mesmos.
o Sobreposição/Sobrescrita de métodos (override) é um conceito do polimorfismo que nos
permite reescrever um método, ou seja, podemos reescrever nas classes filhas métodos criados
inicialmente na classe pai, os métodos que serão sobrepostos, diferentemente dos
sobrecarregados, devem possuir o mesmo nome, tipo de retorno e quantidade de parâmetros do
método inicial, porém o mesmo será implementado com especificações da classe atual, podendo
adicionar um algo a mais ou não. Diferente da sobrecarga, a sobreposição funciona por meio do
sistema de herança, e para a mesma funcionar o nome e lista de argumentos dos métodos devem
ser totalmente iguais aos da classe herdada.
o Polimorfismo do tipo ad-hoc: Sobrecarga (overloading) e coerção (coercion);
o polimorfismo universal: inclusão (Inclusion - overriding) e Paramétrico (parametric);

Tempo de compilação -> Poliformismo por sobrecarga:

• O acoplamento é estático ou adiantado (“early”) se ocorre antes do tempo de execução, e

permanece inalterado durante a execução do programa

Tempo de execução -> Poliformismo por sobrescrita

• O acoplamento é dinâmico ou atrasado (“late”) se ocorre durante o tempo de execução, e muda

no curso da execução do programa
 Essa variação comportamental pode acontecer por duas formas, como através da
o Sobrescrita de métodos
 No exemplo anterior, nós temos um exemplo de polimorfismo através da sobrescrita de
métodos: nós temos a classe Veiculo, que possui o método abstrato acelerar(). O
método é abstrato porque a classe Veiculo só sabe que tem que conter este
comportamento, mas não sabe como esse comportamento deve ocorrer.
 Mas, as classes Carro e Bicicleta foram obrigadas a implementar o método acelerar()
por herdarem a classe Veiculo. Cada uma dessas classes implementou o método
acelerar() da maneira mais adequada para cada um dos tipos de veículos. Aqui, já temos
um exemplo de polimorfismo: as classes Carro e Bicicleta são polimórficas, pois
possuem um ancestral comum (a classe Veiculo) que as obriga a implementar o método
acelerar(), mas cada uma delas implementa o mesmo método da maneira mais correta
para cada tipo de veículo.
o LSP (Liskov Substitution Principle)
 Padrão Sintaxe:

NomeDaInterface variavelDeReferencia = new ClasseQueImplementaInterface(); (Exemplo de instância em java)

obs: A interface faz o papel de superclasse e a classe que a implementa faz o papel de classe filha que, tem a
obrigação de implementar (sobrescrever) cada método (assinatura) definido no contrato (interface);

O Princípio de Substituição de Liskov diz que objetos podem ser substituídos por seus subtipos sem que isso afete
a execução correta do programa.


Veiculo veiculo = new Carro();

// ...
veiculo.acelerar(); // Vai escrever "O carro foi acelerado"
// ...
 Nós podemos definir o objeto veiculo como sendo do tipo Veiculo, mas o criar com
base em um Carro. Nesse momento, o objeto veiculo vai se comportar como um Carro.
No caso acima, dizemos que Veiculo é a abstração, enquanto Carro é a concretização.
Se quiséssemos trocar o tipo do nosso veículo para uma bicicleta, bastaria trocar a
concretização.

Veiculo veiculo = new Bicicleta();

// ...
veiculo.acelerar(); // Vai escrever "A bicicleta foi acelerada"
// ...
 Se quiséssemos trocar o tipo do nosso veículo para uma bicicleta, bastaria trocar a
concretização. Todo o código acima continuaria funcionando normalmente, já que uma
Bicicleta também é um Veiculo. Isso torna nosso código muito mais flexível (se
quisermos alterar o comportamento do nosso código, basta trocar as concretizações) e a
 prova de falhas de escrita de código (já que a abstração vai garantir que o código que
vier logo abaixo da definição da concretização vai continuar funcionando de maneira
transparente).
 podemos dizer que o objeto veiculo é um objeto polimórfico, pois a concretização está
sendo capaz de alterar seu comportamento. Porém, todo o código subsequente não é
afetado por essa troca.

Na programação orientada a objetos (POO), uma ação executada por um objeto quando passada uma
mensagem ou em resposta a uma mudança de estado representa o conceito de : comportamento (Uma
ação executada por um objeto quando passada uma mensagem, temos a definição de comportamento.
Seriam os métodos de uma classe.)

Em programação orientada a objetos, métodos de acesso do tipo setter têm a finalidade primária de
modificar o valor de um atributo (Dois principais métodos GET e SET utilizados no conceito de
Encapsulamento, em que você busca tentar proteger o acesso a sua classe por meio desses métodos.)

Quando se diz que uma classe “Pessoa” estende a classe “Humano”, em Programação Orientada a
Objetos, estamos afirmando o mesmo que a classe “Pessoa” deriva da classe “Humano”. Outras
representações:
Pessoa estende a classe Humano.
Pessoa é uma subclasse de Humano.
Pessoa é derivada da classe Humano.
Humano é uma superclasse de Pessoa.
I - Encapsulamento é a vinculação dos dados e seus métodos assessores, criando uma forma de
proteção contra interferências externas. (CERTO)
II Um objeto instanciado a partir de uma classe abstrata precisa instanciar métodos tidos como abstratos
dessa classe. (ERRADO)
III Interfaces e sobrecarga de métodos são tipos diferentes de polimorfismo. (CERTO)
IV Em uma linguagem baseada em protótipos (prototype-based), o conceito de classes é inexistente;
existem somente objetos. (CERTO) Estão corretas apenas I,III e IV somente

Orientação a objetos é um paradigma de análise, projeto e programação de sistemas de software

baseado na composição e interação entre diversas unidades de software chamadas objetos. Marque a
alternativa INCORRETA com relação a programação de orientação a objetos.

Os pacotes são pastas as quais podemos guardar arquivos (classes). (CERTO)

Declarar um objeto é o mesmo que instanciar um objeto. (ERRADO) declarar é Classe e instanciar um
objeto é NEW.
Cada objeto possui um endereço de memória.(CERTO)
O comportamento de um objeto é definido pelos métodos de sua classe.(CERTO)
Atributos estáticos são conhecidos como atributos de classes. (CERTO)

Considerando os conceitos de Herança, presentes na linguagem orientada a objetos Java, é correto

afirmar que:
A - uma vantagem da herança como forma de aumentar a possibilidade de reuso é que ela cria
dependências entre classes em uma hierarquia (ERRADA) não cria dependência ou seja, é
desvantagem
B- a herança não oferece uma solução para o problema de modificação oriundo do reuso de tipos
abstratos de dados (ERRADA) oferece solução de reuso
C- podem existir métodos na classe pai que não sejam visíveis na subclasse (CERTO) Métodos privados
não são acessados
D- os métodos de classe podem realizar operações somente na classe pai (ERRADO) Pai e Filha
Assim como a classe, um objeto é uma estrutura puramente estática, baseada em sua própria classe de
origem. (ERRADA) objeto é dinâmico

O conceito de Programação Orientada a Objetos que permite construir objetos especializados utilizando
características de objetos mais generalistas, possibilitando reuso de código à medida que os atributos e
métodos de classes já existentes podem gerar novas classes mais específicas, é o de HERANCA

Considerando o paradigma orientado a objetos, o que é uma Instância de Classe? Uma ocorrência
específica de uma classe.

Assinale a alternativa que apresenta uma motivação válida para a passagem de parâmetro por valor para
uma função. (Garantia de que o valor da variável original não será alterado.)
o Na Passagem de Parâmetro por Valor uma cópia do valor de um argumento é feito no
parâmetro da função (aqueles entre os parênteses). Ao fazer esta cópia do valor, qualquer
alteração feita no parâmetro não terá nenhum efeito nas variáveis usadas para chamá-la.
o Na Passagem de Parâmetro por Referência passamos todo o endereço do argumento para o
parâmetro. Devido a isto, qualquer alteração feita no parâmetro afeta a variável usada para
chamar a função, pois dentro da função é usado o endereço real do argumento para acessá-lo
na hora da chamada da função.

Na POO, uma classe pode ser derivada de outra, determinando famílias de classes por meio
 de hierarquia. Nesse caso, uma subclasse pode derivar de uma superclasse já existente, e
esta superclasse herda atributos e funcionalidades da subclasse. (ERRADO) pois Superclasse
não herda nada de subclasse. Subclasses sim herdam da superclasse.

O encapsulamento em uma classe garante que seus métodos e suas variáveis tenham alta
coesão e baixo acoplamento, seguindo os objetivos básicos da programação orientada a
objetos. (ERRADO) pois alta coesão: Trata-se de objetos que possuem apenas
responsabilidades inerentes a sua função / baixo acoplamento: Quanto menos classes
dependendo de uma funcionalidade específica, menor será o acoplamento, senão, uma
mudança nessa função implicará em mudanças em vários pontos do código. Uma maneira de
resolver isso, é injeção de dependência. Logo, a técnica de encapsulamento não garante alta
coesão e baixo acoplamento pois Encapsulamento é a técnica que faz com que detalhes
internos do funcionamento dos métodos de uma classe permaneçam ocultos para os objetos.
Por conta dessa técnica, o conhecimento a respeito da implementação interna da classe é
desnecessário do ponto de vista do objeto, uma vez que isso passa a ser responsabilidade
dos métodos internos da classe.

Na programação orientada a objetos, uma das características do polimorfismo é a

independência do software que invoca o comportamento polimórfico em relação aos tipos de
objeto para os quais as mensagens são enviadas. (CERTO) software significa método

Coesão e acoplamento são dois critérios úteis para se analisar a qualidade da interface
pública de uma classe. A interface pública será considerada coesa se todos os seus recursos
estiverem relacionados ao conceito que a classe representa, enquanto, no acoplamento, uma
classe é dependente de outra. (CERTO) pois Coesão está, na verdade, ligado ao princípio da
responsabilidade única, que foi introduzido por Robert C. Martin no inicio dos anos 2000 e diz
que uma classe deve ter apenas uma única responsabilidade e realizá-la de maneira
satisfatória, ou seja, uma classe não deve assumir responsabilidades que não são suas . Uma
vez sendo ignorado este princípio, passamos a ter problemas, como dificuldades de
manutenção e de reuso. Já o acoplamento significa o quanto uma classe depende da outra
para funcionar. E quanto maior for esta dependência entre ambas, dizemos que estas classes
elas estão fortemente acopladas. O forte acoplamento também nos traz muitos problemas,
problemas até semelhantes aos que um cenário pouco coeso nos traz.

o Caso de Uso e Programação

No diagrama temos quatro Casos de Uso, e três

relacionamentos diferentes: Include, Extend e
Generalization.

Explicando o Include: O caso de uso “Solicitar Material” faz

include no caso de uso “Checar Estoque”. Isso se dá porque
sempre que houver a solicitação de material sempre haverá a
consulta ao estoque para saber se o material está disponível.
Se sempre haverá, o relacionamento correto é o include.

Explicando o Extend: O caso de uso “Comprar Material”

estende o caso de uso “Solicitar Material”. Isso se dá porque
quando houver a solicitação de material, caso o material não
exista em estoque (após consulta via o caso de uso “Checar estoque”) poderá ser solicitado a compra do item. Mas
também poderá não ser solicitada a compra, pois o item pode existir em estoque. Se poderá ser solicitada a compra (e
não sempre será solicitada a compra) o relacionamento correto é o extend.

Explicando o Generalization: O caso de uso “Comprar Material” generaliza o caso de uso “Emitir pedido de compra”.
Isso se dá porque no caso de uso “Emitir pedido de compra” existe especificação de como se realiza o pedido de
compra, processo que não se dá somente no contexto do almoxarifado, mas é o mesmo em qualquer área do negócio.
Dessa forma, não justifica-se duplicar a especificação pertinente em outro caso de uso, basta reaproveitar o que já está
pronto mas generalizado a ponto de poder ser aproveitado por alguém que o especialize.

Para elaborar um Diagrama de Casos de Uso, primeiramente, temos que ter domínio sobre todos os elementos que o
compõe e saber como representá-los:

Atores: são os usuários do sistema, podendo representar uma pessoa, um dispositivo ou um componente
externo que interage com o sistema. Exemplos: Funcionário, Gerente, Sistema Integrado ou Sensor Eletrônico.
São representados pelo desenho de uma pessoa.

Casos de Uso: são ações executadas por um ou mais atores. Exemplos: Marcar Consulta,
Cancelar Consulta e Abrir Conta. São representados por uma elipse.
Relacionamento: é indicado por uma linha ou seta (quando necessita indicar sentido do tráfego de informação), que
liga os envolvidos. Existem alguns tipos de relacionamento, tais como:

o Entre ator e caso de uso: Indica a ação que o ator pode realizar. No exemplo abaixo, um
Funcionário pode Efetuar pagamento.

o Generalização/Especialização: ocorre entre dois ou mais casos de uso semelhantes que apresentem uma
ou mais características específicas. Assim, cria-se um caso de uso generalizado que engloba as características gerais,
enquanto as diferenças são apresentadas nos casos de uso específicos. Esse tipo de relacionamento também pode
ocorrer com atores.

No exemplo abaixo, o ator Funcionário apresenta as características gerais de todos os funcionários, mas o
engenheiro e o eletricista apresentam características ou funções específicas que outro funcionário não pode
operar. O mesmo ocorre com os casos de uso, onde Pagar no Crédito apresenta diferenças em relação a Pagar
no Débito, mas os dois estão Efetuando Pagamento.

o Include: relação entre dois casos de uso, onde o primeiro, para executar sua ação, precisa
chamar o segundo caso de uso. Existe uma dependência que obriga a execução do caso de uso incluso.
Sua representação é por uma seta pontilhada com o rótulo include que aponta para o caso de uso
incluso.

o Extend: relação entre dois casos de uso, onde o caso de uso estendido pode ser ou não
acionado se determinadas condições forem satisfeitas. É representado por uma seta pontilhada com o
rótulo extend que aponta para o caso de uso do qual se estende.

Lista de Diagramas da UML:

1) Diagrama Estrutural (Objetivo: Mostrar o esqueleto e não comportamentais)

a. Diagrama de Classes: É uma representação da estrutura e relações das classes que servem de
modelo para objetos. É uma modelagem muito útil para o desenvolvimento de sistemas, pois
define todas as classes que o sistema necessita possuir e é a base para a construção dos
diagramas de comunicação, sequência e estados.

b. Diagrama de Objetos: é uma variação do diagrama de classes e utiliza quase a mesma notação.
A diferença é que o diagrama de objetos mostra os objetos que foram instanciados das classes. O
diagrama de objetos é como se fosse o perfil do sistema em um certo momento de sua execução.
c. Diagrama de componentes: Ilustra como as classes deverão se encontrar organizadas através da
noção de componentes de trabalho. Por exemplo, pode-se explicitar, para cada componente, qual
das classes que ele representa.
Componentes: Peça física distribuível e substituível de código e que contém elementos que
apresentam um conjunto de interfaces requeridas e fornecidas.
 É utilizado para:
 Modelar os dados do código fonte, do código executável do software.
 Destacar a função de cada módulo para facilitar a sua reutilização.
 Auxiliar no processo de engenharia reversa, por meio da organização dos módulos do
sistema e seus relacionamentos.
d. Diagrama de Instalação/Implantação: descreve os componentes de hardware e software e sua
interação com outros elementos de suporte ao processamento. Representa a configuração e a
arquitetura de um sistema em que estarão ligados seus componentes, sendo representado pela
arquitetura física de hardware, processadores,etc.
Conceitos:
 Nó: Representa uma peça física de equipamento na qual o sistema será implantado.
 Artefatos: Qualquer pedaço físico de informação usada ou produzida por um sistema.
 Especificação de implantação: Especifica um conjunto de propriedades que determina
os parâmetros de execução de um artefato que está instalado em um nó.

e. Diagrama de Pacotes: O Diagrama de pacotes, ou diagrama de módulos, definido pela UML,

descreve os pacotes ou pedaços do sistema divididos em agrupamentos lógicos mostrando as
dependências entre eles. Este diagrama é muito utilizado para ilustrar a arquitetura de um sistema
mostrando o agrupamento de suas classes.
f. Diagrama de Estrutura Composta: destina-se a descrição dos relacionamentos entre os
elementos. Utilizado para descrever a colaboração interna de classes, interfaces ou componentes
para especificar uma funcionalidade.
Conceito:
 Colaboração: Define um conjunto de regras e suas ligações para ilustrar uma
funcionalidade específica.
 Parte: Representa as classes internas que compõem uma classe encapsuladora
chamada Container.
 Port: a interação entre uma classe e/ou objeto e sua interface.
 Papéis: são as instâncias que cooperam entre si para concluir uma tarefa.

2) Diagrama Comportamentais/Dinâmicos (Objetivo: Mostrar apenas os comportamentos)

a. Diagrama de Caso de Usos: descreve a funcionalidade proposta para um novo sistema que será
projetado, é uma excelente ferramenta para o levantamento dos requisitos funcionais do sistema.
descreve a sequência de eventos de um ator que usa um sistema para completar um processo.
b. Diagrama de Transição de Estados/Máquina de Estados: é uma representação do estado ou
situação em que um objeto pode se encontrar no decorrer da execução de processos de um
sistema. Com isso, o objeto pode passar de um estado inicial para um estado final através de uma
transição.
Conceitos:
 Estado: Condição ou situação durante a vida de um objeto na qual ele satisfaz algumas
condições, executa algumas atividades ou espera por eventos.[1]
 Transição: O relacionamento entre dois estados, indicando que o objeto que está no
primeiro estado irá passar para o segundo estado mediante a ocorrência de um
determinado evento e em certos casos uma condição.[1]
 Condição: causa necessária para que haja a transição de estado. Decorre da ocorrência
de um evento ou circunstância que propicia a transição de estado.
 Estado inicial: Estado por onde se começa a leitura de um diagrama de estado.
 Estado final: Estado que representa o fim de uma máquina.
 Barra de Sincronização: Semelhante a um Fork do Diagrama de atividade.
 Estado composto: Estado composto por outras máquinas de estado organizadas em
regiões que são executadas em paralelo.
 Sincronização: permite que os relógios de dois ou mais processos paralelos estejam
sincronizados em um determinado momento do processo.
 Ação: atividade do sistema que efetua a transição de estado.
c. Diagrama de Atividade: é essencialmente um gráfico de fluxo, mostrando o fluxo de controle de
uma atividade para outra e serão empregados para fazer a modelagem de aspectos dinâmicos do
sistema.
Enquanto os diagramas de interação dão ênfase ao fluxo de controle de um objeto para outro, os
diagramas de atividades dão ênfase ao fluxo de controle de uma atividade para outra; Uma
atividade é uma execução não atômica em andamento em uma máquina de estados e acabam
resultando em alguma ação, formada pelas computações atômicas executáveis que resultam em
uma mudança de estado do sistema ou o retorno de um valor.
Conceito:
 Atividades: Comportamento a ser realizado.
 Sub-atividade: Execução de uma sequência não atômica de atividades.
 Transição: Fluxo de uma atividade para outra.
 Ação: Transformação.
 Decisão: Dependendo de uma condição, mostra as diferentes transições.
  Raia: Diferenciação de unidades organizacionais.
 Bifurcação (Fork): Separa uma transição em várias transições executadas ao mesmo
tempo.
 Sincronização (Join): Concatenação de transições vindas do Fork.
 Object: O objeto da atividade.
 Envio de sinal: Transição para um meio externo, por exemplo, um hardware.
 Recepção de sinal: Recepção do envio.
 Região: Agrupamento de uma ou mais atividades.
 Exceção: Atividades que ocorrerem em decorrência de uma excepção.

d. Diagrama de Interação: Os diagramas de interação mostram como os objetos interagem uns com
os outros. Permitem assim modelar os aspectos dinâmicos de um sistema. Existem quatro tipos de
diagramas de interação:
 diagrama de sequência: é tipicamente usado para mostrar a interação de objetos em um
único caso de uso.
 diagrama de comunicação/colaboração: pode ser usado para mostrar como os objetos em
um sistema interagem sobre múltiplos casos de uso.
 diagrama de visão geral de interação: descreve em alto nível o fluxo principal das
interações
 diagramas de tempo: são especializados para sistemas de tempo real e usam um eixo de
tempo.

o Padrão singleton de desenvolvimento orientado a objetos

 Os Design Patterns são uma coleção de padrões de projeto de software que contém
soluções para problemas conhecidos e recorrentes no desenvolvimento de software
descrevendo uma solução comprovada para um problema de projeto recorrente.
 Padrão Singleton: O padrão Singleton permite criar objetos únicos para os quais há
apenas uma instância. Este padrão oferece um ponto de acesso global, assim como
uma variável global, porém sem as desvantagens das variáveis globais.
 Tem como definição garantir que uma classe tenha apenas uma instância de si mesma
e que forneça um ponto global de acesso a ela.
 Ou seja, uma classe gerencia a própria instância dela além de evitar que qualquer outra
classe crie uma instância dela. Para criar a instancia tem-se que passar pela classe
obrigatoriamente, nenhuma outra classe pode instanciar ela. O Padrão Singleton
também oferece um ponto global de acesso a sua instância. A própria classe sempre
vai oferecer a própria instância dela e caso não tenha ainda uma instância, então ela
mesma cria e retorna essa nova instância criada.


 Portanto O controle de como e quando os clientes acessam a instância pode ser obtido
por meio da operação getInstance da Singleton acima.
 Esse padrão permite o refinamento de operações e de representação, pois as várias
classes singleton obedecem à mesma interface, o que permite que um singleton seja
escolhido para trabalhar com determinada aplicação em tempo de execução.

 4.3 Coleções.

4.4 Tipos genéricos.

4.5 Threads.

 O processamento de hoje ainda é feito na maioria das vezes por um único processador da
máquina(um núcleo CPU CORE) ou mais núcleos ( 2 ou + CORE). Só que na maioria dos
sistemas, vários processos são executados no mesmo intervalo de tempo, dando a impressão de
simultaneidade de execução. Esta capacidade é chamada de multiprocessamento, e muito
estudada em sistemas operacionais.
 Um processo é basicamente um programa em execução. Eles são independentes dos outros.
 Devido ao quesito desempenho, uma característica importante é a escalabilidade em
aplicações multithread, pois a alocação de espaço de memória não deve se tornar um gargalo
para o aumento do número de tarefas concorrentes sendo executadas. (escalabilidade significa
aumento de desempenho à medida que se aumenta o número de linhas de execução (threads).)
 Threads:
o São subprocessos no Sistema Operacional. O thread pode ser vista como uma parte de
um processo, que permite compartilhar a sua área de dados com o programa ou outros
threads. Seu início de execução é muito mais rápido do que um processo, e o acesso a
sua área de dados funciona como um único programa.
o Vantagens:
 Torna-se menos custoso em termos de processamento criar um thread que um
processo;
 •São necessárias poucas variáveis para criação de um thread;
 •Podem compartilhar o mesmo espaço de processo;
 •Podem compartilhar os mesmos recursos de seus processos.
o Os estados de um Thread:
 Novo (New Thread)
 Executável (Runnable)
 Bloqueado (Not Runnable)
 Encerrado|(Dead)
 Thread em Java
o Cada Thread está associada com uma instancia da classe Thread
o A máquina virtual Java permite que uma aplicação tenha diversos fluxos sequencias de
execução rodando concorrentemente (SUN, 2009a). Para se utilizar esta
funcionalidade, a API Java disponibiliza a classe Thread e a interface Runnable.
o A Interface Runnable: define um único método –run–que deve conter o código de
execução da thread.
o A Classe Thread: Implementa o Runnable, logo seu método run nada faz. Uma
aplicação pode herdar de thread fornecendo a sua própria implementação do método
run.
o A prioridade de um thread corresponde a preferência que ela terá perante as demais
durante sua execução. Quanto maior a prioridade de um thread, maior será sua
preferência no uso da CPU. Threads de mesma prioridade costumam partilhar o tempo
de CPU igualmente.
o A prioridade é extremamente ligada ao algoritmo de escalonamento de CPU que o
sistema operacional utiliza. Para definir a prioridade de um thread, são usados números
de 1 a 10, sendo que o número 5 é usado para definir a prioridade como normal.
Quanto maior o valor da prioridade, maior é a sua prioridade. Entretanto, nem todos os
sistemas operacionais possuem as mesmas prioridades de um thread Java. Portanto,
para garantir que um thread com prioridade 10 tenha prioridade alta tanto em um
sistema operacional cuja prioridade máxima seja 10 quanto em outro que seja 100, a
JVM traduz a prioridade especificada no código para a do sistema operacional, logo
uma prioridade 10 em Java pode ser traduzida para uma prioridade 100 no SO, por
exemplo.
o Para definirmos a prioridade da thread, usamos os métodos:
  •voidsetPriority(intprioridade) –Define a prioridade de execução de uma
thread. Os valores de prioridade estão entre 1 e 10;
 •intgetPriority() –verifica a prioridade de execução de uma thread;
o Sincronização
 Durante a execução de threads, há casos em que elas trabalham
independentemente uma da outra, sem necessidade de qualquer comunicação
entre elas. Por outro lado, há casos em que elas comunicam-se de alguma
forma ou utilizam dados em comum. Este comportamento gera a necessidade
de denominar os threads em assíncronas e síncronas, dependendo da forma
de trabalho desempenhada.
 Threads que trabalham independentes no tempo, são assíncronas
 Enquanto aquelas que trocam informações em tempo de execução
são síncronas.
 As threads se diferem dos processos por poderem ter áreas de dados comuns.
Isto pode facilitar em muito a implementação de programas. Porém, pode
causar alguns erros quando a mesma base de dados é alterada por mais de
um thread, em momentos inesperados.
 O uso de memória compartilhada entre os threads obriga o programador a
sincronizar as ações de suas threads.
 Para isso, Java provê monitores ou locks. Imagine um lock como uma
permissão para que apenas um thread possa utilizar um recurso por vez.
 Cada objeto em Java possui um lock ele deve ser obtido através do
comando synchronized.
 Os métodos wait(), notify() e notifyAll() também são muito importantes na
sincronização, sendo responsáveis por provocar, respectivamente: uma
espera, a liberação de uma ou mais threads em espera

4.6 Escalonamento.
4.7 Primitivas de sincronização e deadlocks.
4.8 Garbage collector.

 Conhecido como coletor de lixo

 é um processo usado para a automação do gerenciamento de memória. Com ele é possível
recuperar uma área de memória inutilizada por um programa, o que pode evitar problemas de
vazamento de memória, resultando no esgotamento da memória livre para alocação.
 Os princípios básicos do coletor de lixo são:
o encontrar objetos de um programa que não serão mais acessados no futuro, e
o desalocar os recursos utilizados por tais objetos. Tornando a desalocação manual de
memória desnecessária,
o O coletor de lixo livra o programador de se preocupar com a liberação de recursos já
não utilizados, o que pode consumir uma parte significativa do desenvolvimento do
software. Também evita que o programador introduza erros no programa devido a má
utilização de ponteiros.
 Vantagens:
o livra o programador de lidar manualmente com o gerenciamento de memória.
o certas categorias e defeitos de software são eliminadas ou reduzidas.(ex: apontador
pendente, que ocorre quando um pedaço de memória é desalocado enquanto ainda há
ponteiros apontando para o objeto, e um desses ponteiros é usado.)
o é essencial para a segurança de memória e está geralmente associado à propriedade
de segurança de tipo.
o Em linguagens orientadas a objetos onde o tempo de carga do objeto é muito alta o
coletor pode conter um algoritmo para cache de objetos de forma a devolver objetos
que costumam ser utilizados com frequência sem precisar recriá-los.
 Desvantagens:
o Eles são processos que consomem recursos computacionais para decidir quais partes
da memória podem ser liberadas, enquanto no gerenciamento manual esse consumo é
mínimo.
o o momento em que o objeto é realmente desalocado não é determinístico, o que pode
acarretar na variação do tempo de execução de algoritmo em partes aleatórias, o que
impensável em sistemas como em tempo real, drivers de dispositivo e processamento
de transações.
 o uso de recursividade atrasa a desalocação automática da memória da pilha de
execução até que a última chamada seja completada, aumentando os requisitos de
memória do algoritmo.
 Processo de coleta de lixo é dividido em duas fases:
o A primeira é a separação entre objetos vivos e objetos mortos
o A segunda fase é liberação da memória ocupada pelos mortos.
o Como? Através da contagem de referencia: quando um objeto X referencia outro objeto
Y, o sistema incrementa um contador de referências em Y, e quando X deixa de
referenciar Y, o contador é decrementado. Quando o contador chega a zero, Y não está
mais vivo, e torna-se qualificado para a coleta de lixo. Dessa maneira, os contadores
dos objetos aos quais Y eventualmente se refere também serão decrementados.
 Java:
o Java oferece uma opção automática para o gerenciamento de memória.
o O gerenciamento automático de memória o livrará de qualquer tipo de controle manual
sobre objetos que devem ser liberados da memória. A única desvantagem desse
gerenciamento automático de memória é que o programador não saberá exatamente
quando ele será executado.
o O controlador de lixo não é controlado pelo programador e sim pela Máquina Virtual
Java (JVM) que decide quando executá-lo. Há a possibilidade do programador chamar
o coletor de lixo, porém mesmo assim não há nenhuma garantia de que o coletor de lixo
irá realmente ser executado naquele momento. Normalmente o coletor executa quando
percebe-se que a memória está ficando sem espaço.
o Infelizmente a especificação da linguagem Java não garante como é o funcionamento
do coletor de lixo, nem mesmo indica algum algoritmo que ele utiliza. É possível saber
quais objetos o coletor de lixo realmente age ou seja, o programador pode agir de forma
a ir colocando alguns objetos disponíveis para o coletor de lixo para posteriormente
desalojá-lo da memória liberando espaço para outros objetos.
o Em Java o programador precisa se preocupar com duas áreas de memória – a área
onde os objetos são armazenados (heap), e a área onde vivem as variáveis locais e as
chamadas de métodos (pilha).
 Variáveis locais:
 podem ser primitivas ou referências a objetos
 possuem um tipo e tamanho que determina o espaço de memoria
o Se o tamanho do heap é pequeno, a coleta vai ser rápida, mas a pilha vai encher mais
rapidamente, exigindo, portanto, coletas mais frequentes. Por outro lado, uma pilha de
tamanho maior vai demorar mais tempo a encher e assim, as coletas serão menos
frequentes, mas podem demorar mais tempo.
o GC deve ser seguro e compreensivo.
 Seguro significa que objetos vivos nunca devem ter seu espaço liberado
 Compreensivo, os objetos não mais referenciados não deveriam permanecer
sem ser coletados por mais que um pequeno número de ciclos de coleta(inicia
com a marcação dos objetos elegíveis e vai até suas exclusões definitivas)
o Exemplos: Objeto alocado que deixa de ser referenciado, ou seja, será liberado para
coleta de lixo.
 Consiste em atribuir null à variável de referência
 Outra maneira é fazer uma variável de referência a um objeto A, “apontar” para
outro objeto B

Integer i = new Integer(10);

i = null;
// variável i com Null deixa de apontar para objeto

public class TesteColetor {

public static void main(String[] args) {

StringBuffer sb1 = new StringBuffer("abcd");
StringBuffer sb2 = new StringBuffer("xwyz");
// Os StringBuffer estão sendo referenciados
// e não são elegíveis para coleta de lixo
System.out.println(sb1);
sb1 = sb2;
  (dangling references)/referencia pendentes Um dos problemas que ocorrem
quando o gerenciamento de memória é feito pelo programador. As falhas de
referências pendentes acontecem se o programador desaloca o espaço
ocupado por um objeto que ainda está sendo referenciado.
 vazamento de memória (space leaks): O vazamento ocorre quando um objeto
deixa de ser referenciado e sua memória não é liberada. Caso aconteça muito
vazamento, o aumento de consumo do espaço de armazenamento pode levar
ao esgotamento da memória.
o Comandos Garbage Collector
 A classe Runtime, com alguns métodos da classe System, permite que o
Coletor de Lixo seja chamado, que finalizadores pendentes sejam executados
ou que se consulte o estado atual da memória. É uma classe especial que tem
uma única instância para cada programa.
 método finalize() – finalizador – que é executado pelo Coletor de Lixo depois
que ele determina que um objeto não é mais alcançável, tornando-se assim
elegível à coleta de lixo.
 Após esta instância ter sido definida, pode-se invocar o Garbage Collector
utilizando o método gc(). Ao executar esse método, a coleta de lixo deveria
ser efetivada e o programa teria mais memória livre disponível.
 NET:
o Toda vez que você cria um novo objeto, o Common Language Runtime (CLR) aloca
memória para o objeto do heap gerenciado.
o Coletor de Lixo (GC) é automático.
o Cada processo tem seu próprio espaço de endereço virtual separado. Todos os
processos no mesmo computador compartilham a mesma memória física e o arquivo de
paginação, se houver um.
o Como desenvolvedor de aplicativos, você trabalha apenas com o espaço de endereço
virtual e nunca manipula a memória física diretamente. O coletor de lixo aloca e libera
memória virtual para você no heap gerenciado.
 JavaScript:
o A única limitação que pode ser encontrada é que não é possível acionar explicitamente
ou programaticamente o coletor de lixo em JavaScript.
Portanto, se houver casos em que seria conveniente programar manualmente quando
liberar memória, não há disposições em JavaScript para acionar tal evento.
o Adotar mesmas práticas de forma manual (mencionada no tópico Java )
 Python:
o O método de alocação e desalocação de memória do Python é automático. O usuário
não precisa pré-alocar ou desalocar memória de maneira semelhante ao uso da
alocação dinâmica de memória em linguagens como C ou C ++.
o Python usa duas estratégias para alocação de memória:
 Contagem de referência
 Coleta de lixo
o É possível inspecionar o limite de novos objetos através da biblioteca GC:

import gc

print("Garbage collection thresholds:", gc.get_threshold())

 Chamar o coletor de lixo manualmente durante a execução de um programa pode

ser uma boa ideia sobre como lidar com a memória que está sendo consumida por
ciclos de referência.

import gc

collected = gc.collect()

print("Garbage collector: collected", "%d objects." % collected)

Na plataforma .NET, o coletor de lixo (garbage collector) é um componente do Tempo de Execução de

Linguagem Comum (CLR – Common Language Runtime).
Na plataforma Java SE 8, o coletor de lixo (garbage collector) somente libera o espaço ocupado pelo
objeto A na memória quando não há mais referências para o objeto A no programa.
 4.9 Tratamento de exceções.

 O tratamento de exceção, na ciência da computação, é o mecanismo responsável pelo tratamento da

ocorrência de condições que alteram o fluxo normal da execução de programas de computadores.
Para condições consideradas parte do fluxo normal de execução, ver os conceitos de sinal (é uma
notificação assíncrona enviada a processos com o objetivo de notificar a ocorrência de um evento.) e
evento(programação orientada a eventos).
 Em geral, na ocorrência de uma exceção, o estado do programa é gravado em um local pré-definido e
a sua execução é direcionada para uma rotina de tratamento. Dependendo da situação, a rotina de
tratamento pode prosseguir a execução a partir do ponto que originou a exceção, utilizando a
informação gravada para restaurar o estado.
 Para o desenvolvedor de uma rotina, lançar uma exceção é um modo útil de assinalar que a rotina não
deve continuar a execução quando, por exemplo, os argumentos de entrada não são válidos (um
denominador igual a zero em uma divisão, por exemplo) ou quando um recurso no qual o programa
depende não está disponível (um arquivo não encontrado ou um erro em um disco, por exemplo).
 Os níveis de segurança relacionados ao tratamento de exceção podem ser colocados da seguinte
forma:
o transparência à falha: há garantia que as operações ocorrerão com sucesso e satisfarão
todos os requerimentos, mesmo na presença de situações excepcionais. Este é o melhor
nível de segurança.
o transacional : as operações podem falhar, mas quando isso ocorre as operações não
causam efeitos colaterais.[1]
o segurança básica: execuções parciais de operações que falham podem causar efeitos
colaterais, mas os invariantes de estado são preservados (isto é, qualquer dado gravado
conterá valores válidos).
o segurança mínima: execuções parciais de operações que falham podem gravar dados
inválidos mas não levarão à falha completa (crash) do programa.
o sem segurança: não há qualquer garantia. Este é o pior nível de segurança para com
exceções.
o Normalmente um nível básico de segurança é requerido. A transparência à falhas é difícil de
implementar e normalmente não é possível de atingir em bibliotecas onde o conhecimento
completo da aplicação não está disponível.

 Muitas linguagens de programação, como Java, Python e todas linguagens do framework .NET
contém suporte nativo para tratamento de exceção. Nestas linguagens, no advento de uma exceção
(mais precisamente, uma exceção tratada pela linguagem), a pilha de execução é varrida até que uma
rotina de tratamento de exceção seja encontrada.
 No estilo mais popular, uma exceção é iniciada por uma declaração especial (throw ou raise) com
um objeto representando a exceção (como em Java). O escopo de uma rotina de tratamento de
exceção é iniciada com uma cláusula de marcação (try ou a palavra reservada da linguagem para
início de bloco, como begin), e termina com o início do bloco de tratamento (catch, except ou
rescue). Várias cláusulas indicando blocos de tratamento para diferentes tipos de exceções podem
ser colocados na sequência.
 Java
o Todas as exceções em Java herdam direta ou indiretamente da classe
Throwable.
o Há Dois tipos de exceções em Java:
 Checked Exceptions: Você é obrigado a tratá-las! São
subclasses da Exception (java.lang.Exception), geralmente são
condições inválidas de entrada, falhas na rede, arquivos faltando.
 Unchecked Exceptions(java.lang.Error): não é obrigatório o
tratamento destas exceções, você pode ou não trata-las,
geralmente representam erros no programa ou na JVM.
o Um simples declaração throws Exception ou catch
(Exception e) é sempre suficiente para satisfazer a verificação.
Exemplo 1:

try {
 line = console.readLine();
if (line.length() == 0) {
throw new EmptyLineException("A linha lida da console está vazia!");
}
console.printLine("Alô %s!" % line);
} catch (EmptyLineException e) {
console.printLine("Alô!");
} catch (Exception e) {
console.printLine("Erro: " + e.message());
} else {
console.printLine("O programa executou com sucesso.");
} finally {
bloco Finally, que independente de dar erro ou não, este será executado.
console.printLine("O programa termina neste momento.");

 As cláusulas throw e throws podem ser entendidas como ações que

propagam exceções, ou seja, em alguns momentos existem exceções que
não podem ser tratadas no mesmo método que gerou a exceção. Nesses
casos, é necessário propagar a exceção para um nível acima na pilha.

public static int calculaQuociente(int numerador, int denominador) throws

ArithmeticException{
return numerador / denominador;
}

 Python

import sys

try:
f = open('myfile.txt')
s = f.readline()
i = int(s.strip())
except OSError as err:
print("OS error: {0}".format(err))
except ValueError:
print("Could not convert data to an integer.")
except BaseException as err:
print(f"Unexpected {err=}, {type(err)=}")
raise
o
 Javascript

try {
// código que inclui comandos/invocações de métodos
// que podem gerar uma situação de exceção.
} catch (error) {
// bloco de tratamento do erro
} finally {
// bloco de código que sempre será executado após
// o bloco try, independentemente de sua conclusão
// ter ocorrido normalmente ou ter sido interrompida
}
o
 .NET

try
{

Console.WriteLine("Informe um valor 1!");

int num1 = Convert.ToInt32(Console.ReadLine());
Console.WriteLine("Informe um valor 2!");
int num2 = Convert.ToInt32(Console.ReadLine());
int result = num1 / num2;
Console.WriteLine("{0} / {1} = {2}", num1, num2, result);
}
 Catch (Exception exc)

{
Console.WriteLine("Não é possivel a divisão por 0");
}
finally
{
Console.WriteLine("Executado mesmo na ocorrência de erro.");
}
Console.ReadKey();

O compilador Java não permite que sejam definidos tratadores (cláusulas catch) para as exceções de tipo
RuntimeException e Error. (ERRADO) pois a classe error lança exceções referentes a run-time do Java,
portanto NÃO LANÇAM EXCEÇÕES PELOS PROGRAMAS DOS USUÁRIOS e por isso NUNCA DEVEM
SER TRATADAS, já as exceções da RunTime Exception podem ou não ser tratadas(unchecked).
Na hierarquia de exceções em Java, é correto afirmar que a classe RuntimeException é uma subclasse
da classe Exception. (CERTO)

( ) NullPointerException é a exceção lançada ao tentar dividir um número por zero. (ERRADO)

( ) É possível ter vários blocos catch para a mesma cláusula try para tratar diferentes exceções. (CERTO)
( ) É possível declarar mais de uma exceção na cláusula throws. (CERTO)
( ) Se o desenvolvedor usa o bloco try-catch para tratar uma ou mais exceções em um método, ele não
pode mais usar a cláusula throws na assinatura do mesmo método para lançar exceções.(ERRADO) "É
possível declarar mais de uma exceção na cláusula throws." SIM

Na linguagem Java, o tratamento de exceções ajuda o usuário a entender tanto o tipo de dado esperado
quanto um erro informado pelo programa. Sabendo disso, assinale a alternativa que apresenta
corretamente a cláusula que especifica as exceções que um método pode apresentar se ocorrerem
problemas, devendo essa cláusula aparecer após a lista de parâmetros e antes do corpo do método.
THROWS (Ex: public void M1() throws IOException {

FileReader f = new FileReader("notExist.txt");

A linguagem de programação JAVA utiliza exceções para lidar com erros e outros eventos
excepcionais. Nessa linguagem, uma nova exceção pode ser lançada por meio da seguinte
palavra reservada: THROWS
 No método conectar podem ser lançadas duas exceções que o Analista de Informática deseja que
sejam tratadas não no interior do método, mas sim por quem o chamar. Para que isso seja permitido,
deve-se inserir o comando throws ClassNotFoundException, SQLException na linha de declaração do
método.

4.10 Anotações.

Padrão GRASP:

 Os padrões GRASP englobam uma série de princípios baseados em conceitos de Orientação a

Objetos. Partindo de análises que procuram definir quais as obrigações dos diferentes tipos de objetos em
uma aplicação, estes patterns disponibilizam uma série de recomendações que procuram favorecer a
obtenção de sistemas melhor estruturados.
 Ao todo são nove os padrões GRASP:
· Criador (Creator);
· Especialista na Informação (Information Expert);
· Baixo Acoplamento (Low Coupling);
· Alta Coesão (High Cohesion);
· Controlador (Controller);
· Polimorfismo (Polymorphism);
· Fabricação/Invenção Pura (Pure Fabrication);
· Indireção (Indirection);
· Variações Protegidas (Protected Variations).
 O acoplamento significa o quanto uma classe depende da outra para funcionar.
 Quanto mais baixo melhor, isto é, quanto menos "amarradas" as classes, menor é o acoplamento.
 Como minimizar dependências e maximizar o reuso?
· O acoplamento é uma medida de quão fortemente uma classe está conectada, possui
conhecimento ou depende de outra classe
 Com fraco acoplamento, uma classe não é dependente de muitas outras classes
 Com uma classe possuindo forte acoplamento, temos os seguintes problemas:
 Mudanças a uma classe relacionada força mudanças locais à classe
 A classe é mais difícil de entender isoladamente
 A classe é mais difícil de ser reusada, já que depende da presença de outras
classes
· Solução
 Atribuir responsabilidades de forma a minimizar o acoplamento

 Clean Code (Código Limpo)

o Clean Code é uma filosofia de desenvolvimento cuja o principal objetivo é aplicar técnicas
simples que visam facilitar a escrita e leitura de um código, tornando-o de fácil compreensão
e revelando a sua real intenção.
o A produtividade de um programador está diretamente ligada a qualidade do código em que
ele trabalha. (Passamos dez vezes mais tempo lendo o código do que escrevendo-o)
o Práticas de código limpo:
 Nomes significativos:
 Use nomes que revelem seu propósito nas Variáveis, funções, métodos,
parâmetros, classes, objetos, arquivos fonte, diretórios, projetos, branchs
do controle de versão.
 Se um nome requer um comentário, então ele não revela seu proposito
 Não abrevie e evite siglas, exceto se todos conhecerem. (Exemplo: API,
pt-BR)
 Exemplo:
 o $ymd = date('Y-m-d'); // Ruim
o $currentDate = date('Y-m-d'); // Bom
 Evite números mágicos
 Números mágicos são aqueles números aleatórios que de vez em quando
você acaba encontrando no código, eles são “mágicos” porquê se
assemelham com o truque de um mágico, sendo necessário uma
explicação para que sejam entendidos.
 Ex:


 Condicionais
 Usar booleanos de forma implícita para poluir menos.

//Ruim
if (in_array(self::GRUPO_ADMINISTRADOR, $gruposAcesso)) {
return true;
}
//Bom
return in_array(self::GRUPO_ADMINISTRADOR, $gruposAcesso));
 Evitar condicionais negativos

// Ruim
function shouldNotProccess() { //Não devo processar
// ...
}
//Bom
function shouldProccess() { // Devo processar
// ...
}
 Encapsule condicionais para melhor reaproveitamento e facilidade de
manutenção do código se precisar mudar essa condição

//Ruim

if ($article->state === 'published') {

}

//Bom

if ($article->isPublished()) {

// ...

 Comentários:
 Não faça comentários irrelevantes, eles só poluem o código e não devem
explicar o código. Ele deve ser comparado como uma história. Sugestão:
function NomeNaoPodeSerVazioNemNulo($nome)
 Não use comentários para versionar o código.Use versionamento GIT
 Funções
 Dê preferencia para funções nativas: Além de limpar o código
economizando algumas linhas, as funções nativas são executas mais
rápidas. Ex: Em vez de usar um loop foreach, use apenas uma função
array_map.
 Função pequenas: Você tem uma função que é composta por várias
linhas de códigos? Então você tem um problema! Funções com várias
linhas são difíceis de serem entendidas e praticamente impossíveis de
serem testadas. Outro ponto negativo, é que sua função provavelmente
tem mais de uma responsabilidade, o que quebra o conceito de Single
 responsibility principle do SOLID. Uma função contém apenas uma
tarefa !
 Evite o uso de flags como parâmetro: Porquê? porque o uso de flags
indicam que essa função faz mais de uma coisa. Lembre-se, funções
devem fazer apenas uma coisa.
 SOLID
o SOLID são cinco princípios da programação orientada a objetos e design de código que
facilitam no desenvolvimento de softwares, tornando-os fáceis de manter e estender. Esses
princípios podem ser aplicados a qualquer linguagem de POO.
o Esses princípios ajudam o programador a escrever códigos mais limpos, separando
responsabilidades, diminuindo acoplamentos, facilitando na refatoração e estimulando o
reaproveitamento do código.
o Os 5 princípios da POO:
 S — Single Responsiblity Principle (Princípio da responsabilidade única)
 Uma classe deve ter um, e somente um, motivo para mudar: uma
classe deve ser especializada em um único assunto e possuir apenas uma
responsabilidade dentro do software, ou seja, a classe deve ter uma única
tarefa ou ação para executar.
 não se limita somente a classes, ele também pode ser aplicado em
métodos e funções, ou seja, tudo que é responsável por executar uma
ação, deve ser responsável por apenas aquilo que se propõe a fazer.
 Uma classe com mais responsabilidade: Conhecida como “God Class”
(Classe Deus) - será difícil modificar uma dessas responsabilidades sem
comprometer as outras. Toda alteração acaba sendo introduzida com um
certo nível de incerteza.
 As violações do SRP são:
o Falta de coesão — uma classe não deve assumir
responsabilidades que não são suas;
o Alto acoplamento — Mais responsabilidades geram um maior
nível de dependências, deixando o sistema engessado e frágil
para alterações;
o Dificuldades na implementação de testes automatizados — É
difícil de “mockar” esse tipo de classe;
o Dificuldades para reaproveitar o código;
 O — Open-Closed Principle (Princípio Aberto-Fechado)
 Objetos ou entidades devem estar abertos para extensão, mas
fechados para modificação, ou seja, quando novos comportamentos e
recursos precisam ser adicionados no software, devemos estender e não
alterar o código fonte original.
 Solução: Separe o comportamento extensível por trás de uma interface e
inverta as dependências: concentrar nos aspectos essências do contexto,
abstraindo-os para uma interface. Se as abstrações são bem definidas,
logo o software estará aberto para extensão.
 L — Liskov Substitution Principle (Princípio da substituição de Liskov)
 Uma classe derivada deve ser substituível por sua classe base.
 se S é um subtipo de T, então os objetos do tipo T, em um programa,
podem ser substituídos pelos objetos de tipo S sem que seja necessário
alterar as propriedades deste programa.
 em alguns casos, você precisara usar a injeção de dependência
 Seguir o LSP nos permite usar o polimorfismo com mais confiança.
Podemos chamar nossas classes derivadas referindo-se à sua classe
base sem preocupações com resultados inesperados.
 Exemplos de violação do LSP:
o Sobrescrever/implementar um método que não faz nada;
o Lançar uma exceção inesperada;
o Retornar valores de tipos diferentes da classe base;
 I — Interface Segregation Principle (Princípio da Segregação da Interface)
 Uma classe não deve ser forçada a implementar interfaces e métodos
que não irão utilizar: Esse princípio basicamente diz que é melhor criar
 interfaces mais específicas ao invés de termos uma única interface
genérica.

<?php

interface Aves
{
public function setLocalizacao($longitude, $latitude);
public function renderizar();
}

interface AvesQueVoam extends Aves

{
public function setAltitude($altitude);
}

class Papagaio implements AvesQueVoam

{
public function setLocalizacao($longitude, $latitude)
{
//Faz alguma coisa
}

public function setAltitude($altitude)

{
//Faz alguma coisa
}

public function renderizar()

{
//Faz alguma coisa
}
}

class Pinguim implements Aves

{
public function setLocalizacao($longitude, $latitude)
{
//Faz alguma coisa
}

public function renderizar()

{
//Faz alguma coisa
}
}

 D — Dependency Inversion Principle (Princípio da inversão da dependência)

 Dependa de abstrações e não de implementações
 Módulos de alto nível não devem depender de módulos de baixo nível.
Ambos devem depender da abstração.
 Abstrações não devem depender de detalhes. Detalhes devem depender
de abstrações.
 Importante: Inversão de Dependência não é igual a Injeção de
Dependência, fique ciente disso! A Inversão de Dependência é um
princípio (Conceito) e a Injeção de Dependência é um padrão de projeto
(Design Pattern)

interface DBConnectionInterface
{
public function connect();
}

class MySQLConnection implements DBConnectionInterface

{
public function connect()
{
// ...
}
}
 class OracleConnection implements DBConnectionInterface
{
public function connect()
{
// ...
}
}
class PasswordReminder
{
private $dbConnection;

public function __construct(DBConnectionInterface $dbConnection) {

$this->dbConnection = $dbConnection;
}

// Faz alguma coisa

}

 Documentação de referência da API
 A documentação de referência para uma API é parte intrínseca de qualquer API, e sem ela a API é
inutilizável. Cada aspecto da API, não importa o quão trivial, deve ser declarado explicitamente. Quando uma API
documenta uma biblioteca de funções em uma linguagem procedural, ela deve incluir:
• uma descrição de todas as estruturas de dados de que depende
• uma descrição de todas as assinaturas de funções, incluindo:
 nomes de funções
 nomes de parâmetros de função (quando aplicável) e tipos
 tipo de retorno para as funções
 para cada parâmetro, se o parâmetro for possivelmente modificável dentro da função
 uma descrição do tratamento de qualquer condição de erro
 pré e pós-condições ou invariantes
 de forma mais geral, como o estado muda após a execução da função
 possíveis efeitos colaterais
 qualquer restrição de acessibilidade ou visibilidade.”
 TIPOS DE APIs:
• API Privada:é usada apenas internamente (na própria empresa) - oferece as empresas um maior controle.
• API de Parceiros: é compartilhada com parceiros de negócios específicos.
• API Pública: é disponibilizada para todos, terceiros podem desenvolver aplicações que interajam com a API.

Uma API restringe a interface entre duas aplicações, nesse sentido, não é possível que uma
API especifique uma interface entre uma aplicação e o sistema operacional, já que estão em
camadas diferentes de programação. (ERRADO) É possível SIM que uma API especifique
uma interface entre uma aplicação e o sistema operacional (inclusive essa foi a origem da
API, foram inicialmente desenvolvidas para o sistema operacional)

Para utilizar uma API que trabalhe com entrada/saída de arquivos, é necessário entender as
operações do sistema de arquivo ao se utilizar a função copiar um arquivo de um dispositivo
para outro. (ERRADO) Não é necessário

Um computador executa, como instrução, uma sequência de baites, que consiste de

comandos, como, por exemplo, um algoritmo, a serem executados pelo processador.
(ERRADO) executa sequencia de bit

Um algoritmo computacional escrito em linguagem de programação pode ser completamente

executado sem gerar nenhuma saída. (ERRADO)

Com a finalidade de minimizar a complexidade dos programas, a programação estruturada

permite o uso de um número ilimitado de estruturas de controle dentro de cada módulo.
(ERRADO)
Uma característica marcante da programação estruturada é o uso constante de comandos de
desvio, como, por exemplo, o GOTO. (ERRADO) GOTO não é aconselhável

4.11 Técnicas de profiling.

Profiling ("perfil de programa", "perfil de software") é uma forma de que mede, por exemplo, o espaço (memória) ou
tempo , o ou a frequência e duração das chamadas de função. Mais comumente, as informações de perfil servem
para auxiliar na e, mais especificamente,
Profiling é o processo de medir um aplicativo ou sistema executando uma ferramenta de análise chamada profiler. As
ferramentas de criação de perfil podem se concentrar em muitos aspectos: tempos de chamada de funções e
contagem, uso de memória, carga de CPU e uso de recursos.

Profiling em Python:

 Pandas Profiling é uma biblioteca open source, disponível no Github, baseada nos principais pacotes citados
anteriormente, que permite a elaboração de análises exploratórias com códigos simples.

# importa a função da biblioteca

from pandas_profiling import ProfileReport
#lendo o dataset no formato de um dataframe através da função read do pandas
dataset = pd.read_csv('winequality-red.csv', sep=';') #realiza a leitura do banco de dados
# executa a função que gera o relatório
profile = ProfileReport(dataset, title="Wine Quality")
# visualização do relatório
profile
 Nesta postagem do blog, apresentaremos as ferramentas, dicas e truques para verificar o desempenho do
código e como ele pode se tornar eficiente com pequenos ajustes.
 Profiling
 A criação de perfil ajuda a encontrar gargalos no código, de forma a receber o grande ganho de desempenho
prático. Todos nós acreditamos naturalmente em executar o código mais rápido com redução no uso de
recursos e praticamente queremos que nosso código seja 'rápido o suficiente' e 'enxuto o suficiente' para
atender aos nossos requisitos. Por razões mencionadas, vem o perfil, que nos ajuda a tomar as decisões
mais pragmáticas com o mínimo esforço geral.
 Ferramentas para criação de perfil
o cProfile (para identificar qual função leva tempo máximo em seu código):
o line_profiler (tempo gasto para cada linha de código em uma função). cProfile atua como um guia
para identificar quais funções são caras em termos de tempo de execução, enquanto o line_profiler
atua no topo de cada função, para identificar qual linha leva o máximo de tempo para execução.
line_profiler ajuda a encontrar o uso da CPU.
o py-spy (manter o controle de processos de longa execução). em vez de exigir qualquer alteração
de código, ele faz uma introspecção em um processo Python já em execução. Essa ferramenta
pode ser muito útil em um ambiente de produção com processos de longa execução ou requisitos
de instalação complicados.Uma vez que funciona em um processo Python em execução existente,
precisamos mencionar o pid (id do processo) do processo que pretendemos espionar.
o memory_profiler ( rastreando o uso de RAM ao longo do tempo). encontra a quantidade de
memória (RAM) sendo usada linha a linha. memory_profiler ajuda a responder duas perguntas
 Uma função pode ser reescrita com eficiência de forma que ocupe menos RAM?
 Podemos usar mais RAM e economizar o ciclo da CPU com cache?
o pstats
o Dis módulo para examinar o bytecode CPython. ajuda a entender a função lenta do código,
enquanto o estamos compilando.

4.12 Linguagens de desenvolvimento de interfaces ricas (HTML 5, CSS 3).

 xHTML => as camadas de conteúdo.

 CSS => apresentação visual do conteúdo.
 JavaScript => comportamento dos elementos.

Modelo de Objeto de Documento (DOM)

 é uma interface de programação API para documentos HTML, XML e SVG . Ele fornece uma
representação estruturada do documento como uma árvore.
 O DOM define métodos que permitem acesso à árvore, para que eles possam alterar a estrutura,
estilo e conteúdo do documento.
 O DOM fornece uma representação do documento como um grupo estruturado de nós e objetos,
possuindo várias propriedades e métodos. Os nós também podem ter manipuladores de eventos
que lhe são inerentes, e uma vez que um evento é acionado, os manipuladores de eventos são
executados.
 Embora o DOM seja frequentemente acessado usando JavaScript, não é uma parte da
linguagem JavaScript. Ele também pode ser acessado por outras linguagens.
 Interface DOCUMENT
o A interface Document serve como um ponto de entrada para o conteúdo da Página ( a
árvore DOM, incluindo elementos como <body> e <table>) e provê funcionalidades
globais ao documento
 o Propriedades: São atributos do documento. A interface Document também herda das
interfaces Node e EventTarget.
o Métodos: São funções do documento. A interface Document também herda das
interfaces Node e EventTarget.
 getElementsByClassName(): Retorna um vetor de objetos com todos os
elementos filhos que possuem o nome da classe dada.

Na linguagem JavaScript, ao invocar o método getElementsByClassName, do objeto document, será

retornado: Um array (CERTO)
JavaScript é uma linguagem que sofre muito com compatibilidade entre navegadores. A jQuery sofre
com o mesmo problema. Animações, manipulação de DOM e outra tarefas corriqueiras são mais
complexas e menos produtivas ao usar o jQuery. (ERRADO) MENOS
 4.13 JavaScript.

 JavaScript é uma linguagem de programação que permite a você implementar itens complexos

em páginas web de forma dinâmica (Uma página web sem atualizações dinâmicas é
chamada de estática — ela só mostra o mesmo conteúdo o tempo todo.)
 É a terceira camada do bolo das tecnologias padrões da web, duas das quais (HTML e CSS):
o HTML é a linguagem de marcação que nós usamos para estruturar e dar significado
para o nosso conteúdo web. Por exemplo, definindo parágrafos, cabeçalhos, tabelas de
conteúdo, ou inserindo imagens e vídeos na página.
o CSS é uma linguagem de regras de estilo que nós usamos para aplicar estilo ao nosso
conteúdo HTML. Por exemplo, definindo cores de fundo e fontes, e posicionando nosso
conteúdo em múltiplas colunas.
o JavaScript é uma linguagem de programação que permite a você criar conteúdo que se
atualiza dinamicamente, controlar múltimídias, imagens animadas, e tudo o mais que há
de intessante. Ok, não tudo, mas é maravilhoso o que você pode efetuar com algumas
linhas de código JavaScript.
 Javascript foi construída sobre capô da APIs (Application Programming Interfaces - Interface de
Programação de Aplicativos). APIs são conjuntos prontos de blocos de construção de código que
permitem que um desenvolvedor implemente programas que seriam difíceis ou impossíveis de
implementar. Elas geralmente se dividem em duas categorias.
o APIs de navegadores já vem implementadas no navegador, e são capazes de expor
dados do ambiente do computador, ou fazer coisas complexas e úteis. Por exemplo:
 A API DOM (Document Object Model) permite a você manipular HTML e
CSS, criando, removendo e mudando HTML, aplicando dinamicamente novos
estilos para a sua página, etc. Toda vez que você vê uma janela pop-up
aparecer em uma página, ou vê algum novo conteúdo sendo exibido (como
nós vimos acima na nossa simples demonstração), isso é o DOM em ação.
 A API de Geolocalização recupera informações geográficas. É assim que o
Google Maps consegue encontrar sua localização e colocar em um mapa.
 As APIs Canvas e WebGL permite a você criar gráficos 2D e 3D animados.
Há pessoas fazendo algumas coisas fantásticas usando essas tecnologias
web — veja Chrome Experiments e webglsamples.
 APIs de áudio e vídeo como HTMLMediaElement (en-US) e WebRTC
permitem a você fazer coisas realmente interessantes com multimídia, tanto
tocar música e vídeo em uma página da web, como capturar vídeos com a sua
câmera e exibir no computador de outra pessoa.
o APIs de terceiros não estão implementados no navegador automaticamente, e você
geralmente tem que pegar seu código e informações em algum lugar da Web. Por
exemplo:
 A API do Twitter permite a você fazer coisas como exibir seus últimos tweets
no seu website.
 A API do Google Maps permite a você inserir mapas customizados no seu
site e outras diversas funcionalidades.
 Um uso muito comum do JavaScript é modificar dinamicamente HTML e CSS para atualizar uma
interface do usuário, por meio da API do Document Object Model (conforme mencionado acima).
Observe que o código em seus documentos web geralmente é carregado e executado na ordem
em que aparece na página. Se o JavaScript carregar e tentar executar antes do carregamento
do HTML e CSS afetado, poderão ocorrer erros.
 Cada Guia do navegador é um espaço de trabalho/ambiente de execução por medida de
segurança. Uma guia não pode afetar o código da outra guia ou outro website. Nota: Há muitas
maneiras de trocar código e conteúdo entre diferentes websites/guias de uma forma segura, mas
são técnicas avançadas que não serão estudadas nesse curso.
 Ordem de execução do javascript: Quando o navegador encontra um bloco de código JavaScript,
ele geralmente executa na ordem, de cima para baixo no código.
 Código interpretado: JavaScript é uma linguagem interpretada (e não compilado)— o código é
executado de cima para baixo e o resultado da execução do código é imediatamente retornado.
Você não tem que transformar o código em algo diferente antes do navegador executa-lo. O
navegador recebe o código JavaScript em sua forma de texto original e executa o script a partir
dele através de uma técnica chamada compilação just-in-time para melhorar o desempenho; o
 código-fonte JavaScript é compilado em um formato binário mais rápido enquanto o script está
sendo usado, para que possa ser executado o mais rápido possível. No entanto, o JavaScript
ainda é considerado uma linguagem interpretada, pois a compilação é manipulada em tempo de
execução, e não antes.
 o JavaScript é carregado e acionado dentro do cabeçalho do documento, antes do corpo da
página ser completamente carregado.
 Lado do servidor x Lado do cliente: Javascript do lado do cliente (cliente-side) Códigos do
lado do cliente são executados no computador do usuário — quando uma página web é
visualizada, o código do lado do cliente é baixado, executado e exibido pelo navegador. Códigos
do lado do servidor (server-side), por outro lado, são executados no servidor e o resultado da
execução é baixado e exibido no navegador. Ex: PHP, Ruby e ASP.NET. Javascript pode ser
usada no servidor através do ambiente Node.js
 Para adicionar Javascript na página:
o JavaScript só precisa de um elemento <script> no HTML:
 Javascript interno: Inclusão de um bloco de código Javascript entre o
elemento <script></script>
 Javascript externo: Chamada de um arquivo.js (situado na mesma
pasta do arquivo HTML) entre o elemento <script src="script.js"
defer></script> : atributo defer, que informa ao browser para continuar
renderizando o conteúdo HTML uma vez que a tag <script> foi atingida.
Nota: No caso externo, nós não precisamos utilizar o
evento DOMContentLoaded porque o atributo defer resolve o nosso
problema. Nós não utilizamos defer como solução para os exemplos
internos pois defer funciona apenas com scripts externos.
o DICA: Uma solução à moda antiga para esse problema era colocar o elemento script
bem no final do body da página (antes da tag </body>). Com isso, os scripts iriam
carregar logo após todo o conteúdo HTML. Isto causa bloqueio do
carregamento/renderização do script até que todo o conteúdo HTML fosse analisado.
Em sites de maior escala, com muitos scripts, essa solução causaria um grande
problema de performance e deixaria o site lento. Solução: uso do ASYNC e DEFER
que permitem baixar o script sem bloquear a renderização da página e irão executar
imediatamente após o script terminar de ser disponibilizado. 
o Resumindo:
 async e defer instruem o browser a baixar os scripts numa thread (processo)
à parte, enquanto o resto da página (o DOM, etc.) está sendo baixado e
disponibilizado de forma não bloqueante.
 Se os seus scripts precisam rodar imediatamente, sem que dependam de
outros para serem executados, use async.
 Se seus scripts dependem de outros scripts ou do DOM completamente
disponível em tela, carregue-os usando defer e coloque os elementos <script>
na ordem exata que deseja que sejam carregados.
o Eventos:
 Eventos são ações que acontecem no navegador, como um botão sendo
clicado, ou uma página carregada, ou um vídeo tocando; ações as quais
podemos responder executando blocos de código. Os construtores que:
 monitoram os acontecimentos de eventos ( event listeners)
addEventListener(), e
 blocos de código executados em resposta ao acontecimento do evento (
event handlers.)
 Variáveis
o Ao se definir uma variável sem "let", "var" ou "const", ele se tornará uma variável de
escopo global.
o Ao se criar uma variável de escopo de função e com o mesmo nome de uma variável de
escopo global, acontecerá um evento chamado "Shadowing" que esconderá a variável
maior (global) e usará a de escopo menor (local)

Métodos Javascript
 Em um navegador Internet com JavaScript habilitado, esse código apresentará o resultado a seguir:

CERTO pois porque o campo é do tipo text e sua operação é junção de caracteres. Mas a lógica está
correta.

Biblioteca Math
Math.ceil() - arredonda para cima;
Math.exp() - retorna x elevado a e onde x é o argumento e "e" é o número de Euler;
Math.pow() - recebe dois argumentos Math.pow(x, y) e retorna o valor de x elevado a y;
Math.round() - retorna o inteiro mais próximo, arredonda para baixo ou para cima;
Math.sqrt() - retorna a raiz quadrada de um número

O Node.js é capaz de gerar conteúdos dinâmicos rodando JavaScript no servidor, porém não tem a
capacidade de acessar banco de dados. (ERRADO) tem capacidade de acessar BD
O protocolo JSON é derivado da linguagem de programação Java e sua utilização é restrita a sistemas
desenvolvidos em Java ou JavaScript.(ERRADO) O protocolo JSON é derivado da linguagem de
programação Java e sua utilização é restrita a sistemas desenvolvidos em Java ou JavaScrip
JSON NÃO é protocolo. JSON é uma linguagem independente que usa sintaxe de JavaScript, mas seu
formato é somente texto. E esse pode ser usado por qualquer linguagem de programação. Qual a
vantagem do JSON sobre o XML? Bem, ele é um formato muito mais leve e muito mais fácil de
ler/entender.
NPM - Node Package Manager é um gerenciador de pacotes global para JavaScript.
Quanto a sua orientação e arquitetura, o Node.js é uma linguagem que é orientada a
eventos e possui um modelo de E/S não bloqueante.
m JavaScript, o operador new cria e inicializa um novo objeto.
Qual operador NÃO representa a criação de um objeto de tipo nativo JavaScript? var l = new
ArrayList();

4.14 Python (versão 3.7 ou superior).

 Bloco de Instruções Código
o Delimitado por dois pontos (:) e NÃO por chaves { }
 Tipos de Dados:
• Listas
 Coleção ordenada.
 Número ilimitado de posições
 Cada valor na lista é identificado por um índice. O valores que formam uma
lista são chamados elementos ou itens
 Exemplo: “integer_list = [1, 2, 3] “
• Tuplas
 Coleção de dados, assim como as listas.
 São imutáveis, diferente das listas.Similar a constante
 Sem limite de níveis, isto é, número de itens.
 Exemplo: “my_tuple = (1, 2)”
• Dicionário
 Associa valores com chaves.{ }
 Permite recuperação de valores correspondentes a uma chave rapidamente.
 Exemplo: “empty_dict = {}”
 Operadores:
• + Soma
• - Subtração
• * Multiplicação
• / Divisão
• ** Potência
• // Divisão inteira
• % Resto da Divisão (ATENCAO: somente INTEIRO e não REAL)
• = Atribui valores a uma variável
• == Fazer comparação entre valores (igual)
• != Diferente
• Deve guarda a ordem de precedência:
 1º ( ) Parênteses
 2º ** Exponenciação
 3º * / Multiplicação e divisão, que possuem a mesma precedência (esq. Para dir)
 4º + - Adição e subtração, que possuem a mesma precedência
• Estruturas logicas em Python: and (e), or (ou), not (não), is (é)

x=7*3**2%4
print(x)
# resultado 3 • % Resto da Divisão (ATENCAO: somente INTEIRO e não REAL)

a,b=0,1
while a <= 14:
if (a%2)==1:
print('Saida:',a)
a,b=b,a+b # ATENCAO: Em atribuições dupla de variáveis=> Considerar o estado antigo

Abreviação casas decimais – Python

 Em casos de operações de várias casas decimais, pyhon sempre retorna apenas 1
casa decimal com zero.
 print(4.000000/(2.000000+2.00000)) # 1.0
 print(4/(2.000000+2.00000)) # 1.0
 print(4/(2+2.0)) # 1.0

 Função Mediana: A função median da biblioteca numpy possui o argumento axis como
opcional. Quando utilizado, ele pode ter os valores de 0 ou 1 (fora isso dá erro de sintaxe). No caso da
questão:
• axis=0, são retornadas as medianas de cada coluna: [2. 2.]
• axis=1, são retornadas as medianas de cada linha: [1.5 2. 3. ]
• sem o axis, é retornada a mediana do conjunto de todos os dados: 2.0

# retorna as medianas dos valores encontrados na primeira coluna

import numpy
y = numpy.array([[1, 2], [2, 2], [3, 3]])
numpy.median(y, axis=0)

 Função Desvio Padrão: A função std() (Standard Deviasion) da biblioteca numpy possui os
parâmetros:

• ➥ arr - array de entrada para calcular o desvio padrão axisEixo ao longo do qual o desvio padrão é
computado.
• ➥ axis=0 - significa desvio padrão computado ao longo da coluna.
• ➥ axis=1 - significa desvio padrão ao longo da linha.
• ➥ dtype - Tipo de dados utilizado durante o cálculo do desvio padrão.
• ➥ ddof - Permite alterar o divisor pelo valor que especificamos.

#O código a seguir retorna o valor do desvio padrão amostral do conjunto de dados

{1,2,2,3,5}.
 import numpy
x = numpy.array([1,2,2,3,5])
numpy.std(x,ddof=1)
 Função strip(): Elimina os espaços no inicio e fim do string.

a = " Hello, World! "

print(a.strip())
# Resultado
"Hello,World!"
a[0] = ‘H‘.
a(1) = ‘e’.
 Função split(): Converte uma strings em uma lista

a = " Hello, World! "

print(a.split(','))
Resultado em tela:
[' Hello', ' World! ']
a[0]=Hello,
a[1]=World!

v1='Rio de Janeiro'
v2=v1.split('o')
print(v2)
# ['Ri', ' de Janeir', '']

 Função capitalize() : Converte o primeiro caractere em maiúscula

x = "olá, mundo!"
print(x.capitalize()) #retorna "Olá, mundo!

 Função find() : Retorna a posição da primeira ocorrência de um valor em uma string ou -1 se

não existir. 
x = "Uma vez Flamengo, sempre Flamengo!"
print(x.find("vez")) #retorna 4
 Função index() : Semelhante ao find(), mas retorna uma exceção caso o valor não exista.

x = "Uma vez Flamengo, sempre Flamengo!"

print(x.index("vasco")) #retorna ValueError
 Função len(): Retorna o tamanho da strings OU tamanho da lista (se variável é lista)

x = "Uma vez Flamengo, sempre Flamengo!"

print(len("x")) #retorna 34
lista=[‘a’,’b’,’c’]
print(list.len()) # 3
 Função Range(start,stop,step): Cria uma sequência numérica, começa com start e incrementa
by step e termina no stop. Se informado somente start=> começa com 0.
Print(list(range(6)))
# Saida: [0, 1, 2, 3, 4, 5]

L=["A","E","I","O","U"]
for k in range(-1, -5, -1): # -1,-2,-3,-4
print (L[k+1])
# resultado
AUOI

LEMBRETE:
 Padrão do Index Positivo: Começa com 0 e termina 1 a menos que o final
 Padrão do Index Negativo: Começa com -1.
A E I O U
0 1 2 3 4
-5 -4 -3 -2 -1
 Python String Diversas Funções
 Conversão Numerica

A função int() representa os números inteiros, sejam eles positivos ou

negativos. Assim, ela descondidera quaisquer valores após o ponto (ou seja,
desconsidera casas decimais).
x = int(5.9)
print(x)
5
A função round() irá arredondar o valor para o número inteiro acima do valor
especificado. Assim:
 x = round(3.8)
print(x)
4
A função float() irá retornar todo o valor, inclusive os decimais. Assim:
x = float(3.9)
print(x)
3.9

 Interpolação (antiga forma)
 Interpolar é a inserção de um trecho de texto dentro de outro. A
interpolação, ocorre de várias formas, e, algumas linguagens e
bibliotecas, proporcionam maneiras bastante interessantes e
diferentes para interpolarmos valores. O Python fornece um conjunto
de ferramentas bastante poderosas para esse fim.
 >>> sexo = "masculino"
 >>> nome = "Cláudio"
 >>> interpolar = "Sexo é igual a %s e o nome é igual %s "%(sexo,
nome)
 >>> interpolar
 'Sexo é igual a masculino e o nome é igual Cláudio '
 Interpolação (nova forma) F-STRING
 x = "World"
 print(f"Hello, {x}")
 Função find(): retorna o index da primeira ocorrência de uma strings. Se
encontrar, retorna index caso contrário -1.
 str.find(sub[, start[, end]] )
quote = 'Do small things with great love'
# Substring is searched in 'hings with great love'
print(quote.find('small things', 10))
# -1

# Substring is searched in ' small things with great love'

print(quote.find('small things', 2))
#3

# Substring is searched in 'hings with great lov'

print(quote.find('o small ', 10, -1))
# -1

# Substring is searched in 'll things with'

print(quote.find('things ', 6, 20))
9
 Função rfind(): Retorna o maior índice de uma substring encontrada. Se não
encontrar, retorna -1 caso contrário máximo index.
 str.rfind(sub[, start[, end]] )
quote = 'Do small things with great love'

# Substring is searched in 'hings with great love'

print(quote.rfind('things', 10))
# -1

# Substring is searched in ' small things with great love'

print(quote.rfind('t', 2))
# 25

# Substring is searched in 'hings with great lov'

print(quote.rfind('o small ', 10, -1))
#-1

# Substring is searched in 'll things with'

print(quote.rfind('th', 6, 20))
# 18
 Função join() junta cada item da string com um delimitador específico. Como
pede a questão para se separa os itens de uma lista "Y" com virgulas.

y='aaaaaa justo'
print(",".join(y))
a,a,a,a,a,a, ,j,u,s,t,o

 Acessando item da lista
  Regra da lista: [inicio:fim:passo].
 Default: [0:size:1]
 x[:-1]: Inicia no índice 0, termina no índice -1 (penúltimo elemento e intervalo
aberto), passo de 1
 x[:-1] = [1,2,3,4,5]
thislist = ["apple", "banana", "cherry", "orange", "kiwi", "melon", "mango"]
print(thislist[:4])
# ['apple', 'banana', 'cherry', 'orange']
#This will return the items from index 0 to index 4.

#Remember that index 0 is the first item, and index 4 is the fifth item
#Remember that the item in index 4 is NOT included

thislist = ["apple", "banana", "cherry", "orange", "kiwi", "melon", "mango"]

print(thislist[2:])
['cherry', 'orange', 'kiwi', 'melon', 'mango']
#This will return the items from index 2 to the end.

#Remember that index 0 is the first item, and index 2 is the third

thislist = ["apple", "banana", "cherry", "orange", "kiwi", "melon", "mango"]

print(thislist[-4:-1])
# ['orange', 'kiwi', 'melon']
#Negative indexing means starting from the end of the list.

#This example returns the items from index -4 (included) to index -1 (excluded)
#Remember that the last item has the index -1,

thislist = ["apple", "banana", "cherry", "orange", "kiwi", "melon", "mango"]

print(thislist[:-1])
#['apple', 'banana', 'cherry', 'orange', 'kiwi', 'melon']

thislist = ["apple", "banana", "cherry", "orange", "kiwi", "melon", "mango"]

print(thislist[:-4])
['apple', 'banana', 'cherry']

x=[1,2,3,4,5]
print(x[3::-1])
# [4, 3, 2, 1]

x=[1,2,3,4,5]
print(x[ ::-1])
# [5, 4, 3, 2, 1]

x=[1,2,3,4,5]
print(x[ ::-2])
# [5, 3, 1]

x=[1,2,3,4,5]
print(x[1 ::-2])
# [2]

 Função pop(index): Remove item na lista através da index e retornando o valor removido. Se
informado sem parâmetro, padrão -1 (último item)
# create a list of prime numbers
prime_numbers = [2, 3, 5, 7]
# remove the element at index 2
removed_element = prime_numbers.pop(2)
print('Removed Element:', removed_element)
print('Updated List:', prime_numbers)
# Output:
# Removed Element: 5
# Updated List: [2, 3, 7]
removed_element = prime_numbers.pop()
print('Removed Element:', removed_element)
print('Updated List:', prime_numbers)
# Output:
# Removed Element: 7
# Updated List: [2, 3]

 Função remove(elemento): Remove a primeira ocorrência do item na lista e retornando o valor

removido. Se informado sem parâmetro, padrão -1 (último item)
 fruits = ['apple', 'banana', 'cherry',’banana’]
fruits.remove("banana")
print(fruits)
['apple', 'cherry',’banana’]

 Função append(elemento): Adiciona um item no final da lista

currencies = ['Dollar', 'Euro', 'Pound']

# append 'Yen' to the list
currencies.append('Yen')
print(currencies)
# Output: ['Dollar', 'Euro', 'Pound', 'Yen']
 Função extend(elementos): Adiciona todos elementos no final de outra lista
# create a list
prime_numbers = [2, 3, 5]
# create another list
numbers = [1, 4]
# add all elements of prime_numbers to numbers
numbers.extend(prime_numbers)
print('List after extend():', numbers)
# Output: List after extend(): [1, 4, 2, 3, 5]
 Função insert( index, elemento): Insere item na posição desejada
# create a list of vowels
vowel = ['a', 'e', 'i', 'u']
# 'o' is inserted at index 3 (4th position)
vowel.insert(3, 'o')
print('List:', vowel)
# Output: List: ['a', 'e', 'i', 'o', 'u']
 Biblioteca Numpy (np) trabalha com vetor ARRAY
import numpy as np
arr = np.array([1, 2, 3, 4, 5])
print(arr)
# [1 2 3 4 5]
ATENCAO: VETOR não vem com separação em virgulas

import numpy as np
a = np.array ( [ [ 1,2,3 ],[ 4,5,6 ],[ 7,8,9 ] ] )
print (a[a>5])
# [6 7 8 9] desejamos imprimir apenas os valores que sejam maiores que 5
•
• Biblioteca Pandas (dp) trabalha com dataframe (Matriz)
No Pandas, quando se deseja selecionar mais de uma coluna, utilizam-se colchetes duplos.
Ao analisar um conjunto de dados com Python, um programador resolveu usar um dataframe Pandas de nome dp para
guardá-los. Em um certo momento, ele resolveu que precisaria usar, apenas, quatro colunas de dados do dataframe:
“pais“, “ano“, “renda per capita“ e “expectativa de vida“.
Que fragmento de código Python 3 deve ser usado para selecionar, apenas, essas quatro colunas do dataframe dp?
dp[[“pais“,“ano“,“expectativa de vida“,“renda per capita“]]

 Biblioteca Json

Sabendo que é possível utilizar JSON em programas desenvolvidos em Python, assinale a

opção que apresenta o código correto para que, ao final, o script tenha como resultado a
impressão do valor do processo, ou seja, 1234, a partir do JSON fornecido.

import json

# É um dicionário x é composto de um conjunto de chaves e valores, que podemos

chamar de propriedades de acesso. Em Python, todo dicionário estará entre chaves { }.

x = '{ "MP":"AP", "Processo":1234, "Cidade":"Macapa"}'

# Esse método load é responsável por desserializar um objeto. Esse método possui suporte à
leitura, .read( ), e sua missão é, basicamente, imprimir valores. A variável y carrega em si
todos os valores presentes em um dicionário e fica aguardando informar a chave que deverá
buscar o valor. 

y = json.loads(x)
#o comando print manda a variável y imprimir o valor que está carregado na
 chave Processo, que ao final da execução nos dá como saída o valor 1234.
print(y["Processo"])

# Outras funções
#método dump. Esse método é responsável por serializar um objeto. Esse método possui
suporte à escrita, .write( ), e sua missão é, basicamente, receber valores.
y = json.dump(x)
# O método index é utilizado quando queremos saber em que posição da lista um elemento
está.
y = json.index(x)
# O método split é utilizado para desmembrar uma string. Você informa um texto, por
exemplo, como valor de string e esse método o fatia quebrando o texto em vários pedaços. 
y = json.split(x)
#lambda é um recurso que utilizamos para criar funções anônimas, que são as que realizam
"serviços" simples.
y = json.lambda(x)

PYTHON – Orientado a Objetos

// Declaração de uma classe Pessoa

// Começa com primeira letra maiúscula
// Se nome é composto, usar primeira letra maiúscula em cada palavra: Ex: CamelCase
class Pessoa:

// Atributos e métodos da classe

// Método Construtor de atributos da classe

def __init__(self, nome, sexo, cpf, ativo):
self.__nome = nome // Atributo privado
self.__sexo = sexo // Atributo privado
self.__cpf = cpf // Atributo privado
self.__ativo = ativo // Atributo privado usa-se: dois underline (__) antes do nome do
atributo ou método.
self.nada = True // Atributo publico

// Método da classe: desativar

def desativar(self):
self.__ativo = False
print("A pessoa foi desativada com sucesso")

def get_nome(self):
return self.__nome

// Método Setter – Alterar atributo privado nome.

def set_nome(self, nome):
self.__nome = nome

@property
def nome(self):
return self.__nome

@nome.setter
def nome(self, nome):
self.__nome = nome

// Criação de uma instancia de objeto

if __name__ == "__main__":
pessoa1 = Pessoa("João", "M", "123456", True)
pessoa1.desativar()
pessoa1.ativo = True

print(pessoa1.ativo)

# Utilizando geters e setters

pessoa1.set_nome("José")
 print(pessoa1.get_nome())

# Utilizando properties, outro tipo de recurso para obter/enviar dados aos atributos de uma
classe.
pessoa1.nome = "José"
print(pessoa1.nome)

OBS: Porém, isso é apenas uma “convenção” do Python, ou seja, mesmo definindo o atributo
com visibilidade privada (utilizando dois underlines antes de seu nome), ele poderá ser acessado
de fora da classe.

Os decorators são funções que recebem uma classe ou uma função e retornam algo para
substituir a classe ou a função que receberam. Assim é possível mudar todo o comportamento
da função ou da classe, simplesmente a substituindo por outra coisa, ou adicionar
comportamento ao comportamento padrão.

a) @staticmethod: permite criar métodos estáticos e esses métodos não podem ser sobrescritos
pelas subclasses. Ele é imutável.

b) @classmethod: permite criar métodos estáticos que podem ser sobrescritos pelas subclasses.
Isto é porque o primeiro parâmetro das funções que tem o @classmethod tem que ser sempre
cls (classe)

4.15 .Net Core (versão 5 ou superior).

BLOCO 2:
1. Qualidade de Software.
1.1 Garantia da qualidade de software.

Os fatores de qualidade de software (Medidas de Qualidade de Software) são:

o Operação: Correção, Confiabilidade, Eficiência, Integridade e Usabilidade.

o Revisão: Manutenibilidade, Flexibilidade e Testabilidade.
o Transição: Portabilidade, Reusabilidade e Interoperabilidade.

 Atributos de Qualidade INTERNA E EXTERNA de um Produto de Software

o Funcionalidade – Funções do software, que determinam o que o sistema faz. Direcionada para o
atendimento dos requisitos do usuário.
o Confiabilidade – Atributos que têm impacto na capacidade do software de manter o seu nível de
desempenho, dentro de condições estabelecidas, por um dado período de tempo. não deve
causar prejuízos físicos ou econômicos no caso de falha de sistema.
o Usabilidade - Atributos que respondem pela facilidade de uso do software por usuários com perfil
específico. compreensível, usável e compatível com outros sistemas;
o Eficiência – Relação entre o nível de desempenho do software e a quantidade de recursos
utilizada, sob condições de uso pré-definidas. não deve desperdiçar os recursos do sistema.
o Manutenibilidade – Medida do esforço necessário para fazer alterações, extensões e
complementações no produto de software. deve evoluir. Mudanças são inevitáveis;
o Portabilidade – Facilidade do produto de software ser transferido para outro ambiente
computacional e funcionar adequadamente.
o QUALIDADE EM USO ( PONTO DE VISTA DO USUÁRIO):
 Produtividade
 Eficâcia
 Segurança
Satisfação

MPS.BR (CAI NA PROVA)

 MPS-BR ou Melhoria de Processos do Software Brasileiro, é um modelo de qualidade de processo criado

em 2003 pela Softex (Associação para Promoção da Excelência do Software Brasileiro) para melhorar a
capacidade de desenvolvimento de software nas empresas brasileiras.
 MPS-BR levou em consideração normas e modelos internacionalmente reconhecidos como CMMI (Capability
Maturity Model Integration), e nas normas ISO/IEC 12207 e ISO/IEC 15504 e na realidade do mercado
brasileiro de software.
 O modelo define sete níveis de maturidade:
o A – Em Otimização: há a preocupação com questões como inovação e análise de causas.
o B – Gerenciado Quantitativamente: avalia-se o desempenho dos processos, além da gerência
quantitativa dos mesmos.
o C – Definido: aqui ocorre o gerenciamento de riscos.
o D – Largamente Definido: envolve verificação, validação, além da liberação, instalação e integração de
produtos, dentre outras atividades.
 o E – Parcialmente Definido: considera processos como treinamento, adaptação de processos para
gerência de projetos, além da preocupação com a melhoria e o controle do processo organizacional.
o F – Gerenciado: introduz controles de medição, gerência de configuração, conceitos sobre aquisição e
garantia da qualidade.
o G – Parcialmente Gerenciado: neste ponto inicial deve-se iniciar o gerenciamento de requisitos e de
projetos.
o G (Parcialmente Gerenciado), sendo o nível G o primeiro a ser implementado e o nível A o nível
máximo que a empresa poderá atingir.
 A implementação do MPS-BR exige a aplicação de vários processos referentes ao produto de software. Para
alcançarmos o nível F precisamos implementar os seguintes processos:
o Gerência de Requisitos (Evolução do nível G) – O propósito do processo gerência de Requisitos é
gerenciar os requisitos do produto e dos componentes do produto do projeto e identificar inconsistências
entre os requisitos, os planos do projeto e os produtos de trabalho do projeto;
o Gerência de Projetos (Evolução do nível G) ? O propósito do processo gerência de Projetos é
estabelecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, bem
como prover informações sobre o andamento do projeto que permitam a realização de correções
quando houver desvios significativos no desempenho do projeto;
o Gerência de Portfólio (Opcional) ? o propósito desse processo é iniciar e manter projetos que sejam
necessários, suficientes e sustentáveis, de forma a atender os objetivos estratégicos da organização, é
dispensável para empresas que tem apenas um produto e não tem a necessidade de gerenciar vários
projetos diferentes ao mesmo tempo;
o Gerência de Aquisição (Opcional) ? o propósito desse processo é gerenciar a aquisição de produtos
que satisfaçam às necessidades expressas pelo adquirente, é opcional para empresas que não
necessitam adquirir produtos a parte;
o Gerência de Configuração ? tem o propósito de estabelecer e manter a integridade de todos os
produtos de trabalho de um processo ou projeto e disponibilizá-lo a todos os envolvidos;
o Gerência de Medição ? tem o propósito de coletar, armazenar, analisar e relatar os dados relativos aos
produtos desenvolvidos e aos processos implementados na organização e em seus projetos, de forma a
apoiar os objetivos organizacionais;
o Gerência da Qualidade ? o propósito desse processo é assegurar que os produtos de trabalho e a
execução dos processos estão em conformidades com os planos e recursos definidos.


Do ponto de vista da qualidade de software, para o desenvolvimento de sistemas complexos e de grande porte, o
mais importante é estabelecer uma cultura e uma abordagem positiva da qualidade pelos membros da equipe, não
sendo necessário ou relevante um gerenciamento formal da qualidade de software. (ERRADO)

A validação dos dados de entrada faz parte do requisito de confiabilidade quando se refere à qualidade de
aplicações web. (CERTO)

Um dos atributos de qualidade de software é a capacidade de suas funções, com objetivo de facilitar o
desenvolvimento por times em ambientes separados. (ERRADO)

São quatro as etapas para conseguir software de qualidade: utilização de engenharia de software, gerenciamento
de projetos, controle de qualidade e infraestrutura adequada. (CERTO)

No processo de ciclo de vida de um software, a revisão do software faz parte dos processos de apoio, sendo
aplicada exclusivamente ao código-fonte.(ERRADA) pois A revisão também é feita em documentações geradas pelo
time de desenvolvimento.

Uma revisão por pares de um software avalia os modelos adotados na programação e os erros constantes no
código, o que exige que o programa seja colocado em condições de execução próximas ao ambiente real de
operação.(ERRADO) A programação em par pode ser feita em qualquer etapa do desenvolvimento em código.
No caso de um programa que considere como válidas as idades entre 21 e 75 anos completos de vida, incluindo
esses limites, o conjunto mínimo de valores suficientes para a realização de um teste de unidade que cubra todas
as partições de entrada é 21, 48 e 75.(ERRADO) Para o teste de unidade seria necessário verificar valores fora dos
limites, como 20 e 76, além de entradas não esperadas, como valores negativos, strings e símbolos.

Para a análise estática de um programa em que se deseja verificar erros no uso das variáveis, as técnicas
apropriadas para tal ação incluem a análise de fluxo de dados com uma abordagem backward (para trás ou de
baixo para cima). (CERTO) Integração Ascendentes: o teste de integração ascendente (bottom-up), como o nome
diz, começa a construção e o teste com módulos atômicos (isto é, componentes nos níveis mais baixos na estrutura
do programa). Devido aos componentes serem integrados de baixo para cima, a funcionalidade proporcionada por
componentes subordinados a um dado nível está sempre disponível e a necessidade de pseudocontrolados (stubs)
é eliminada.

Atributo fundamental de qualidade de software, a funcionalidade mede o grau de utilização dos recursos do sistema.
(ERRADA) EFICIENCIA

Embora não seja dirigido a riscos, o modelo de desenvolvimento de sistemas espiral de Boehm inclui,
em seu framework, a etapa de análise e validação dos requisitos.(ERRADO) A espiral de Boehm, como
outros modelos, inclui a etapa de validação e verificação de requisitos. Essa etapa compreende a verificação dos
 requisitos, ou seja, aquela análise que checa se o sistema atende aos requisitos estabelecidos na definição e
projeto do sistema.
1.2 Gerência de configuração de software (GIT).

 git add . - Adiciona tudo (não é uma boa prática)

 git commit -m "sua mensagem" - confirma o que vai para o diretório
 git push origin master – envia as alterações confirmadas do local para o diretório remoto
 git pull – atualiza/baixa no diretório local com o dir remoto (servidor)
 git clone URL.git - quando se quer clonar completamente um diretório.
 git-stash - Acumula as alterações em um outro diretório de trabalho.
 git stash show - Exiba as alterações registradas na entrada stash como uma diferença entre o conteúdo
oculto e o commit quando a entrada stash for criada.
 git checkout – Muda de branch
 git checkout -b new_branch significa Git que permite criar uma branch de nome new_branch e mudar para
essa branch ao mesmo tempo.
 Git init é uma forma de iniciar um novo projeto com Git.

No GIT, o comando git pull é usado para enviar ao repositório a alteração que foi efetivada no computador local.
(ERRADO) Push (não é puxar, é empurrar): Você envia (empurra) as alterações do repositório local para o servidor
de destino. Pull (pull é puxar): Você transfere/baixa (puxa) os arquivos do servidor para a máquina local.

A execução do comando git stash sem argumentos por padrão é similar à execução do comando git stash show, na
medida em que ambas mostram as alterações armazenadas por este comando.(ERRADO)
O comando git checkout é capaz de copiar completamente um repositório para um diretório local. (ERRADO) Esse é
o git clone. O git checkout é para mudar de branch

Para atualizar e sincronizar os dados no repositório do arquivo de nome codigo1, deve ser utilizado o seguinte
comando. git init codigo1 (ERRADO) pois git pull

Considerando um programa em linguagem Java, assinale a opção que apresenta o comando do versionador Git
que permite criar uma branch de nome new_branch e mudar para essa branch ao mesmo tempo. (ERRADO) git
checkout -b new_branch

Na prática de integração contínua para desenvolvimento de software, vários colaboradores criam e mantêm o
código de forma organizada e controlada, utilizando ferramentas como Git (controle de versão), Junit (testes),
Hudson e Jenkins (deploys em ambientes de desenvolvimento e produção), o que reduz a geração de erros de
integração. (CERTO)

1.3 Testes de software (unitário, integração, funcional, aceitação, desempenho, carga, vulnerabilidade).

1.4 Técnicas para aplicação de testes de software (caixa-branca, caixa-preta, regressão e não funcionais).

1.5 Ferramentas para automatização de testes; Técnicas de refatoração de software.

o Refatoração (Reffatoring)
 refatoração é um processo de melhoria de código sem, necessariamente, envolver a criação de novas
features, para transformar um código mal feito ou bagunçado em código limpo e com design simples,
melhorando sua legibilidade e eficiência.
 Vantagens:
o Refatorar evita a deterioração durante o ciclo de vida de um código
o Melhora do entendimento do código, facilitando a manutenção e os famosos bugs.
 todo o código tenha cobertura de testes automatizada para garantir que o comportamento externo não
tenha mudado.
 Alguns práticas do clean code são:
o Utilizar nomes significativos.
o Funções curtas.
o Bons comentários.
o Formatação de código.
o Tratamento de erros.
o etc.
 Quando devemos Refatorar:
o Estivermos implementando algo pela primeira vez.
o Fizermos algo que já foi feito antes. Refaça de tal modo para não repetir.
o Tivermos que fazer algo de novo, ou mesmo quando realizar uma revisão.
  Devemos realizar uma série de alterações atômicas, se possíveis, com um escopo pequeno. Isso vai
deixar o código existente cada vez melhor com o tempo e programa em geral em funcionamento.
 Abaixo, um checklist para o processo de refatoração:
o O código deve estar conforme as práticas do Clean Code.
o Não há desenvolvimento de novas features.
o Os testes passam depois da refatoração, todos eles.
 As técnicas de refatoração são:
o Método de extração. Problema: você tem um fragmento de código que pode ser agrupado.
Solução: mova esse código para um novo método (ou função) separado e substitua o código
antigo por uma chamada ao método.
o Método em linha. Problema: quando um corpo de método é mais óbvio que o próprio
método, use esta técnica. Solução: substitua as chamadas para o método pelo conteúdo do
método e exclua o próprio método no processo de refatoração.
o Extrair variável. Problema: você tem uma expressão difícil de entender. Solução: coloque o
resultado da expressão ou de suas partes em variáveis separadas que são auto-explicativas.
o Dividir variável temporária. Problema: você tem uma variável local usada para armazenar
vários valores intermediários dentro de um método (exceto para variáveis de ciclo). Solução:
use variáveis diferentes para valores diferentes. Cada variável deve ser responsável por
apenas uma coisa em particular.
o Remover atribuições a parâmetros. Problema: algum valor é atribuído a um parâmetro
dentro do corpo do método. Solução: use uma variável local em vez de um parâmetro na
refatoração.
 As técnicas de substituição são:
o Temp inline. Problema: você tem uma variável temporária à qual é atribuído o resultado de
uma expressão simples e nada mais.. Solução: substitua as referências à variável pela
própria expressão na refatoração.
o Substituir Tem por consulta. Problema: você coloca o resultado de uma expressão em uma
variável local para uso posterior no seu código.Solução: mova a expressão inteira para um
método separado e retorne o resultado. Consulte o método em vez de usar uma variável.
Incorpore o novo método em outros métodos, se necessário.
o Substituir método por objeto de método. Problema: você tem um método longo no qual
variáveis locais estão tão entrelaçadas que não é possível aplicar o Método de Extração.
Solução: transforme o método em uma classe separada para que as variáveis locais se
tornem campos da classe. Em seguida, você pode dividir o método dentro da mesma classe.
o Algoritmo substituto: Problema: substituir um algoritmo existente por um novo. Solução:
substitua o corpo do método que implementa o algoritmo por um novo algoritmo.

No processo de TDD (test driven development), a refatoração deve acontecer após o

código do software ter sido escrito e testado. (CERTO)

Refactoring (refatoração) é o processo utilizado para reescrever aplicações

desatualizadas, com a finalidade de incrementar e melhorar suas funcionalidades; o uso
dessa técnica normalmente aprimora aplicações para disponibilizá-las na Internet.
(ERRADO)
Refatoração (do inglês refactoring) é o processo de modificar um sistema de software para
melhorar a estrutura interna do código sem alterar seu comportamento externo e sem
implementar novas funcionalidades.

A refatoração recomendada pela metodologia XP consiste na reorganização interna do

código-fonte sem alteração no seu comportamento, o que permite melhorias no projeto,
mesmo após o início da implementação.(CERTO)

Refactoring é o processo que efetua mudanças em um código existente e funcional sem

alterar seu comportamento externo, com o objetivo de aprimorar a estrutura interna do
código. (CERTO)

1.6 Tratamento do débito técnico.

o Débito técnico (ou dívida técnica) é um conceito no desenvolvimento de software que representa o custo implícito
de uma implementação/solução pensada somente no agora, em vez de usar uma abordagem com melhor
qualidade porém que levaria mais tempo.
o Em termos de software, essa dívida cria a dificuldade de manutenção de código, gerando ainda mais atrasos e
mudanças no produto final.
o Não dá para zerar, isso mesmo, se você acha que a solução dos seus problemas é acabar com todo o débito
técnico do seu projeto, você está enganado. A dívida técnica é inevitável e, portanto, sempre irá existir, cabendo
a nos somente controla-la. Por exemplo, somente com o passar do tempo, cria-se esse tipo de problema pois o
código acaba envelhecendo.
o Motivos do surgimento de um débito técnico
  Prazos fora da realidade
 Falta de conhecimento técnico
 Escolha de tecnologia inadequada
 Passar do tempo
 Falta de uma metodologia de desenvolvimento iterativa (sem feedback e teste do cliente)
o Existem 4 tipos de débito técnico:
 Imprudente intencional: “Sabemos do problemas mas não vamos resolver!”
 Imprudente não intencional: “Trabalhar com uma nova linguagem de programação”
 Consciente intencional: “Temos um prazo X, precisamos entregar com esses problemas, depois
corrigimos”
 Consciente não intencional: “Agora que entregamos o projeto sabemos como deveríamos ter feito.”
o Como mensurar débito técnico: Embora o conceito de débito seja subjetivo, existem diversas maneiras de
mensurá-lo, sendo elas:
 Duplicação de código
 Cobertura de testes
 Fragilidade de builds
 Linhas de código comentadas
 Complexidade ciclomática
 Coesão do código
o Nessa fase é importante evitar ao máximo a dívida técnica, e inclusive, matar alguns débitos da fase anterior.
Nesse momento surgirão problemas de performance, usabilidade, arquiteturas que são frutos de dívidas
passadas.O máximo de cuidado aqui é pouco, pois como dito anteriormente, quanto mais débito deixarmos, mais
difícil é dar manutenção no projeto.

1.7 Métricas de qualidade de código.

 Métricas de software são parâmetros para a medição do desempenho de um software. Uma

métrica é um padrão de medida do grau em que um sistema ou processo de software é dotado de
uma dada propriedade.
 Ainda que uma métrica não seja uma medida (as métricas são funções, enquanto as medidas são
os números obtidos pela aplicação da métrica), muitas vezes os dois termos são usados como
sinônimos.
 Também podemos dividir as métricas de software, sob o ponto de vista de aplicação, em duas
categorias:
o métricas de produtividade: concentram-se na saída do processo de engenharia de
software.
o métricas de qualidade. As métricas de qualidade indicam o quanto o software atende
aos requisitos definidos pelo usuário.
 Tais métricas, no processo de engenharia de software, podem ser:
o Diretas: As diretas são o custo e o esforço aplicado ao desenvolvimento e manutenção
do software e do produto. A quantidade de linhas de código produzidas e o total de
defeitos registrados durante um determinado período de tempo.
Exemplos de Metricas Diretas:
 Custo
 Esforço
 Linhas de Código
 Velocidade de Execução
 Memória
 Número de Erros
 Complexidade Ciclomática: Essa complexidade é computada através do
grafo de fluxo de controle do programa: os nós do grafo correspondem a
grupos indivisíveis de comandos, e uma aresta direcionada conecta dois nós
se o segundo comando pode ser executado imediatamente após o primeiro. A
complexidade ciclomática também pode ser aplicada a funções, módulos,
métodos ou classes individuais de um programa. Complexidade ciclomática
é uma métrica de software que fornece uma medida quantitativa da
complexidade lógica de um programa. Quando usada no contexto do método
de teste de caminho básico, o valor calculado para a complexidade ciclomática
define o número de caminhos independentes no conjunto base de um
programa, fornecendo um limite superior para a quantidade de testes que
devem ser realizados para garantir que todos os comandos tenham sido
executados pelo menos uma vez.
o Indiretas: a Qualidade e a funcionalidade do software, ou a sua capacidade de
manutenção, são mais difíceis de serem avaliadas e só podem ser medidas de forma
indireta. Exemplos de métricas indiretas:
 Funcionalidade
 Qualidade
 Complexidade
 Eficiência
  Confiabilidade
 Manutenibilidade
 As medições de software podem ser organizadas em outras classes:
o Métricas da produtividade: baseadas na saída do processo de desenvolvimento do
software, com o objetivo de avaliar o próprio processo;
o Métricas da qualidade: permitem indicar o nível de resposta do software a exigências
explícitas ou implícitas do cliente, com relação ao definido pela gerência de qualidade;
o Métricas técnicas,: envolvem aspectos tais como funcionalidade, modularidade,
manutenibilidade, etc..
 Sob uma outra ótica, é possível definir uma nova classificação das medições:
o Métricas orientadas ao tamanho, baseadas nas medições diretas da engenharia de
software; tais como contagem de linhas de código
o Métricas orientadas à função, que oferecem medidas indiretas;
o Métricas orientadas às pessoas, que dão indicações sobre a forma como as pessoas
desenvolvem os programas de computador.
 Análise de pontos de função (APF) : mede o tamanho funcional do software, subsídios para o
cálculo da produtividade do processo de desenvolvimento com base na funcionalidade ou utilidade
dos programas. Esta avaliação é realizada sob o ponto de vista do usuário que avalia o tamanho e
a complexidade de um software. Nesta contagem são consideradas os seguintes itens da
aplicação. Os pontos calculados servem para se chegar às horas totais do projeto.
o Os objetivos da análise de pontos de função são medir:
 A funcionalidade implementada no software, que o usuário solicita e recebe;
 A funcionalidade impactada pelo desenvolvimento, melhoria e manutenção de
software, independentemente da tecnologia utilizada na implementação.
o A APF pode ser aplicado a todos os domínios funcionais. O IFPUG (International
Function Point Users Group) publica constantemente artigos fornecendo orientações
para a utilização do método em ambientes e domínios diferentes.
o Os analistas de pontos de função do IFPUG identificaram diferentes taxas de entrega
(horas para entregar um ponto de função) relacionadas à construção de aplicações em
diferentes domínios funcionais, calibradas para diversos tamanhos de projeto e
complexidade do software.
o Os componentes do Ponto de Função são:
 Funções de dados:
 Arquivos Lógicos Internos (ALIs): grupos de dados logicamente
relacionados, ou informações de controle, mantidos dentro da
fronteira da aplicação. A principal função de um ALI é agrupar os
dados mantidos por um ou mais processos elementares da
aplicação que está sendo contada.
 Arquivos de Interface Externa (AIEs); são grupos de dados
logicamente relacionados, ou informações de controle, referenciados
pela aplicação, mas mantidos dentro da fronteira da outra aplicação.
Isso significa que um AIE contado para uma aplicação deverá ser
um ALI em outra.
 A complexidade dos ALIs e AIEs se dá em função do número de
RLRs (tipos de registro elementar) e dos DERs (tipo de dado
elementar).
 Funções de Transação:
 Entradas Externas (EE): As EEs são processos elementares que
processam dados ou informações de controle que vêm de fora das
fronteiras da aplicação. A função primária de uma EE é manter um
ou mais ALIs e/ou alterar o comportamento do sistema. A
complexidade da EE é dada em função do número de ALRs (tipos
de arquivos referenciados ou arquivos referenciados) e dos DERs
(tipo de dado elementar),
 Saídas Externas (SE): As SEs são processos elementares que
enviam dados ou informações de controle para fora das fronteiras
da aplicação. A função primária de uma SE é apresentar informação
para o usuário através de processamento lógico exceto em
recuperação de dados ou informação de controle. O processamento
lógico tem que possuir pelo menos uma fórmula matemática ou
cálculo, gerar dados derivados, manter um ou mais ALIs ou alterar o
comportamento do sistema.
 Consultas Externas (CE): são processos elementares que enviam
dados ou informações de controle para fora das fronteiras da
aplicação. A função primária de uma CE é apresentar informação
para o usuário através da recuperação de dados ou informação de
controle. O processamento lógico não deve possuir fórmula
matemática ou cálculo e não deve gerar dados derivados. Nenhum
 ALI é mantido durante o processo ou o comportamento do sistema é
alterado.
o Processos de contagem de pontos de função devem ser executadas, a fim de identificar
as atividades e classificar os componentes funcionais básicos (ALI,AIE,EEE,SE,CE):
 Reunir a documentação disponível (ou acesso a especialistas)
 Determinar o escopo e a fronteira da contagem, identificando os Requisitos
Funcionais do Usuário;
 Medir as funções de dados;
 Medir as funções de transação;
 Calcular o tamanho funcional;
 Documentar a contagem de pontos de função;
 Reportar o resultado da contagem de pontos de função.

A métrica de qualidade de código que mede a complexidade estrutural de um programa

computando o número de caminhos linearmente independentes ao longo do código-fonte é
denominada complexidade ciclomática. (CERTO)

índice de manutenibilidade é a métrica de qualidade de software e não do código.

Uma forma de aferir a qualidade de um código desenvolvido é avaliar a quantidade de

autorreferências feitas em módulos do código. Essa métrica é conhecida como complexidade
ciclomática. (ERRADA)

Para garantir a qualidade de um software, a sua medição deve permitir comparações confiáveis
entre produtos/funções equivalentes. Os procedimentos de medição devem conter critérios aceitos e
validados que possam ser replicados e que tenham uma margem de tolerância a erros humanos.
(CERTO)

Considerando os aspectos de manutenibilidade, assinale a opção que apresenta a caraterística de

qualidade de software que corresponde à capacidade do produto de permitir o diagnóstico de
deficiências ou de causas de falhas, bem como a identificação das partes a serem
modificadas. (ANALISABILIDADE)

http://www.bianchi.pro.br/edutec/qualsoft.php

o Qualidade de produtos de software (ISO/IEC 9126 e NBR 13596)

 A norma ISO/IEC 9126 de 1991 ou NBR 13596 de 1996 representa a atual padronização mundial para a
qualidade de produtos de software ;
 Baseada em três níveis: características, subcaracterísticas e métricas; onde cada característica é
refinada em um conjunto de subcaracterísticas e cada subcaracterísticas é avaliada por um conjunto de
métricas.
De acordo com a NBR ISO/IEC 9126, entre as subcaracterísticas da característica confiabilidade,
aquela que corresponde à capacidade do produto de software de evitar falhas decorrentes de
defeitos no software é a MATURIDADE
 1.8 Code Smell.

 Code Smell (cheiro de código) é qualquer característica no código-fonte de um programa que possivelmente
indica um problema mais profundo.
 Code Smells não são bugs, contudo, eles indicam pontos fracos que podem ocasionar falhas no presente ou
no futuro.
 Cinco tipos de code smell mais comuns:
o Bloaters: Bloater (inchaço) é quando um código cresce demais, já que as suas responsabilidades não
foram bem definidas durante o seu planejamento. Ocorre quando o código consome responsabilidades
de outras classes.
o Object-Orientation Abusers: Trata-se da violação à orientação de objetos. Assim, a aplicação
inadequada total ou parcialmente da herança, polimorfismo ou encapsulamento podem provocar
problemas no código. Para identificar este problema, repare se o código tem muitos ifs ou switches
complexos.
o Change Preventers: É o tipo de código que dificulta a manutenção, pois está relacionado à ideia de
“código espaguete”. Ele é aquele que ao “puxar” um ponto para correção, automaticamente se atinge
outros pontos. De maneira geral, códigos assim devem ser reescritos.
o Dispensables: São os trechos do código que podem ser removidos sem afetar a aplicação, como
comentários longos, partes duplicadas e outros itens que deixam o código-fonte longo demais. Afinal,
um código enxuto reduz a chance de erros e falhas.
o Couplers: Trata-se do alto acoplamento, que é a forma que temos de medir o quão dependente uma
classe é das outras. Assim, uma boa prática da Programação Orientada a Objetos (POO) é que uma
aplicação de qualidade tem baixo acoplamento. Portanto, o ideal é prevenir este problema.

2. Estrutura de Dados e Algoritmos.

2.1 Tipos básicos de dados.

 As variáveis compostas homogêneas são estruturas de dados que caracterizam-se por um conjunto de
variáveis do mesmo tipo. Elas pode ser unidimensionais (array) ou multidimensionais (matrizes)
 As variáveis compostas heterogeneas são estruturas de dados que caracterizam-se por um conjunto de
variáveis de vários tipos diferentes. Exemplo: Registros pois pois podem agrupar variáveis de tipos diferentes.

 Ela é definida por um conjunto de dados armazenados na memória de um equipamento como um computador, por
exemplo. Esses dados precisam funcionar de modo eficiente e fazer sentido.
 entenda-se um elemento estrutural responsável por transportar consigo informações internas em um software. Já
por “dados” entenda-se como um elemento que possui um valor e tem utilização para resolver problemas
computacionais.
 Uma estrutura de dados possui vários tipos. Conheça alguns dos principais e mais utilizados pela programação:
o Array (vetores): estruturas lineares e estática. São compostas por um número finito. O seu uso é
recomendado para quando há dados armazenados que não apresentarão mudança significativa com o
tempo.
o Lista: linear e dinâmica, possui nós que direcionam para o elemento a seguir (exceto o último).
o Lista encadeada: - Listas são estruturas lineares. Posições alocadas na memória onde um Elemento
armazena o endereço do PRÓXIMO elemento. Não há nenhum outro ponteiro para anterior
o Lista duplamente encadeada: Listas são estruturas lineares. cada elemento armazenado apresenta
ligações de apontamento com seu sucessor e com o seu predecessor, o que possibilita que ela seja
percorrida em qualquer sentido.
o Lista Generalizada: Listas generalizadas são estruturas de dados flexíveis que podem
representar qualquer tipo de lista linear, mas tamém como árvores em diferentes graus.
o Àrvore: nessa estrutura, cada elemento possui pelo menos um outro associado a si. Aplicativos de
pesquisa com entrada constante de dados (Árvores binárias); algoritmos de compactação de dados.
o Fila: baseia-se no princípio FIFO. Ele remete às expressões em inglês “first in, first out”. Processos
executados em um sistema operacional (fila). Nessa estrutura os elementos que são inseridos no início
serão os primeiros removidos.
o A fila é uma lista de elementos em que os itens são sempre inseridos em uma das extremidades e
excluídos da outra.
o Pilha: essa estrutura baseia-se no princípio LIFO, que representa as expressões “last in, first. out”.
Nesse caso, os elementos inseridos por último serão removidos primeiramente. Exemplo: chamadas de
funções num interpretador de código (pilha); Pilhas são estruturas lineares, mas também só precisam
conhecer seu topo, e que cada elemento conheça o elemento de baixo. Não é necessária a navegação
nos dois sentidos.
o Registro: são classificados como variáveis compostas heterogêneas, pois podem agrupar variáveis de
tipos diferentes.
 tipo tipest informa ao compilador que um modelo de estrutura está sendo definido.
 inteiro: CODIGO é uma etiqueta que dá nome à definição da estrutura
 <fim_estrutura>; comando, por isso deve terminar em ponto-e-vírgula
o Grafo: Grafos não têm conceito predecessor e sucessor, pois não são elementos lineares. Um grafo
tem nós, que podem se ligar uns aos outros, sem restrição quantidade de ligações. Redes sociais;
 algoritmos de sugestão de conexões; algoritmos de cálculo de relacionamentos (professores,
disciplinas); aplicações voltadas para distribuição de malha elétrica.
o Heap:
o Tabela Hash: Algoritmos de movimentação de personagens em jogos; bancos de dados;
implementação de compiladores. A estrutura de dados que consiste no armazenamento de cada
elemento em um endereço calculado a partir da aplicação de uma função sobre a chave de busca
denomina-se tabela hashing. Os elementos-chave nas funções de hashing são números naturais OU
sequencia de caracteres STRING tipo um conjunto alfanumérico com comprimento fixo de caracteres. A
ocorrência de colisões de hashing em um sistema de armazenamento de dados por tabelas
hashing encadeadas NÃO indica a saturação desse sistema de armazenamento.
o

Na estrutura de dados denominada FILA, o primeiro elemento a ser inserido será o primeiro a ser retirado:
adiciona-se item no fim e remove-se item do início. (CERTO)

Em determinada estrutura de dados, os valores seguem a regra segundo a qual o último a entrar é o primeiro a
sair. (PILHA)

Na estrutura do tipo grafo, cada elemento indica o próximo elemento, seja aquele que o antecede ou aquele
que é seu sucessor, e cada elemento está associado a somente um antecessor e a vários sucessores.
(ERRADO) é ARVORE

As variáveis são classificadas em:

 Quanto ao nível de Mensuração:
o Qualitativas: Podem ser Nominais ou Ordinais
o Quantitativas: Podem ser Discretas ou Contínuas.
 Quanto ao nível de manipulação:
o Independentes
o Dependentes

GRAFO (Não direcionado) / DIGRAFO COM PESOS (Direcionado)

 A teoria dos grafos ou de grafos é um ramo da matemática que estuda as relações entre os objetos de
um determinado conjunto.
 são utilizadas estruturas chamadas de grafos, G ( V , E ) onde V é um conjunto não vazio de objetos
denominados vértices (ou nós) e E (do inglês edges - arestas) é um subconjunto de pares não
ordenados de V.
 Dependendo da aplicação, arestas podem ou não ter direção, pode ser permitido ou não arestas ligarem
um vértice a ele próprio e vértices e/ou arestas podem ter um peso (numérico) associado. Se as arestas
têm um sentido associado (indicado por uma seta na representação gráfica) temos um dígrafo (grafo
orientado). Um grafo com um único vértice e sem arestas é conhecido como grafo trivial.
 Representação gráfica Exemplo:

 Um gráfico com 6 vértices (nós) e 7 arestas. Onde conjunto de vértices: V={1,2,3,4,5,6} e um conjunto
de arestas E={ {1,2},{1,5},{2,3},{2,5},{3,4},{4,5},{ 4,6} }
 Representação por adjacência: vértices são representados como regiões disjuntas no plano e arestas
são representadas por adjacências entre regiões
o Vertice (Nó) 1 e 2 são adjacentes mas os vértices 2 e 4 não são adjacentes pois não há
arestas entre eles.
o O conjunto de vizinhos de um vértice consiste de todos os vértices adjacentes a ele. No
grafo-exemplo, o vértice 1 possui 2 vizinhos: vértice 2 e vértice 5.
 Representação por visibilidade: vértices são representados por regiões no plano e arestas são
representadas por regiões com uma linha de visão desobstruída para cada vértice.
 Representação por intersecção no qual vértices são representados como objetos geométricos não
disjuntos e arestas são representadas por suas intersecções;
 Na computação, um grafo finito direcionado ou não-direcionado (com, digamos, n vértices) é geralmente
representado por sua matriz de adjacência: uma matriz n-por-n cujo valor na linha i e coluna j fornece
o número de arestas do i-ésimo ao j-ésimo vértices.
 Representação por Valencia/Grau: A valência (ou grau) de um vértice é o número de arestas
incidentes a ele. Se houver laços, serão contados duas vezes. No grafo de exemplo os vértices 1 e 3
possuem uma valência de 2, os vértices 2, 4 e 5 têm a valência de 3 e o vértice 6 tem a valência de 1.
Se E é finito, então a valência total dos vértices é o dobro do número de arestas. Em um dígrafo
(direcionado), distingue-se o grau de saída (o número de arestas saindo de um vértice) e o grau de
entrada (o número de arestas entrando em um vértice). O grau de um vértice em um dígrafo é igual à
 soma dos graus de saída e de entrada. O grau de um vértice é definido somente quando o número de
arestas incidentes sobre o vértice é finito.
 Caminho: é uma sequência de vértices tal que de cada um dos vértices existe uma aresta para o
vértice seguinte. Um caminho é chamado simples se nenhum dos vértices no caminho se repete. O
comprimento do caminho é o número de arestas que o caminho usa, contando-se arestas múltiplas
vezes. O custo de um caminho num grafo balanceado é a soma dos custos das arestas atravessadas.
Dois caminhos são independentes se não tiverem nenhum vértice em comum, exceto o primeiro e o
último.
o No grafo de exemplo, (1, 2, 5, 1, 2, 3) é um caminho com comprimento 5, e (5, 2, 1) é um
caminho simples de comprimento 2.
o Caminho euleriano em um grafo é o caminho que usa cada aresta exatamente uma vez.
o Caminho hamiltoniano em um grafo é o caminho que visita cada vértice exatamente uma
vez.
o Ciclo (ou circuito) é um caminho que começa e acaba com o mesmo vértice. Ciclos de
comprimento 1 são laços. No grafo de exemplo, (1, 2, 3, 4, 5, 2, 1) é um ciclo de comprimento
6. Um ciclo simples é um ciclo que tem um comprimento pelo menos de 3 e no qual o vértice
inicial só aparece mais uma vez, como vértice final, e os outros vértices aparecem só uma
vez. No grafo acima, (1, 5, 2, 1) é um ciclo simples. Um grafo chama-se acíclico se não
contém ciclos simples.
o Laço (loop) num grafo ou num dígrafo é uma aresta e em E cujas terminações estão no
mesmo vértice.
o Exemplo:

 São 3 ciclos de comprimento igual a TRÊS:

 AJ,JB,BA
 BK,KL,LB
 CD,DM,MC
o

 Tipos de Grafos – Dicionário

o Grafo simples é um grafo não direcionado, sem laços e existe no máximo uma aresta entre
quaisquer dois vértices (sem arestas paralelas). Para um grafo simples, o número de vizinhos
de um vértice é igual à sua valência (grau).
o Grafo completo é o grafo simples em que, para cada vértice do grafo, existe uma aresta
conectando este vértice a cada um dos demais. Ou seja, todos os vértices do grafo possuem
mesmo grau. O grafo completo de n vértices é frequentemente denotado por Kn. Ele tem n(n-
1)/2 arestas (correspondendo a todas as possíveis escolhas de pares de vértices).
o Grafo nulo é o grafo cujo conjunto de vértices é vazio.
o Grafo vazio é o grafo cujo conjunto de arestas é vazio.
o Grafo trivial é o grafo que possui apenas um vértice e nenhuma aresta.
o Grafo regular é um grafo em que todos os vértices tem o mesmo grau.
o Multigrafo é um grafo que permite múltiplas arestas ligando os mesmos vértices (arestas
paralelas).
o Pseudografo é um grafo que contém arestas paralelas e laços.
o Grafo conexo um grafo é conexo se for possível estabelecer um caminho de qualquer vértice
para qualquer outro vértice de um grafo. Se for sempre possível estabelecer um caminho de
qualquer vértice para qualquer outro vértice mesmo depois de remover k-1 vértices, então diz-
se que o grafo está k-conexo. Note que um grafo está k-conexo se, e somente se, contém k
caminhos independentes entre qualquer par de vértices. O grafo de exemplo acima é conexo
(e portanto 1-conexo), mas não é 2-conexo. Em um grafo genérico G, o corte associado a um
conjunto X de vértices é o conjunto de todas as arestas que têm uma ponta em X e outra em
V(G) - X, onde V(G) é o conjunto de todos os vértices pertencentes ao grafo G.
o Ponto de articulação ou Vértice de corte é um vértice cuja remoção desliga um grafo. Uma
ponte é uma aresta cuja remoção desliga um grafo. Um componente biconectado é um
conjunto máximo de arestas tal que qualquer par de arestas do conjunto fazem parte de um
ciclo simples comum. O contorno de um grafo é o comprimento do ciclo simples mais curto no
grafo. O contorno de um grafo acíclico é, por definição, infinito.
o Árvore é um grafo simples acíclico e conexo. Às vezes, um vértice da árvore é distinto e
chamado de raiz. As árvores são muito usadas como estruturas de dados em informática
(veja estrutura de dados em árvore).
 o Subgrafo de um grafo G é um grafo cujo conjunto dos vértices é um subconjunto do conjunto
de vértices G, cujo conjunto de arestas é um subconjunto do conjunto de arestas de G, e cuja
função w é uma restrição da função de G
o Subgrafo gerador é aquele obtido pela remoção de uma ou mais arestas de um outro grafo,
dizemos então que este novo grafo obtido é gerador do primeiro,
o Subgrafo induzido é obtido pela remoção de vértices e consequente das arestas
relacionadas com ele de um outro grafo, dizemos que este novo grafo é um grafo induzido do
original.
o Grafo parcial de um grafo G é um subgrafo com o mesmo conjunto de vértices que G. Uma
árvore parcial é um grafo parcial que é árvore. Todo grafo tem pelo menos uma árvore parcial.
o Clique em um grafo é um subgrafo que também é um grafo completo. No grafo do exemplo
acima, os vértices 1, 2 e 5 formam um clique.
o Conjunto independente em um grafo é um conjunto de vértices não adjacentes entre si. No
exemplo acima, os vértices 1, 3 e 6 formam um conjunto independente e 3, 5 e 6 são outro
conjunto independente.
o Grafo planar é aquele que pode ser representado em um plano sem qualquer intersecção
entre arestas. O grafo do exemplo é planar; o grafo completo de n vértices, para n> 4, não é
planar.
o Grafo bipartido é o grafo cujos vértices podem ser divididos em dois conjuntos, nos quais
não há arestas entre vértices de um mesmo conjunto. Para um grafo ser bipartido ele não
pode conter circuitos de comprimento ímpar.
o Grafo bipartido completo é o grafo bipartido, cujo qualquer vértice do primeiro conjunto é
adjacente a todos vértices do segundo conjunto
o O diâmetro de um grafo é a excentricidade máxima de qualquer vértice do grafo. Ou seja, ele
é a maior distância entre qualquer par de vértices. Para achar o diâmetro de um grafo,
primeiro encontre o caminho mínimo entre cada par de vértices. O maior comprimento de
qualquer um desses caminhos é o diâmetro do grafo.Exemplo:

o
o O grafo em questão tem diâmetro igual a quatro. (CERTO) pois Os pares de vértices mais
distantes são AJ e DM, sendo que o menor caminho entre eles percorre 4 pares de vértices.
J-B-L-C-D=4 / A-B-L-C-M=4
o A soma dos graus de todos os vértices de um grafo é sempre par (CERTO) pois A soma do
graus de um grafo é sempre igual a duas vezes a quantidade de arestas, logo é um
numero par.
 Busca / Percurso em Grafo:
o É possível percorrer de modo sistemático todos os vértices e arestas do grafo. O grafo pode
ser dirigido ou não.
o O percurso em árvores é o processo de visitar cada nó da árvore exatamente uma vez.
o O percurso pode ser interpretado como colocar todos os nós em uma linha, não existe uma
ordem para ser seguida.
o Existem n percursos diferentes, quase todos caóticos.
o Os básicos são percurso em profundidade e percurso em largura
 Fila: Busca em largura (ou Amplitude) ou em extensão (Breadth-First Search
ou BFS). COMECA PELA RAIZ E EXPLORA TODOS OS VIZINHOS PRIMEIRO. A
propriedade especial está no fato de a árvore não possuir ciclos: dados dois
vértices quaisquer, existe exatamente 1 caminho entre eles. Um percurso em
extensão é visitar cada nó começando do menor nível e move-se para os níveis
mais altos nível após nível, visitando cada nó da esquerda para a direita. Sua
implementação é direta quando uma fila é utilizada. Depois que um nó é visitado,
seus filhos, se houver algum, são colocados no final da fila e o nó no início da fila é
visitado. Assim, os nós do nível n+1 serão visitados somente depois de ter visitados
todos os nós do nível n. Computa a menor distância para todos os vértices
alcançáveis. O sub-grafo contendo os caminhos percorridos é chamado de
breadth-first tree.
 Pilha: busca em profundidade (Depth-first search ou DFS). Um algoritmo de
busca em profundidade realiza uma busca não-informada que progride através da
expansão do primeiro nó filho da árvore de busca, e se aprofunda cada vez mais,
até que o alvo da busca seja encontrado ou até que ele se depare com um nó que
não possui filhos (nó folha). Então a busca retrocede (backtrack) e começa no
próximo nó. Numa implementação não-recursiva, todos os nós expandidos
recentemente são adicionados a uma pilha, para realizar a exploração.
 Diferença entre dois métodos de busca:
  A complexidade espacial de um algoritmo de busca em profundidade é
muito menor que a de um algoritmo de busca em largura.
 A complexidade temporal de ambos algoritmos são proporcionais ao
número de vértices somados ao número de arestas dos grafos aos quais
eles atravessam. Quando ocorrem buscas em grafos muito grandes, que
não podem ser armazenadas completamente na memória, a busca em
profundidade não termina, em casos onde o comprimento de um caminho
numa árvore de busca é infinito. O simples artifício de “lembrar quais nós
já foram visitados” não funciona, porque pode não haver memória
suficiente. Isso pode ser resolvido estabelecendo-se um limite de
aumento na profundidade da árvores

2.2 Tipos abstratos de dados (lista, fila, pilha, árvore, heap).

2.3 Sub-rotinas: chamadas por endereço, referência e valor.

2.4 Algoritmos para pesquisa e ordenação.

 Algoritmo de Ordenação:
o Os métodos de ordenação se classificam em:
 Ordenação Interna: onde todos os elementos a serem ordenados cabem na memória
principal e qualquer registro pode ser imediatamente acessado. Há dois métodos:
Métodos Simples e Método Eficientes.
 Ordenação Externa: onde os elementos a serem ordenados não cabem na memória
principal e os registros são acessados sequencialmente ou em grandes blocos.
o Métodos Simples:
 Os métodos simples são adequados para pequenos vetores, são programas pequenos e
fáceis de entender. Possuem complexidade C(n) = O(n²), ou seja, requerem O(n²)
comparações.
 Exemplos:
 Insertion Sort:
o Conhecido como ordenação por inserção
o é o método que percorre um vetor de elementos da esquerda para a
direita e à medida que avança vai ordenando os elementos à
esquerda.
o É estável se a ordem relativa dos itens iguais não se altera durante a
ordenação.
o Possui complexidade C(n) = O(n) no melhor caso e C(n) = O(n²) no
caso médio e pior caso.
o Funcionamento:
 Consiste em cada passo a partir do segundo elemento
selecionar o próximo item da sequência e colocá-lo no
local apropriado de acordo com o critério de ordenação.
 Selection Sort:
o Conhecido como ordenação por seleção
o Consiste em selecionar o menor item e colocar na primeira posição,
selecionar o segundo menor item e colocar na segunda posição,
segue estes passos até que reste um único elemento.
o Para todos os casos (melhor, médio e pior caso) possui
complexidade C(n) = O(n²)
o Não é um algoritmo estável.
 Bubble Sort
o o algoritmo mais simples porém menos eficientes.
o Cada elemento da posição i será comparado com o elemento da
posição i + 1, ou seja, um elemento da posição 2 será comparado
com o elemento da posição 3. Caso o elemento da posição 2 for
maior que o da posição 3, eles trocam de lugar e assim
sucessivamente. Por causa dessa forma de execução, o vetor terá
que ser percorrido quantas vezes que for necessária, tornando o
algoritmo ineficiente para listas muito grandes.
 o
o Funcionamento:
 É verificado se o 3 é maior que 5, por essa condição ser
falsa, não há troca.
 É verificado se o 5 é maior que 1, por essa condição ser
verdadeira, há uma troca.
 É verificado se o 5 é maior que 2, por essa condição ser
verdadeira, há uma troca.
 É verificado se o 5 é maior que 4, por essa condição ser
verdadeira, há uma troca.
 O método retorna ao início do vetor realizando os mesmos
processos de comparações, isso é feito até que o vetor
esteja ordenado.
o
o Métodos Eficientes:
 Os métodos eficientes são mais complexos nos detalhes, requerem um número menor
de comparações. São projetados para trabalhar com uma quantidade maior de dados e
possuem complexidade C(n) = O(n log n).
 Exemplos:
 Quick sort,(Dividir para Conquistar)
o é o método de ordenação interna mais rápido e mais utilizado
o Possui complexidade C(n) = O(n²) no pior caso e C(n) = O(n log n)
no melhor e médio caso
o Não é um algoritmo estável.
o Funcionamento:
o emprega a estratégia de “divisão e conquista” onde a ideia básica é
dividir o problema de ordenar um conjunto com n itens em dois
problemas menores.
 Escolhe um elemento da lista chamado pivô.
 Reorganiza a lista de forma que os elementos menores
que o pivô fiquem de um lado, e os maiores fiquem de
outro. Esta operação é chamada de “particionamento”.
 Recursivamente ordena a sub-lista abaixo e acima do
pivô.
o desvantagem deste método é que ele possui uma implementação
difícil e delicada, um pequeno engano pode gerar efeitos
inesperados para determinadas entradas de dados.
 Merge sort,
o algoritmo de ordenação que faz uso da estratégia “dividir para
conquistar” para resolver problemas.
o É um método estável
o possui complexidade C(n) = O(n log n) para todos os casos.
o Esse algoritmo divide o problema em pedaços menores, resolve
cada pedaço e depois junta (merge) os resultados. O vetor será
dividido em duas partes iguais, que serão cada uma divididas em
duas partes, e assim até ficar um ou dois elementos cuja ordenação
é trivial.
 Shell sort,
o algoritmo de ordenação por inserção (Insert Sort)
o Ele permite a troca de registros distantes um do outro, diferente do
algoritmo de ordenação por inserção que possui a troca de itens
adjacentes para determinar o ponto de inserção.
 o Conhecido O algoritmo que se baseia em "saltos" (gap) de
comparação
o Merge Sort usa a recursividade, há um alto consumo de
memória e tempo de execução, tornando esta técnica não
muito eficiente em alguns problemas.
o
 Heap sort,
 Radix sort,

 Busca Binária

o Utiliza o método do “dividir para conquistar”: busca o elemento do meio da coleção, dividindo-a em
duas sub-coleções
o Compara-se o valor procurado com o elemento no centro da coleção:
 – Se for igual, encontrou;
 – Se for menor, repete a busca na sub-coleção à esquerda do centro;
 – Se for maior, repete a busca na sub-coleção à direita do centro;
• Não funciona sobre coleções não-ordenadas!
• Ordem de Complexidade: O(log2 n)
• No pior caso são realizadas “log2 n” comparações
 Busca Sequencial

•Caminha de um por um procurando o valor

• Mais lenta quanto maior for a coleção
• Pode ser realizada também em estruturas não ordenadas
• Simples
• Ordem de Complexidade: O(n)
• No pior caso, são realizadas “n” comparações

 Comparações

TEMPO (MS):
(+RAPIDO) QUICK SORT < INSERT SORT < SELECTION SORT (+LENTO)

COMPARACOES:
INSERT SORT < QUICK SORT < SELECTION SORT < BUBBLE SORT

MOVIMENTACAO:
QUICK SORT < SELECTION SORT < INSERT SORT < BUBBLE SORT

Assinale a opção que apresenta a técnica que tem a maior complexidade de tempo de execução.
(SELECTION SORT)

Situação hipotética: Para ordenar os números do vetor (0, 4, 2, 1, 3, 5, 7, 8, 9, 6), foram realizados
os passos mostrados na figura a seguir, com seus respectivos resultados a cada passagem, tendo
sido o número 5 do vetor utilizado inicialmente como pivô. Nessa situação, foi utilizado o método de
ordenação do tipo quicksort.(CERTO)
 Para ordenar os números do vetor (30, 50, 10, 20, 40), foram realizados os passos i a vi,
apresentados a seguir, com os respectivos resultados a cada passagem. (Assertiva: Nessa
situação, os passos realizados constituem um algoritmo do tipo bubble sort, ou bolha. CERTO)

Na pesquisa do tipo sequencial, há aumento do desempenho se a tabela estiver ordenada pelo

valor da chave. (CERTO)

O método de ordenação conhecido como quick sort utiliza o maior elemento, o qual é sempre
colocado ao final do vetor, para garantir que a ordenação seja realizada em ordem decrescente.
(ERRADO)

2.5 Algoritmos para determinação de caminho mínimo.

2.6 Listas lineares e suas generalizações: listas ordenadas, listas encadeadas, pilhas e filas; Vetores e
matrizes.

2.7 Árvores e suas generalizações: árvores binárias, árvores de busca, árvores balanceadas (AVL),
árvores B e B+.

 Arvore Binária:
o Uma árvore binária é uma estrutura de dados caracterizada por:
 Ou não tem elemento algum (árvore vazia).
  Ou tem um elemento distinto, denominado raiz, com dois ponteiros para duas estruturas
diferentes, denominadas subárvore esquerda e subárvore direita.
o A definição é recursiva e, devido a isso, muitas operações sobre árvores binárias utilizam função
recursiva.
o É o tipo de árvore mais utilizado na computação. A principal utilização de árvores binárias são as
árvores binárias de busca
o Os nós de uma árvore binária possuem graus zero, um ou dois. Um nó de grau zero é denominado
folha.
o por definição, cada nó poderá ter até duas folhas, sendo que ela se compara com a ABB (árvore
binária de busca)
o A profundidade de um nó é a distância deste nó até a raiz. Um conjunto de nós com a mesma
profundidade é denominado nível da árvore. A maior profundidade de um nó, é a altura da árvore.
o Uma árvore "estritamente binária" é uma árvore na qual todo nó tem zero ou duas folhas.
o Em Teoria dos grafos:
 Em teoria dos grafos, uma árvore binária é definida como um grafo acíclico, conexo,
dirigido e que cada nó não tem grau maior que 2. Assim sendo, só existe um caminho
entre dois nós distintos.
 E cada ramo da árvore é um vértice dirigido, sem peso, que parte do pai e vai para o
filho.
o Uma das maneiras mais simples de representar árvores binárias em linguagens de programação é
por meio de arranjos unidimensionais (vetores).

 Arvore de Busca Binária (Arvore binária de Pesquisa) ABB

o é uma estrutura de dados de árvore binária baseada em nós, onde todos os nós da subárvore
esquerda possuem um valor numérico inferior ao nó raiz e todos os nós da subárvore direita
possuem um valor superior ao nó raiz (esta é a forma padrão, podendo as subárvores serem
invertidas, dependendo da aplicação).

o Elementos
o Nós – são todos os itens guardados na árvore
o Raiz – é o nó do topo da árvore (no caso da figura acima, a raiz é o nó 8)
o Filhos – são os nós que vem depois dos outros nós (no caso da figura acima,
o nó 6 é filho do 3)
o Pais – são os nós que vem antes dos outros nós (no caso da figura acima, o
nó 10 é pai do 14)
o Folhas – são os nós que não têm filhos; são os últimos nós da árvore (no caso
da figura acima, as folhas são 1, 4, 7 e 13)
o Operações com Arvore Binária
o BUSCA: A busca em uma árvore binária por um valor específico pode ser um processo
recursivo ou iterativo. Será apresentado um método recursivo. A busca começa examinando o
nó raiz. Se a árvore está vazia, o valor procurado não pode existir na árvore. Caso contrário,
se o valor é igual a raiz, a busca foi bem sucedida. Se o valor é menor do que a raiz, a busca
segue pela subárvore esquerda. Similarmente, se o valor é maior do que a raiz, a busca
segue pela subárvore direita. Esse processo é repetido até o valor ser encontrado ou a
subárvore ser nula (vazia). Se o valor não for encontrado até a busca chegar na subárvore
nula, então o valor não deve estar presente na árvore.
o INSERCAO: A inserção começa com uma busca, procurando pelo valor, mas se não for
encontrado, procuram-se as subárvores da esquerda ou direita, como na busca.
Eventualmente, alcança-se a folha, inserindo-se então o valor nesta posição. Ou seja, a raiz é
examinada e introduz-se um nó novo na subárvore da esquerda se o valor novo for menor do
que a raiz, ou na subárvore da direita se o valor novo for maior do que a raiz.
o REMOCAO: A exclusão de um nó é um processo mais complexo. Para excluir um nó de uma
árvore binária de busca, há de se considerar três casos distintos para a exclusão: Neste caso,
pode-se operar de duas maneiras diferentes.
 Remoção de nó com dois filhos: Pode-se substituir o valor do nó a ser retirado pelo
valor sucessor (o nó mais à esquerda da subárvore direita) ou pelo valor antecessor
(o nó mais à direita da subárvore esquerda), removendo-se aí o nó sucessor (ou
antecessor).
o Percursos em ABB:
o Em uma árvore binária de busca podem-se fazer os três percursos que se fazem para
qualquer árvore binária (percursos em inordem, pré-ordem e pós-ordem). É interessante notar
que, quando se faz um percurso em ordem em uma árvore binária de busca, os valores dos
nós aparecem em ordem crescente. A operação "Percorre" tem como objetivo percorrer a
 árvore numa dada ordem, enumerando os seus nós. Quando um nó é enumerado, diz-se que
ele foi "visitado".
o Tipo de percurso:

 Pré-ordem (ou profundidade): Pré-ordem => 8, 3, 1, 6, 4, 7, 10, 14, 13

 Visita a raiz
 Percorre a subárvore esquerda em pré-ordem
 Percorre a subárvore direita em pré-ordem
 Ordem Simétrica: Ordem simétrica => 1, 3, 4, 6, 7, 8, 10, 13, 14 (chaves
ordenadas)
 Percorre a subárvore esquerda em ordem simétrica
 Visita a raiz
 Percorre a subárvore direita em ordem simétrica
 Pós-ordem: Pós-ordem => 1, 4, 7, 6, 3, 13, 14, 10, 8
 Percorre a subárvore esquerda em pós-ordem
 Percorre a subárvore direita em pós-ordem
 Visita a raiz

 Arvore balanceadas (AVL)

o é uma árvore balanceada (árvore completa) são as árvores que minimizam o número de
comparações efetuadas no pior caso para uma busca com chaves de probabilidades de
ocorrências idênticas. Vide comparação: Arvore Não AVL e Árvore AVL

o Nessa estrutura de dados cada elemento é chamado de nó. Cada nó armazena uma chave e dois
ponteiros, uma para a subárvore esquerda e outro para a subárvore direita.
o Uso de técnica de rotação para balancear a arvore:
 A operação básica em uma árvore AVL geralmente envolve os mesmos algoritmos de
uma árvore de busca binária desbalanceada. A rotação na árvore AVL ocorre devido ao
seu desbalanceamento, uma rotação simples ocorre quando um nó está desbalanceado
e seu filho estiver no mesmo sentido da inclinação, formando uma linha reta. Uma
rotação-dupla ocorre quando um nó estiver desbalanceado e seu filho estiver inclinado
no sentido inverso ao pai, formando um "joelho".

o A árvore AVL é muito útil, pois executa as operações de inserção, busca e remoção em tempo
O(log n). Comparado-a com a árvore rubro-negra, a AVL é mais rápido nas aplicações que
fazem uma quantidade excessiva de buscas, porém esta estrutura é um pouco mais lenta
 para inserção e remoção. Isso se deve ao fato de as árvores AVL serem mais rigidamente
balanceadas.

 Arvore B
o uma árvore B é uma estrutura de dados em árvore, auto-balanceada, que armazena dados
classificados e permite pesquisas, acesso sequencial, inserções e remoções em tempo
logarítmico.
o A árvore B é uma generalização de uma árvore de pesquisa binária em que um nó pode ter mais
que dois filhos.Diferente das árvores de pesquisa binária auto-balanceadas, a árvore B é bem
adaptada para sistemas de armazenamento que leem e escrevem blocos de dados relativamente
grandes, como discos.
o foi projetada para funcionar especialmente em memória secundária como um disco magnético ou
outros dispositivos de armazenamento secundário em grande quantidades de informação. uma
Árvore B (ou uma variante) também é usada em sistemas de arquivos para permitir acesso
aleatório rápido a um bloco arbitrário em um arquivo particular. O problema básico consiste em
transformar o bloco de arquivos i em um endereço de bloco de disco (ou talvez para um cilindro-
cabeça-sector).
o As árvores B são organizadas por nós, tais como os das árvores binárias de busca, mas estes
apresentam um conjunto de chaves maior do que um e são usualmente chamados de páginas. As
chaves em cada página são, no momento da inserção, ordenadas de forma crescente e para cada
chave há dois endereços para páginas filhas, sendo que, o endereço à esquerda é para uma
página filha com um conjunto de chaves menor e o à direita para uma página filha com um
conjunto de chaves maior conforme a figura abaixo:

o Se compararmos as árvores B com suas variações podemos enumerar algumas características

importantes para a escolha de implementação destas:
 Árvores B+: A principal característica proporcionada por esta variação é o fato de
permitir o acesso sequencial das chaves por meio de seu sequence set de maneira
mais eficiente do que o realizado em árvores B. Além do mais, as páginas utilizadas em
seu index set podem conter mais apontadores para páginas filha permitindo reduzir a
altura da árvore.
o
 Arvore B+
o uma árvore B+ é uma estrutura de dados do tipo árvore derivada das árvores B, mas com uma
forma diferente de armazenamento de suas chaves.

o Figura acima mostra a rganização de uma árvore B+ em index set e sequence set. Os nós folha
são os amarelos e os azuis são os nós internos. Para manter o acesso sequencial, cada nó folha
contém apontadores para quais nós são seus predecessores ou sucessores na sequência de
chaves e como nas árvores B, as chaves estão ordenadas tanto em suas páginas internas quanto
em páginas folha.
o A organização das páginas internas ou no inglês index set é semelhante a de uma árvore B,
este, por sua vez, armazena cópias de chaves para referênciar as buscas, mas não contém as
chaves em si. Já no sequence set estão as páginas folha que contém as chaves inseridas na
árvore e funciona como uma lista encadeada permitindo o acesso sequencial ordenado às chaves
independente do index set.

o Caminhamento ou percurso em árvores binárias. Para cada nó, visite na seguinte sequência:

1. Pré-fixo (ou prefixado): RED (Raiz - Esquerda - Direita);

2. Infixo (ou infixado ou in-ordem): ERD (Esquerda – Raiz - Direita);
3. Pós-fixo (ou posfixado): EDR (Esquerda - Direita - Raiz)
2.8 Complexidade de algoritmos.
2.9 Programação recursiva.
3. Arquitetura de Dados.

 Arquitetura de dados é a estrutura dos componentes de dados de uma organização - considerados

sob diferentes níveis de abstração, suas inter-relações, bem como os princípios, diretrizes, normas
e padrões que regem seu projeto e evolução ao longo do tempo.
 A Arquitetura de Dados deve ser definida na fase de planejamento do projeto de uma nova solução
de TI que envolva persistência. Os principais tipos e fontes de dados necessários para apoiar uma
organização devem ser identificados de modo completo, consistente e compreensível. O requisito
principal nesta fase é a definição de todas as entidades de dados relevantes e não a
especificação de itens tecnológicos ou de hardware. Uma entidade de dados é qualquer coisa real
ou abstrata sobre a qual uma organização ou indivíduo deseja armazenar dados.

3.1 Modelagem de dados (conceitual, lógica e física).

 Os Arquitetos de Dados executam essa tarefa, utilizando três processos tradicionais de

Arquitetura: Conceitual, Lógico e Físico.
 Arquitetura Conceitual – Camada 2 – Modelo de Negócios
o Visão de alto nível que dá suporte ao atendimento das necessidades do negócio de uma
organização, direcionando as decisões sobre as soluções de tecnologia. Essa
perspectiva destaca os elementos envolvidos nas relações negociais e não negociais da
organização (entidades corporativas), contemplando-os em modelos independentes de
qualquer limitação tecnológica e que buscam alinhar o suporte de TI à missão
empresarial estabelecida.
 Arquitetura Lógica de Dados – Camada 3 – Modelo de Sistema / Lógico
o Uma arquitetura lógica de dados descreve com precisão as propriedades e os
relacionamentos de cada uma das entidades de dados envolvidas em um domínio
organizacional ou problema de negócio a ser resolvido com apoio de TI, compondo um
desenho detalhado a partir do qual líderes de projeto e desenvolvedores possam
trabalhar com relativa independência.
o Normalização das estruturas de dados e derivação de relacionamentos de
cardinalidade múltipla em entidades associativas são práticas inerentes a essa
abordagem, além do estreito alinhamento a um modelo corporativo previamente
concebido e de alguma preocupação com padrões de implementação da arquitetura de
banco de dados.
 Arquitetura Física de Dados – Camada 4 – Modelo de Dados Físico
o Arquitetura física de dados de um sistema de informação é parte de um Plano de Tecnologia .
Como o próprio nome indica, o plano tecnológico está focado em elementos reais e tangíveis
a serem utilizados na implementação da arquitetura de dados do projeto. Arquitetura Física de
Dados engloba "arquitetura de banco de dados", que vem a ser um esquema da tecnologia de
banco de dados utilizado para viabilizar a realização de um projeto de arquitetura de dados.
o Portanto, a sua concepção está ligada à necessidade de suportar a implementação de um
modelo que visa ao atendimento das necessidades de um negócio e que direciona as
decisões sobre as soluções de tecnologia a serem adotadas.

3.2 Criação e alteração dos modelos lógico e físico de dados.

Os sistemas de banco de dados têm um ciclo de vida para sua execução. O modelo conceitual, lógico
e físico é criado na etapa de PROJETO DO BANCO DE DADOS.

o Escala ordinal: quando as variáveis podem ser colocadas em ordem, mas não é possível quantificar a
diferença entre os resultados. Exemplo: classe social (A, B, C, D, ou E).

o Escala nominal: quando as variáveis não podem ser hierarquizadas ou ordenadas, sendo comparadas
apenas por igualdade ou diferença. Exemplos: cor dos olhos, local de nascimento ou de residência,
género, carreira, religião.
 o Escala intervalar: quando é possível quantificar as diferenças entre as medidas, mas não há um ponto
zero absoluto. Exemplo: temperatura mínima e máxima.

Um atributo é denominado ordinal quando as variáveis podem ser colocadas em ordem, mas não é possível
quantificar a diferença entre os resultados.(ERRADO)

3.3 Abordagem relacional.

 O Modelo Relacional de Banco de Dados é realizado a nível lógico, sendo ele caracterizado pela
presença das relações, em que cada uma dessas relações é conhecida também como tabela. Em
outras palavras, todos os elementos do banco de dados do modelo relacional são organizados em
conjuntos de tabelas bidimensionais
 As tabelas desse modelo são formadas pelas linhas, também conhecidas por tuplas, e pelas
colunas, as quais correspondem aos atributos. Além disso, cada campo da tabela é chamado de
valor do atributo.

 Um domínio corresponde aos possíveis valores que um valor de atributo pode assumir. Por
exemplo, o atributo “Tipo Sanguíneo” apenas pode conter determinados valores, como A, A-, B+,
B-, AB+, AB-, O+ e O-, não sendo possível que ele possua qualquer outro nome.
 Características das relações: Durante a construção de um modelo relacional, é importante que
cada uma das relações possua algumas características, como podemos ver abaixo.
o Atomicidade: A característica da atomicidade garante que todos os atributos devam ser
atômicos, únicos. Desse modo, não é possível que haja atributos multivalorados ou
compostos na modelagem relacional. Por exemplo, não é possível que o atributo “Tipo
Sanguíneo” assuma mais de um valor dentro de uma mesma tupla.
o Identidade: Essa característica determina que cada atributo possua um nome único, não
podendo, dentro de uma mesma relação, atributos com nomes iguais. Por exemplo, na
relação representada pela tabela acima, não seria possível haver duas colunas com o
atributo “CPF”. FIQUE ATENTO: Essa regra vale apenas para uma mesma relação
(tabela). Sendo assim, é possível que duas tabelas distintas possuam atributos com o
mesmo nome.
o Ordenação: Ao construir uma relação, é importante observar que a ordem das colunas
(atributos) é relevante. FIQUE ATENTO: A ordem das linhas (tuplas) não é relevante.
o Unicidade: Por fim, todas as tuplas de uma relação devem ser únicas, não podendo
haver duas duplas totalmente idênticas (duplicidade), com todos os seus valores iguais.
Sendo que, pelo menos um dos valores de atributos deve ser diferente.
 Chaves:
o Em um banco de dados relacional, é normal que haja mais de uma tabela, ou seja, mais
de uma relação. Essas tabelas podem se relacionar entre si, sendo que esse
relacionamento é realizado por meio de chaves.
o uma chave é um ou mais atributos de uma relação que permite identificar, de forma
única, uma tupla.
o Tipos de chaves:
 Chave Primaria (PK): É aquele atributo, ou um conjunto de atributos, que
diferencia uma tupla de outra, sendo esse valor único dentro de um atributo.
Ex: CPF
 Chaves alternativas (AK): São colunas únicas porém não primarias.
 Chave Estrangeira (FK): A chave estrangeira é um atributo de uma tabela
que corresponde à chave principal de outra tabela de um mesmo banco de
dados, de modo a relacioná-las. FIQUE ATENTO: Diferentemente da chave
primária, é possível que haja mais de uma chave estrangeira em uma
tabela, de modo a relacioná-la com diversas outras tabelas.
o Tipos de restrições: são exigências que são incorporadas ao banco de dados, de
modo a torná-lo consistente, íntegro e de acordo com a realidade que ele representa.
 Integridade de Domínio: Essa restrição garante que os valores de cada
atributo apenas recebam valores pertencentes ao seu domínio.
  Integridade de Chave: A restrição de chave determina que toda relação
deverá ter pelo menos uma chave. Além disso, ela garante que o valor da
chave primária de uma tabela não se repita em nenhum momento, de modo a
diferenciar cada tupla.
 Integridade de Vazio: Essa regra especifica se um atributo poderá ou não
receber um valor nulo, conhecido também como valor NULL.
 Integridade de Entidade: Essa restrição de integridade determina que
nenhum valor do atributo da chave primária receba valor nulo, pois cada tupla
precisa ser diferenciada das outras, sendo que essa diferenciação é realizada
pelos valores únicos da chave primária.
 Integridade Referencial: Essa restrição está relacionada ao atributo da chave
estrangeira, a qual é utilizada para realizar o relacionamento entre as tabelas.
Desse modo, a integridade referencial garante que o valor da chave
estrangeira em uma tabela esteja presente nos valores do atributo da chave
principal da outra tabela, podendo também assumir o valor nulo.

3.4 Normalização das estruturas de dados.

 Normalização de banco de dados é um conjunto de regras que visa, principalmente, a organização

de um projeto de banco de dados para reduzir a redundância de dados, aumentar a integridade de
dados e o desempenho.
 Para normalizar o banco de dados, deve-se examinar as colunas (atributos) de uma entidade e as
relações entre entidades (tabelas), com o objetivo de se evitar anomalias observadas na inclusão,
exclusão e alteração de registros.
 Para adequar o banco de dados, é necessário avaliar com base em cinco regras, que recebem o
nome de formas normais (FN).
 Para a maioria dos efeitos práticos, considera-se que as bases de dados estão normalizadas se
aderirem à terceira forma normal.
 MPORTANTE: O CESPE INVERTEU A ORDEM, Primeiramente, precisamos verificar se
encontramos compatibilidade com a primeira forma normal. Caso esteja tudo conforme,
analisamos se a segunda forma normal se encaixa e assim sucessivamente.
 Inicialmente, são definidos todos os atributos do documento, que estão relacionados a uma
entidade principal, atribuindo uma chave primária. Feito isso, partimos para a análise do
documento de acordo com as formas normais a seguir:
o Primeira Forma Normal (ou 1FN)
 os atributos precisam ser atômicos ou seja que as tabelas não podem ter
valores repetidos e nem atributos possuindo mais de um valor.
 Elimina atributos compostos e multivalorados
 Não possui relações aninhadas (uma tabela dentro da outra)
 Não possui colunas/grupos repetidos
 Exemplo: CLIENTE = {ID + ENDEREÇO + TELEFONES}. Porém, uma pessoa
poderá ter mais de um número de telefone, sendo assim o atributo
"TELEFONES" é multivalorado. Para normalizar, é necessário:
 Identificar a chave primária e a coluna que possui dados repetidos
(nesse exemplo "TELEFONES") e removê-los;
 Construir uma outra tabela com o atributo em questão, no caso
"TELEFONES". Mas não se esquecendo de fazer uma relação entre
as duas tabelas: CLIENTE = {ID + ENDEREÇO} e TELEFONE (nova
tabela) = {CLIENTE_ID (chave estrangeira) + TELEFONE}.

o Segunda Forma Normal (ou 2FN)

 Elimina dependências parciais em relação à chave primária.
 Primeiramente, para estar na 2FN é preciso estar também na 1FN.
 2FN define que os atributos normais, ou seja, os não chave, devem depender
unicamente da chave primária da tabela. Assim como as colunas da tabela
que não são dependentes dessa chave devem ser removidas da tabela
principal e cria-se uma nova tabela utilizando esses dados.
 Exemplo: PROFESSOR_CURSO = {ID_PROF + ID_CURSO + SALARIO +
DESCRICAO_CURSO}. Como podemos observar, o atributo
"DESCRICAO_CURSO" não depende unicamente da chave primária
"ID_PROF", mas sim somente da chave "ID_CURSO". Para normalizar, é
necessário:
 Identificar os dados não dependentes da chave primária (nesse
exemplo "DESCRICAO_CURSO") e removê-los;
 Construir uma nova tabela com os dados em questão:
PROFESSOR_CURSO = {ID_PROF + ID_CURSO + SALARIO} e
CURSOS (nova tabela) = {ID_CURSO + DESCRICAO_CURSO}.

o Terceira Forma Normal (ou 3FN).

  Elimina dependências transitivas em relação à chave (deve estar no 2FN, e
não ter dependências transitivas. Dependências transitivas ocorrem quando
um atributo não-chave depende de outro que não é chave da relação.)
 Assim como para estar na 2FN é preciso estar na 1FN, para estar na 3FN é
preciso estar também na 2FN.
 3FN define que todos os atributos dessa tabela devem ser funcionalmente
independentes uns dos outros, ao mesmo tempo que devem ser dependentes
exclusivamente da chave primária da tabela.
 3FN foi projetada para melhorar o desempenho de processamento dos banco
de dados e minimizar os custos de armazenamento.
 Exemplo: FUNCIONARIO = {ID + NOME + VALOR_SALARIO +
VALOR_FGTS}. Como sabemos o valor do FGTS é proporcional ao salário,
logo o atributo normal "VALOR_FGTS" é dependente do também atributo
normal "VALOR_SALARIO".
 Para normalizar, é necessário:
 Identificar os dados dependentes de outros (nesse exemplo
"VALOR_FGTS");
 Removê-los da tabela. Esses atributos poderiam ser definitivamente
excluídos -- e deixando para a camada de negócio a
responsabilidade pelo seu cálculo -- ou até ser movidos para uma
nova tabela e referenciar a principal ("FUNCIONARIO").

o Quarta Forma Normal (ou 4FN).

 requer que não exista nenhuma dependência multi-valorada não trivial de
conjuntos de atributo em algo mais de que um superconjunto de uma chave
candidata;
o Quinta Forma Normal (ou 5FN).
 requer que não exista dependências de joins (associações) não triviais que
não venham de restrições chave;

 Desnormalização
o A criação de novas entidades e relacionamentos podem trazer prejuízos ao serem
implementados em um SGBD.
o Devido a algumas relações excessivamente normalizadas, simples alterações no bancos de
dados podem ocasionar uma profunda mudança na coerência de dados, assim entidades e
relacionamentos devem ser desnormalizados para que o SGBD apresente um melhor
desempenho.
o Além disso, entidades podem conter ocorrências de mudanças de informações ao longo do
tempo e a desnormalização pode contribuir com a manutenção de dados sem afetá-los
drasticamente.
o Para ilustrar o conceito podemos tomar como exemplo uma entidade denominada Vendedor
com os seguintes atributos:

Código do Vendedor;
Nome do Vendedor;
Região de Vendas.

Um vendedor cadastrado pode mudar sua área de vendas mas os dados de vendas
antigas, realizadas em regiões por onde trabalhou, devem ser mantidos no banco sem
incoerência de dados. Assim, a entidade Vendedor deve ser mantida desnormalizada
para que os dados não se tornem inconsistentes.

O processo de normalização de dados consiste em encontrar informações que atinjam um plano de normalização
com as informações constantes nas tuplas adjacentes. (ERRADO) A normalização não consiste em encontrar
informações, mas sim em reestruturar as tabelas de um banco de dados de modo a reduzir a redundância de
dados e evitar anomalias.

Na elaboração de um projeto de banco de dados, é função da normalização evitar (repetição de informações)

De acordo com a normalização de entidades em bancos de dados relacionais, a entidade cujos atributos não chave
independem de outro atributo não chave está na (3FN)

Em normalização, a primeira forma normal é caracterizada por uma tabela com a existência obrigatória de uma
chave primária e uma chave estrangeira. (ERRADO)

Atributo composto é aquele que apresenta em seu conteúdo mais de um valor. (ERRADO) pois é
MULTIVALORADO.

Com o processo de normalização de tabelas, busca-se armazenar informações com redundância, para garantir o
espelhamento e segurança contra a perda de informações. (ERRADO) Sem redundância
 3.5 Integridade referencial.
3.6 Metadados.

3.7 Modelagem dimensional.

3.8 Avaliação de modelos de dados.

 Modelo de dados de objeto define um banco de dados em termos de objetos, suas

propriedades e operações. Os objetos com a mesma estrutura e comportamento
pertencem a uma classe, e as classes são organizadas em hierarquias. As operações de
cada classe são especificadas com procedimentos predefinidos, chamados métodos.
Dados como objetos, propriedades (atributos) e operações (métodos).
 Modelo relacional: Dados como uma coleção de tabelas.
 Modelo objeto-relacional : •SGBD relacional com extensões para modelos de objetos.
 Modelo XML: Estruturas de árvores hierárquicas com uso de tags.
 Modelo de rede: Registros relacionados de forma 1:N.
 Modelo hierárquico: Estruturas de árvores hierárquicas. Não usa DML

o A análise preditiva busca prever comportamentos futuros e tendências com base nos
dados conhecidos.

o A análise prescritiva é parecida com a preditiva, mas a ideia é buscar os efeitos dos
eventos futuros. É como se a preditiva fosse capaz de detectar um possível desaquecimento
do mercado no futuro, enquanto a prescritiva seria responsável por prever o impacto desse
desaquecimento nas vendas da empresa. (GABARITO)

o A análise descritiva foca no presente, visando descrever as características dos dados e

eventos correntes para subsidiar decisões de efeitos imediatos.

o A análise diagnóstica, por sua vez, visa entender as relações de causa e efeito entre
eventos. Por exemplo, pode-se cruzar fatores como dados de vacinação, saneamento básico
e higiene para entender as causas da erradicação de determinada doença em parte da
população.

O modelo de dados que possui métodos e capacidade de encapsulamento é o baseado em objetos.

Uma empresa, ao implementar técnicas e softwares de big data, deu enfoque diferenciado à análise que tem como
objetivo mostrar as consequências de determinado evento. (PRESCRITIVA)

3.9 Técnicas de engenharia reversa para criação e atualização de modelos de dados.

3.10 Linguagem de consulta estruturada (SQL).
3.11 Linguagem de definição de dados (DDL).
3.12 Linguagem de manipulação de dados (DML).

 DML (Data Manipulation Language)/Linguagem de Manipulação de Dados

o Gerenciamento de dados dentro de objetos do banco.
o é a linguagem que permite aos usuários fazer o acesso aos dados ou manipulá-los, conforme
modelo de dados apropriado. Existem basicamente dois tipos:
 DMLs procedurais requerem do usuário a especificação de qual dado é necessário
e de como obtê-lo;
 DMLs não-procedurais requerem do usuário a especificação de qual dado é
necessário sem especificar como obtê-lo. DMLs não-procedurais são usualmente
mais fáceis de aprender e usar do que DMLs procedurais. Entretanto, se um usuário
não necessita especificar como obter os dados, estas linguagens podem gerar
código não tão eficiente como o produzido por linguagens procedurais. Esta
dificuldade pode ser remediada por meio de várias técnicas de otimização.
o Uma consulta (query) é um comando requisitando a busca de uma informação. A porção de
uma DML que envolve busca de informações é chamada linguagem de consulta. Embora
tecnicamente incorreto, é comum utilizar os termos linguagem de consulta e linguagem de
manipulação de dados como sinônimos.
o São comandos DML: INSERT, DELETE e UPDATE, MERGE, BULK INSERT
 DDL (Data Definition Language DDL)/ Linguagem de Definição de Dados)
o Criação e Modificação;
o Definir a estrutura/esquema de banco de dados. {DEFINIÇÃO}
 o A estrutura de armazenagem e os métodos de acesso usados em um sistema de banco de
dados são especificados por um conjunto de definições em um tipo especial de DDL chamado
linguagem de armazenagem e definição de dados. O resultado da compilação destas
definições é um conjunto de instruções para especificar a implementação de detalhes do
esquema de banco de dados que estão normalmente escondidos dos usuários. O resultado
da compilação de comandos de uma DDL é um conjunto tabelas que são armazenadas em
um arquivo especial chamado dicionário (ou diretório) de dados.
o Um diretório de dados é um arquivo que contém metadados, ou seja, "dados sobre dados".
Este arquivo é consultado antes que os dados sejam lidos ou modificados no sistema de
banco de dados.
o São exemplos de comandos DDL: CREATE, ALTER e DROP, DISABLE TRIGGER,
TRUNCATE TABLE, etc
 DCL (Data Control Language)/Linguagem de controle de dados
o privilégios (Direitos/ permissões);
o Linguagem de controle de Dados. {CONTROLE: SEGURANÇA}. Serve para controlar a parte
de segurança do banco de dados. (Dar e retirar permissões). Comandos: GRANT, REVOKE E
DENY.
 TCL (Linguagem de Controle de Transações)
o São usados para gerenciar as mudanças feitas por instruções DML . Ele permite que as
declarações a serem agrupadas em transações lógicas.
o São os comandos para controle de transação.
o São comandos DTL: BEGIN TRANSACTION, COMMIT E ROLLBACK
 DQL: (Data Query Language):
o Possui o comando de consulta.
o SELECT é o comando de consulta
o Aqui cabe um parênteses. Em alguns livros o SELECT fica na DML em outros tem esse grupo
próprio.
 DTL - Data Transaction Language (MESMA COISA QUE TCL)
o Linguagem de Transação de Dados.
o São os comandos para controle de transação.
o São comandos DTL: BEGIN TRANSACTION, COMMIT E ROLLBACK

Um SGBD trata do acesso ao banco e pode ser executado independentemente pelo Oracle, MySQL ou
PostgreSQL; no entanto, cada SGBD utiliza DML (data manipulation language) e DDL (data definition language)
específicas. (CERTO)
3.13 Sistema Gerenciador de Banco de Dados (SGBD).
Os bancos de dados multidimensionais é que tendem a ser mais rápidos, devido à redundância. Quanto mais
normalizados (como é o caso dos relacionais), mais lentos. Os multidimensionais também podem ser normalizados,
mas o comum é serem altamente redundantes. Dados replicados facilitam no momento de gerar relatórios.

Os bancos de dados relacionais são mais eficientes, se pensarmos em eficiência como realizar algo da melhor maneira
possível, como o desempenho aliado à qualidade do processo. É por isso que são os mais utilizados atualmente. Já os
bancos de dados multidimensionais são mais rápidos e eficazes (foco no alcance dos resultados, independentemente
do aperfeiçoamento do processo), apesar de ter dimensionalidade genérica e níveis de agregação ilimitados.

Um sistema de banco de dados distribuídos é uma coleção de vários bancos de dados interconectados, que
são distribuídos fisicamente em vários locais que se comunicam por meio de uma rede de computadores. Um
modelo de banco de dados hierárquico é um modelo de dados no qual os dados são organizados em uma
estrutura semelhante a uma árvore. São coisas diferentes que a questão tentou misturar.

 As funções de SGBD são:

o Controle de redundância (o que impede a ocorrência de inconsistências entre os arquivos.)

o Restrição de acesso não autorizado;
o Armazenamento persistente;
o Oferece estruturas de armazenamento e técnicas de pesquisa para processamento eficiente de
consulta;
o Backup e recuperação;
o Múltiplas interfaces;
o Relacionamento complexo entre dados;
o Restrições de integridade (A integridade de dados se refere a acurácia, completude e
consistência dos dados armazenados em um sistema de banco de dados relacional. Isso garante
que os dados armazenados possam ser armazenados, consultados e utilizados com
confiabilidade, sendo assim dados íntegros)
o Permite deduções e ações usando regras;
 As funções do SGBD devem incluir o suporte a, pelo menos, todos os itens a seguir:
o • Definição de Dados: o SGBD deve ser capaz de aceitar definições de dados em formato fonte e
convertê-los para o formato objeto adequado.
o • Manipulação de Dados: O SGBD deve ser capaz de lidar com as requisições do usuário para
buscar, atualizar ou excluir dados existentes no banco de dados, ou para acrescentar novos dados
ao banco de dados.
 o • Otimização e Execução: O SGBD deve ser capaz de determinar um modo eficiente de
implementar a requisição.
o • Segurança e Integridade de Dados: O SGBD, ou algum subsistema chamado, pelo SGBD,
deve monitorar requisições de usuários e rejeitar toda a tentativa de violar as restrições de
segurança e integridade definidas pelo DBA.
o • Recuperação de Dados e Concorrência: O SGBD deve impor certos controles de recuperação
e concorrência.
o • Dicionário de Dados: Pode ser considerado um banco de dados isolado (mas um banco de
dados do sistema, não um banco de dados do usuário); ele contém “dados sobre os dados” – ou
seja, definições de outros objetos do sistema, em vez de somente “dados crus”.
o • Desempenho: É irrelevante dizer que o SGBD deve realizar todas as funções identificadas
anteriormente de forma tão eficiente quanto possível.
 As funções de Sistema Operacionais são:
o Gerenciamento de memória
o Gerenciamento de Processos (Escalonamento de processos)
o Gerenciamento de sistemas de arquivos
o Gerenciamento de dispositivos de Entrada e Saída

 Resumo das arquiteturas de SGBDs

o Plataformas centralizadas: Na arquitetura centralizada, existe um computador com grande
capacidade de processamento, o qual é o hospedeiro do SGBD e emuladores para os vários
aplicativos. Esta arquitetura tem como principal vantagem a de permitir que muitos usuários
manipulem grande volume de dados. Sua principal desvantagem está no seu alto custo, pois exige
ambiente especial para mainframes e soluções centralizadas.
o Sistemas de Computador Pessoal - PC: Os computadores pessoais trabalham em sistema
stand-alone, ou seja, fazem seus processamentos sozinhos. No começo esse processamento era
bastante limitado, porém, com a evolução do hardware, tem-se hoje PCs com grande capacidade
de processamento. Eles utilizam o padrão Xbase e quando se trata de SGBDs, funcionam como
hospedeiros e terminais. Desta maneira, possuem um único aplicativo a ser executado na
máquina. A principal vantagem desta arquitetura é a simplicidade.
o Banco de Dados Cliente-Servidor: Na arquitetura Cliente-Servidor, o cliente (front_end) executa
as tarefas do aplicativo, ou seja, fornece a interface do usuário (tela, e processamento de entrada
e saída). O servidor (back_end) executa as consultas no DBMS e retorna os resultados ao cliente.
Apesar de ser uma arquitetura bastante popular, são necessárias soluções sofisticadas de
software que possibilitem: o tratamento de transações, as confirmações de transações (commits),
desfazer transações (rollbacks), linguagens de consultas (stored procedures) e gatilhos
(triggers). A principal vantagem desta arquitetura é a divisão do processamento entre dois
sistemas, o que reduz o tráfego de dados na rede.
o Banco de Dados Distribuídos (N camadas): Nesta arquitetura, a informação está distribuída em
diversos servidores. Como exemplo, observe a abaixo. Cada servidor atua como no sistema
cliente-servidor, porém as consultas oriundas dos aplicativos são feitas para qualquer servidor
indistintamente. Caso a informação solicitada seja mantida por outro servidor ou servidores, o
sistema encarrega-se de obter a informação necessária, de maneira transparente para o aplicativo,
que passa a atuar consultando a rede, independente de conhecer seus servidores. Exemplos
típicos são as bases de dados corporativas, em que o volume de informação é muito grande e, por
isso, deve ser distribuído em diversos servidores. Porém, não é dependente de aspectos lógicos
de carga de acesso aos dados, ou base de dados fracamente acopladas, em que uma informação
solicitada vai sendo coletada numa propagação da consulta numa cadeia de servidores. A
característica básica é a existência de diversos programas aplicativos consultando a rede para
acessar os dados necessários, porém, sem o conhecimento explícito de quais servidores dispõem
desses dados.

 Abstração de dados

Um SGBD é composto de uma coleção de arquivos inter-relacionados e de um conjunto de programas que permitem
aos usuários fazer o acesso a estes arquivos e modificar os mesmos.

o Nível físico: o nível mais baixo de abstração descreve como os dados estão realmente
armazenados. No nível físico, complexas estruturas de dados de baixo nível são descritas em
detalhes;
 o Nível conceitual: o próximo nível de abstração descreve quais dados estão armazenados de fato
no banco de dados e as relações que existem entre eles. Aqui o banco de dados inteiro é descrito
em termos de um pequeno número de estruturas relativamente simples. Embora as
implementações de estruturas simples no nível conceitual possa envolver complexas estruturas de
nível físico, o usuário do nível conceitual não precisa preocupar-se com isso. O nível conceitual de
abstração é usado por administradores de banco de dados, que podem decidir quais informações
devem ser mantidas no BD;
o Nível de visões: o mais alto nível de abstração descreve apenas parte do banco de dados. Apesar
do uso de estruturas mais simples do que no nível conceitual, alguma complexidade perdura
devido ao grande tamanho do banco de dados. Muitos usuários do sistema de banco de dados não
estarão interessados em todas as informações. Em vez disso precisam de apenas uma parte do
banco de dados. O nível de abstração das visões de dados é definido para simplificar esta
interação com o sistema, que pode fornecer muitas visões para o mesmo banco de dados.
 Independência de dados

Os níveis de abstração de um banco de dados influenciam na habilidade de modificação de uma

definição de um esquema em um nível sem afetar a definição de esquema num nível mais alto é
chamada de independência de dados. Existem dois níveis de independência dos dados:
 Independência física de dados: é a habilidade de modificar o esquema físico sem a
necessidade de reescrever os programas aplicativos. As modificações no nível físico são
ocasionalmente necessárias para melhorar o desempenho;
 Independência lógica de dados: é a habilidade de modificar o esquema conceitual sem a
necessidade de reescrever os programas aplicativos. As modificações no nível conceitual
são necessárias quando a estrutura lógica do banco de dados é alterada (por exemplo, a
adição de contas de bolsas de mercado num sistema bancário).

A independência lógica dos dados é mais difícil de ser alcançada do que a independência física, porém
os programas são bastante dependentes da estrutura lógica dos dados que eles acessam.

Para o processamento de grandes quantidades de transações, de modo rápido e eficaz, é mais

indicado o modelo relacional de bancos de dados do que os modelos orientados a objetos ou
multidimensional. (ERRADO)

As limitações dos bancos de dados relacionais que utilizam modelo entidade-relacionamento podem
ser superadas por meio do uso de ferramentas OLAP (online analytical processing). (CERTO)

Em um sistema hierárquico, o servidor que recebe pedidos de consultas e distribui essas consultas
para origens de dados remotas é denominado servidor hierárquico. (ERRADO) correto é servidor
distribuído.

O comando GRANT é utilizado para conceder privilégios em um objeto do SGBD, ao passo que o
comando REVOKE serve para cancelar um privilégio já concedido.(CERTO)

Uma das vantagens de utilizar sistema gerenciador de banco de dados é o fato de ele realizar o
controle da redundância de dados, o que impede a ocorrência de inconsistências entre os arquivos.
(CERTO)

O comando a seguir, após sua execução, restringirá o acesso do usuário tec_infor2_tjam à tabela
processo. GRANT update, delete, insert ON processo TO tec_infor2_tjam; (ERRADO) pois GRANT:
privilégio de executar as operações UPDATE, DELETE e INSERT na tabela processo./ REVOKE:
Tira privilégios / DENY: Proíbe ações de um usuário.

Em um sistema gerenciador de banco de dados, as restrições de integridade são utilizadas para

proteger contra danos acidentais em banco de dados.

Em um sistema gerenciador de banco de dados, a chave estrangeira se caracteriza por um atributo

que existe para substituir a chave primária na entidade estrangeira. (ERRADO)

Uma consulta de um sistema gerenciador de banco de dados (SGBD) pode encontrar tendências
úteis em um conjunto de dados, ao passo que o data mining fornece operações de análises mais
abstratas, em alto nível, com o uso de algoritmos especializados. (CERTO)

Tabelas lógicas são usadas para representar o modelo hierárquico das estruturas de relação.
(ERRADO) modelo relacional

O balanceamento de carga pode ser feito por meio de appliances (hardware que implementam
funcionalidades específicas na rede) ou por software. (CERTO) É um sistema projetado para rodar
alguma(s) aplicação(ções) com melhor desempenho, menos custo e o mais importante, mais fácil.
Em uma abordagem de appliance, o hardware e software são projetados para trabalharem em
conjunto, focados na simplicidade, desempenho e redução de custos. O grande segredo está
sempre no software, começando pelo BIOS, passando sistema operacional, banco de dados Oracle
e chegando a um software gerenciador.
 Uma das técnicas utilizadas para a otimização de um banco de dados é a utilização de pool de
conexões.(CERTO) O pool de conexões é um cache de conexões de banco de dados que são
compartilhadas e reutilizadas, basicamente. Melhorando a latência e a conexão. Um Pool de
conexões reduz o número de vezes que serão necessárias a abertura de novas conexões. O
gerenciador do Pool controla conexões mantendo ativas um conjunto de conexões para cada
configuração de conexão usada. Sempre que um usuário faz uma chamada para abrir uma
conexão, o gerenciador procura verificar se existe uma conexão disponível no pool; se existir uma
conexão ativa no pool de conexão, ele devolve a conexão para o chamador em vez de abrir uma
nova conexão economizando assim recursos.

As mudanças no projeto físico do banco de dados realizadas pelo tuning não impactam o
desempenho das aplicações, em termos de redução do tempo de execução.(ERRADO)

Atributo composto é aquele que apresenta em seu conteúdo mais de um valor. (ERRADO)
Multivalorado: podem existir instâncias em que um atributo possua um conjunto de valores para
uma única entidade. Por exemplo, o atributo telefone ou e-mail pode possuir mais de um valor
atribuído. Composto: Pode ser referenciado de duas formas, hora no todo, hora em partes. Ex.:
Endereço, composto por rua, número, cidade, CEP.
Padrões a serem impostos e requisitos contraditórios a serem equilibrados são considerados como
desvantagens da abordagem de banco de dados.(ERRADO)

O modelo conceitual, que reflete uma estrutura simplificada do banco de dados, é responsável por
registrar como os dados estão armazenados no sistema de gerenciamento de banco de dados
(SGBD). ERRADO pois Lembrando que o MODELO CONCEITUAL INDEPENDE DE SGBD. A
questão retrata do MODELO FÍSICO = característica principal: como os dados estão armazenados.

É condição típica da propriedade de fechamento dos sistemas relacionais a saída de toda operação
ser do mesmo tipo de objeto que a entrada, permitindo que se escrevam expressões relacionais
aninhadas. (ERRADA) Tenha em mente que todas as operações são executadas sobre uma ou
duas tabelas e o retorno delas é sempre outra relação. Essa característica é conhecida
como fechamento."

3.14 Propriedades de banco de dados: atomicidade, consistência, isolamento e durabilidade. (ACID)

O que é uma transação? Uma transação é uma sequência de operações executadas como uma única unidade lógica
de trabalho.

ACID é um conceito que se refere às quatro propriedades de transação de um sistema de banco de dados:
Atomicidade, Consistência, Isolamento e Durabilidade.

 Atomicidade (COMMIT): Em uma transação envolvendo duas ou mais partes de informações discretas,
ou a transação será executada totalmente ou não será executada, garantindo assim que as transações
sejam atômicas. (COMMIT). A atomicidade diz que uma transação deve ser tratada em sua totalidade,
ou tudo ou nada. Então, caso ocorra um erro, todo o conjunto de alterações já realizadas deverá ser
revertido, retornando os dados e estruturas a seu estado inicial

 Consistência(ROLLBACK): A transação cria um novo estado válido dos dados ou em caso de falha
retorna todos os dados ao seu estado antes que a transação foi iniciada. (ROLLBACK)

 Isolamento(LOCK/CONCORRENCIA TRANSACOES): Uma transação em andamento mas ainda não

validada deve permanecer isolada de qualquer outra operação, ou seja, garantimos que a transação
não será interferida por nenhuma outra transação concorrente. (ISOLATE) O controle da concorrência
gerencia quem vai acessar um recurso em um determinado momento, fazendo com que ocorra o
isolamento das transações. Para isso, pode ser que um dos usuários que está tentando acessar
determinado dado seja “bloqueado” de realizar a operação até que a transação do outro se complete.
Portanto, não se pode dizer que a manipulação de um determinado dado por mais de um usuário ao
mesmo tempo está garantida. 

 Durabilidade(LOGGING): Dados validados são registados pelo sistema de tal forma que mesmo no
caso de uma falha e/ou reinício do sistema, os dados estão disponíveis em seu estado correto. (LOG)

A consistência dos dados é obtida evitando a redundância. Possuir vários arquivos diferentes torna mais
difícil atualizar esse dado, pois a alteração em um arquivo não é refletida nos demais. O objetivo é alterar um
arquivo e refletir nos demais. Para manter a consistência os dados é melhor não ter redundâncias não
controladas. É exatamente por isso que os arquivos foram substituídos por banco de dados.

Por ser considerada uma ação atômica, a proteção do banco de dados deve ser realizada ao nível de tabela, não
sendo possível, por exemplo, realizar a proteção de uma tupla inteira ou de parte da tupla.(ERRADO) Na
terminologia do modelo relacional, uma linha é chamada de tupla, um cabeçalho de coluna é chamado de atributo, e
a tabela é chamada de relação. A questão quer saber se é possível realizar o bloqueio de parte de uma linha ou de
uma linha inteira na tabela. A resposta é SIM, é possível.
 (CESPE) Atomicidade, consistência, isolamento e durabilidade são propriedades fundamentais que devem ser
apresentadas por uma transação de banco de dados. (CERTO) ACID

(CESPE) A atomicidade é a propriedade que assegura que as atualizações relacionadas e dependentes ocorram
dentro dos limites da transação ou nenhuma atualização será efetivada no banco de dados. (CERTO)

A respeito de SGBDs, assinale a opção correta. Conforme o princípio da atomicidade, caso ocorra erro em
determinada transação, todo o conjunto a ela relacionado será desfeito até o retorno ao estado inicial, como se a
transação nunca tivesse sido executada.

As funções de um sistema de gerenciamento de banco de dados (SGBD) incluem transformar e apresentar dados,
controlar o acesso de multiusuário e prover interfaces de comunicação do banco de dados

3.15 Independência de dados.

3.16 Transações de bancos de dados.

 Um gatilho ou trigger é um bloco de comandos Transact-SQL que é automaticamente executado

quando um comando INSERT, DELETE ou UPDATE for executado em uma tabela do banco de dados.
São usados para realizar tarefas relacionadas com validações, restrições de acesso, rotinas de
segurança e consistência de dados; desta forma estes controles deixam de ser executados pela
aplicação e passam a ser executados pelos triggers em determinadas situações, como:
o mecanismos de validação envolvendo múltiplas tabelas;
o criação de conteúdo de uma coluna derivada de outras colunas da tabela;
o realização de análises e atualizações em outras tabelas com base em alterações e/ou
inclusões da tabela atual.
 As 7 restrições mais importantes, definidas por Edgar Frank Cood:
o Restrição de Chave ou Unicidade: Impede que uma chave primária se repita. Um campo
chave primária diferencia de forma única os registros (linhas) de uma relação (tabela).
o Restrição de Domínio: Define o conjunto de valores possíveis ou permitidos que um campo
pode ter.
o Integridade de vazios: Verifica se um campo pode ou não receber valor NULL. Sub-item da
integridade de domínio.
o Integridade Referencial: Uma chave estrangeira de uma relação tem que coincidir com uma
chave primária da sua tabela "pai", ao qual a chave estrangeira se refere. Ou seja, não só
deve existir o atributo (campo), como também, o valor referenciado.
o Integridade da coluna: Determina os valores aceitos para a respectiva coluna.
o Integridade definida pelo utilizador: A integridade definida pelo usuário permite definir
regras comerciais que não se encaixam em outras categorias de integridade. Todas as
categorias de integridade oferecem suporte à integridade definida pelo usuário.
o Violação da integridade referencial: Existe violação da integridade referencial quando a
chave externa não coincide com a chave primária da sua tabela “pai”.

Em um SGBD, o trigger pode substituir a instrução que o originou, sendo a instrução original
descartada e apenas o trigger executado. (CERTO)
Princípio da Não Volatilidades - > os dados não mudam com o tempo (MESMO COM
ALTERACOES EVOLUTIVAS DO SGBD)
replicação inclui a duplicação de transações e um processo constante de
atualização e sincronização entre o ambiente original e suas cópias.

3.17 Melhoria de performance de banco de dados.

A finalidade de um sistema de bancos de dados é simplificar e facilitar o acesso aos dados.

 Visões do usuário de alto nível ajudam-nos a atingir isto . Os usuários do sistema não devem preocupar-se
desnecessariamente com os detalhes físicos da implementação do sistema. Contudo, o principal fator na
satisfação de um usuário com o sistema de bancos de dados é seu desempenho.
 Se o tempo de resposta a uma solicitação é muito longo, o valor do sistema é diminuído. O desempenho de um
sistema depende da eficiência das estruturas de dados usadas para representar os dados no banco de
dados. E, se for o caso, a vantagem não deve ser dada apenas entre espaço e tempo, mas também eficiência de
um tipo de operação versus outra.

 Select é a operação em um banco de dados em que um conjunto de tuplas (linhas) é selecionada em uma relação
(tabela) a partir de uma condição. Ex.: suponha que eu deseje selecionar no meu banco de dados os funcionários
 que ganhem mais de 5000. Para esse fim, utilizo o select que me devolverá todas as tuplas da relação que
satisfaçam a condição imposta.

 A seletividade é definida como a razão entre o número de registros (tuplas) que satisfazem a condição e o número
total de registros (tuplas) no arquivo (relação). Ou seja, quanto mais tuplas forem selecionadas entre todas
possíveis, mais tempo o SGBD precisará para processar. Logo, a eficiência é inversamente proporcional ao
número de tuplas selecionadas, pois quanto mais tuplas, mais demorado é o processamento.

Para otimizar a seleção em um SGBD, é utilizado o grau de seletividade da tabela, sendo a

eficiência de seleção diretamente proporcional ao número obtido. (ERRADO) Inversamente
proporcional

3.18 SQL

Uma cláusula JOIN em SQL, correspondente a uma operação de junção em álgebra relacional, combina colunas de
uma ou mais tabelas em um banco de dados relacional. Ela cria um conjunto que pode ser salvo como uma tabela ou
usado da forma como está.

Um JOIN é um meio de combinar colunas de uma (auto-junção) ou mais tabelas, usando valores comuns a cada uma
delas. O SQL padrão ANSI especifica cinco tipos de JOIN: INNER JOIN, LEFT JOIN, RIGHT JOIN, FULL JOIN e
CROSS JOIN e SELF JOIN.

 INNER JOIN (MERGE/COMBINADA) EQUIVALE (=) (NÃO ACEITA NULO)

SELECT <select_list>
FROM Tabela A
INNER JOIN Tabela B
ON A.Key = B.Key

A cláusula INNER JOIN compara cada linha da tabela A com as linhas da tabela B para
encontrar todos os pares de linhas que satisfazem a condição de junção. Se a condição de
junção for avaliada como TRUE, os valores da coluna das linhas correspondentes das tabelas A
e B serão combinados em uma nova linha e incluídos no conjunto de resultados.

INNER OUTER JOIN EQUIVALE (+)=

 LEFT JOIN

SELECT <select_list>
FROM Tabela A
LEFT JOIN Tabela B
ON A.Key = B.Key
Retorna todos os registros da tabela esquerda (A) e os registros correspondentes da tabela
direita (B).
Para cada linha da tabela A, a consulta a compara com todas as linhas da tabela B. Se um par
de linhas fizer com que a condição de junção seja avaliado como TRUE, os valores da coluna
dessas linhas serão combinados para formar uma nova linha que será incluída no conjunto de
resultados.

Se uma linha da tabela “esquerda” A não tiver nenhuma linha correspondente da tabela “direita”
B, a consulta irá combinar os valores da coluna da linha da tabela “esquerda” A com NULL para
cada valor da coluna da tabela da “direita” B que não satisfaça a condição de junto (FALSE).

Em resumo, a cláusula LEFT JOIN retorna todas as linhas da tabela “esquerda” A e as linhas
correspondentes ou valores NULL da tabela “esquerda” A.

 RIGHT JOIN

SELECT <select_list>
FROM Tabela A
RIGHT JOIN Tabela B
ON A.Key = B.Key
 Retorna todos os registros da tabela direita (B) e os registros correspondentes da tabela
esquerda (A).
A RIGHT JOIN combina dados de duas ou mais tabelas. A RIGHT JOIN começa a selecionar dados da
tabela “direita” B e a corresponder às linhas da tabela “esquerda” A.

A RIGHT JOIN retorna um conjunto de resultados que inclui todas as linhas da tabela “direita” B, com ou sem
linhas correspondentes na tabela “esquerda” A. Se uma linha na tabela direita B não tiver nenhuma linha
correspondente da tabela “esquerda” A, a coluna da tabela “esquerda” A no conjunto de resultados será nula
igualmente ao que acontece no LEFT JOIN.

 FULL OUTER JOIN

SELECT <select_list>
FROM Tabela A
FULL JOIN Tabela B
ON A.Key = B.Key
Retorna todos os registros quando houver uma correspondência na tabela esquerda ou direita.
A cláusula FULL JOIN retorna todas as linhas das tabelas unidas, correspondidas ou não, ou seja, você pode
dizer que a FULL JOIN combina as funções da LEFT JOIN e da RIGHT JOIN. FULL JOIN é um tipo de
junção externa, por isso também é chamada junção externa completa.

Quando não existem linhas correspondentes para a linha da tabela esquerda, as colunas da tabela direita
serão nulas. Da mesma forma, quando não existem linhas correspondentes para a linha da tabela direita, a
coluna da tabela esquerda será nula.

retorna todas as tuplas, independente de correspondência. (UNIÃO)

 CROSS JOIN

SELECT <select_list>
FROM Tabela A
CROSS JOIN Tabela B
A cláusula CROSS JOIN retorna todas as linhas das tabelas por cruzamento, ou seja, para cada linha da
tabela esquerda queremos todos os linhas da tabelas direita ou vice-versa. Ele também é chamado de
produto cartesiano entre duas tabelas. Porém, para isso é preciso que ambas tenham o campo em
comum, para que a ligação exista entre as duas tabelas.

Para entender melhor, pense que temos um banco de dado, onde temos uma tabela FUNCIONÁRIO e uma
tabela CARGO, assim poderíamos ter vários cargos para um único FUNCIONÁRIO, e usando o CROSS
JOIN podemos trazer todos os CARGOS de todos os FUNCIONÁRIOS.

 SELF JOIN.

Tipo de Tabelas/Arquivos de Banco de dados:

 Heap file (arquivos não ordenados) Arquivos de Pilha.--> Os dados contidos no arquivo não possuem
qualquer ordem, ou seja, estão dispostos conforme a ordem de entrada
 Sorted file (arquivo ordenado) Arquivo Sequência --> Registros de arquivos são mantidos ordenados de
acordo com a chave de ordenação. A pesquisa será facilitada se a chave de pesquisa coincidir com a chave
de ordenação, caso contrário não há vantagem na ordenação.
 Hashed file (arquivo de acesso direto) --> O arquivo tem uma chave de pesquisa associado a ele, que
pode ser a combinação de um ou mais campos. Esta chave permite um acesso rápido ao registro desejado.

3.19 Bancos de dados NoSQL.

NoSQL: 
o simplicidade de projeto
o escalonamento "horizonal" mais simples para clusters de máquinas (o que é um problema
para bancos de dados relacionais) e controle mais refinado sobre a disponibilidade.
o A proposta dos bancos de dados não-relacionais não é substituir os bancos de dados
relacionais, mas serem utilizados nos casos em que é necessária uma maior
flexibilidade na estrutura do banco de dados.
o As estruturas de dados usadas pelos bancos de dados NoSQL (e.g., chave-valor, coluna
larga, grafo ou documento) são diferentes daquelas usadas por padrão em bancos de dados
relacionais, tornando algumas operações mais rápidas em NoSQL. 
o Algumas vezes as estruturas de dados usadas por bancos de dados NoSQL também são
vistas como "mais flexíveis" que tabelas de bancos de dados relacionais.
 o O NoSQL é uma solução alternativa para os bancos de dados tradicionais e serve para
dados semi-estruturados (p/ facilitar o entendimento, lembre-se que o FACEBOOK utiliza
esse esquema)
o Importante lembrar que o Termo NoSQL (not only SQL) se refere a não utilizar somente SQL,
ou seja, podem ser acessados por aplicações que usam SQL também.
o Bancos NoSQL são comumente usados em áreas de conhecimento como Data Science. As
maiores diferenças entre bancos NoSQL e relacionais é que bancos relacionais trabalham
com tabelas, enquanto em Bancos NoSQL todos os dados constam no mesmo registro.
o Big Data está em ascensão e é matéria prima dos Bancos de Dados NoSQL. Para entender
os NoSQLs, é importante saber que a linguagem SQL sempre foi usada para tratamento de
dados em bancos relacionais, ao longo dos anos.
o Em suma, a principal diferença entre os bancos de dados relacionais e NoSQL é que o
segundo permite maior velocidade, flexibilidade e escalabilidade ao armazenar e acessar
dados não estruturados.
o Tipos de Banco de Dados NoSQL:
o Modelo Colunas: No modelo colunas, o banco de dados faz armazenamento em linhas
particulares de tabela. Esse esquema é o perfeito oposto dos bancos relacionais, que
armazenam conjuntos de dados em uma única linha. Exemplos clássicos do modelo de
colunas são os bancos Hbase e Cassandra;
o Modelo Grafos: Armazena dados na forma de grafo. Isto é, aqui os dados são
dispostos no formato de arcos conectados por arestas. Podemos definir como um
conjunto de linhas conectadas por vértices também. O modelo de grafos é vantajoso
frente à pesquisas complexas, pois a latência e a performance promete ser menor do
que no modelo chave-valor, por exemplo.Um exemplo prático disso é o banco Neo4j.
o Modelo Chave-Valor: Em chave-valor, nós temos um banco que é formado por
conjuntos de chaves, que por sua vez são acompanhados de valores como tabelas
hash. A estrutura chave-valor também é bem flexível e própria para armazenamento de
big data. É interessante também frisar que esse formato é altamente disponível.
Exemplos práticos são REDIS e MemcacheD.
o Modelo Documento: Neste modelo, os dados são “documentos”. É o esquema de
armazenamento do MongoDB, por exemplo. Esse modelo é altamente flexível e não
carece de colunas pré montadas, como é o caso do Cassandra. Esse modelo é
especialmente eficiente para tratar dados não estruturados, já que uma única coleção
pode contar com grupos de dados (documentos) de diversos formatos diferentes.
o Diferença SQL e NoSQL

NoSQL são bancos de dados que não aceitam expressões SQL e devem ser armazenados na nuvem.
(ERRADA)

Para uma empresa que necessite implantar uma base de dados altamente escalável, com grande
desempenho e cujo esquema de dados seja flexível, de modo que suporte constantes mudanças de campos
e valores armazenados, a melhor opção é uma base de dados NoSQL (CERTO)

Em banco de dados Nosql, mais especificamente o modelo chave/valor, o conceito de consistência é

aplicável apenas às operações em uma única chave, já que essas operações são a obtenção, a gravação
 ou a exclusão em uma única chave.(CERTO)

Os Sistemas de Gerenciamento de Banco de Dados (SGBD) foram afetados pelas demandas trazidas pelo
Big Data. Uma das formas de tratar essas demandas são os Sistemas de Gerenciamento de Banco de
Dados Distribuídos (SGBDD), nos quais os dados podem estar armazenados em vários servidores,
conectados por uma rede de computadores. Um SGBDD que usa softwares middleware, de forma que os
SGBDs que o compõem estejam fracamente acoplados, é conhecido como (FEDERADO) é possível
desenvolver software de middleware para acessar vários bancos de dados autônomos pré-existentes,
armazenados sob SGBDs heterogêneos. Isso leva a um SGBD federado (ou sistema multibanco de dados),
em que os sistemas participantes são fracamente acoplados e possuem um certo grau de autonomia local.
Muitos SGBDDs utilizam arquitetura cliente/servidor.

2015 Um banco de dados em grafos está diretamente relacionado a um modelo de dados já estabelecido, o
que viabiliza recomendar a utilização para os casos em que a interconectividade dos dados é tão importante
quanto os próprios dados.(certa)

2015 Como forma de permitir as buscas em documentos semiestruturados, um banco de dados NoSQL do
tipo orientado a documentos armazena objetos indexados por chaves utilizando tabelas de hash
distribuídas. (Errada)

2016 - Em um banco de dados NoSQL do tipo grafo, cada arco é definido por um identificador único e
expresso como um par chave/valor. (errada)

2016 Os bancos de dados NoSQL não permitem a atualização de seus dados, por serem orientados a
documentos e(ou) coleções. (errada)

3.20 Integração dos dados (ETL, Transferência de Arquivos e Integração via Base de Dados).

o ETL
o ETL, do inglês Extract Transform Load (Extrair Transformar Carregar), são ferramentas de software
cuja função é a extração de dados de diversos sistemas, transformação desses dados conforme regras
de negócios e por fim o carregamento dos dados geralmente para um Data Mart e/ou Data Warehouse,
porém nada impede que também seja para enviar os dados para um determinado sistema da
organização.
o A extração e carregamento são obrigatórios para o processo, sendo a transformação/limpeza é opcional
o É considerada uma das fases mais críticas do Data Warehouse e/ou Data Mart.
o A maioria dessas fontes tendem a ser bancos de dados relacionais ou arquivo de texto (texto plano),
mas podem existir outras fontes. Um sistema ETL tem que ser capaz de se comunicar com as bases de
dados e ler diversos formatos de arquivos utilizados por toda a organização. Essa pode ser uma tarefa
não trivial, e muitas fontes de dados podem não ser acessadas com facilidade.
o O processo de Extração, Transformação e Carregamento (Extract, Transform, Load – ETL) é um
processo que envolve:
 Extração de dados de fontes externas:
 A maioria dos projetos de data warehouse consolidam dados extraídos de
diferentes sistemas de origem. Cada sistema pode também utilizar um formato ou
organização de dados diferente. Formatos de dados comuns são bases de dados
relacionais e flat files (também conhecidos como arquivos planos), mas podem
incluir estruturas de bases de dados não relacionais, como o IMS ou outras
estruturas de dados, como VSAM ou ISAM. A extração converte para um
determinado formato para a entrada no processamento da transformação.
 Transformação dos dados para atender às necessidades de negócios:
 Aplica uma série de regras ou funções aos dados extraídos para derivar os dados a
serem carregados. Algumas fontes de dados necessitarão de muito pouca
manipulação de dados. Em outros casos, podem ser necessários um ou mais de
um dos seguintes tipos de transformação:
o Seleção de apenas determinadas colunas para carregar (ou a seleção de
nenhuma coluna para não carregar)
o Tradução de valores codificados (se o sistema de origem armazena 1
para sexo masculino e 2 para feminino, mas o data warehouse armazena
M para masculino e F para feminino, por exemplo), o que é conhecido
como limpeza de dados.
o Codificação de valores de forma livre (mapeando “Masculino”,“1” e “Sr.”
para M, por exemplo)
o Derivação de um novo valor calculado (montante_vendas = qtde *
preço_unitário, por exemplo)
o Junção de dados provenientes de diversas fontes
 o Resumo de várias linhas de dados (total de vendas para cada loja e para
cada região, por exemplo)
o Geração de valores de chaves substitutas (surrogate keys)
o Transposição ou rotação (transformando múltiplas colunas em múltiplas
linhas ou vice-versa)
o Quebra de uma coluna em diversas colunas (como por exemplo,
colocando uma lista separada por vírgulas e especificada como uma
cadeia em uma coluna com valores individuais em diferentes colunas).

 Carregamento dos dados:

 A fase de carregamento consiste na colocação dos dados no Data Warehouse
(DW). Dependendo das necessidades da organização, este processo varia
amplamente. Alguns data warehouses podem substituir as informações existentes
semanalmente, com dados cumulativos e atualizados, ao passo que outro DW (ou
até mesmo outras partes do mesmo DW, conhecidos como Data Mart) podem
adicionar dados a cada hora. A temporização e o alcance de reposição ou
acréscimo constituem opções de projeto estratégicas que dependem do tempo
disponível e das necessidades de negócios. Sistemas mais complexos podem
manter um histórico e uma pista de auditoria de todas as mudanças sofridas pelos
dados.
o ETL é importante, pois é a forma pela qual os dados são efetivamente carregados no Data Warehouse.
Este artigo assume que os dados são sempre carregados no DW, contudo, ETL pode ser aplicado a um
processo de carregamento de qualquer base de dados.
o Processamento em Paralelo: Existem três tipos primários de paralelismos implementados em
aplicações de ETL:
 Dados: Pela divisão de um único arquivo sequencial em arquivos de dados menores para
permitir acesso em paralelo.
 Pipeline: Permitindo a execução simultânea de diversos componentes no mesmo fluxo de
dados. Um exemplo seria a leitura de um valor no registro 1 e ao mesmo tempo juntar dois
campos no registro 2.
 Componente: A execução simultânea de múltiplos processos em diferentes fluxos de dados
no mesmo job. A classificação de um arquivo de entrada concomitantemente com a de
duplicação de outro arquivo seria um exemplo de um paralelismo de componentes.
o Os três tipos de paralelismo estão normalmente combinados em um único job.
o Uma dificuldade adicional é assegurar que os dados que estão sendo carregados sejam relativamente
consistentes. Uma vez que múltiplas bases de dados de origem apresentam diferentes ciclos de
atualização (algumas podem ser atualizados em espaços de alguns minutos, ao passo que outras
podem levar dias ou semanas), um sistema de ETL pode precisar reter determinados dados até que
todas as fontes sejam sincronizadas. Analogamente, quando um warehouse tem que ser reconciliado
com o conteúdo de um sistema de origem ou com o livro razão, faz-se necessária a implementação de
pontos de sincronização e reconciliação.

o ELT
o ELT é a modernização do processo de ETL.
o Ao contrário do ETL, o ELT é um processo mais ágil para o carregamento e o processamento de dados,
pois inverte a ordem das etapas de transformação de dados da abordagem tradicional de ETL. (ou seja
carregamento será posterior da transformação)
o Na abordagem de ELT, ao contrário da abordagem de ETL, a transformação de dados ocorre logo
após a coleta e o carregamento das informações em um repositório de dados centralizado, e não antes
(Com isso, é possível transformar dados brutos em dados modelados dentro de um data warehouse.)
o reduz consideravelmente o tempo de carregamento de dados, permitindo que a transformação de
dados seja feita por analytics engineers ou analistas de dados, sem a dependência de profissionais
altamente técnicos como desenvolvedores e engenheiros de dados.
o Na prática da implementação do ELT, portanto, os engenheiros de dados focam apenas nas  etapas de
extração e carregamento, atribuições características de sua área de atuação enquanto a
responsabilidade da transformação de dados fica nas mãos de profissionais próximos à empresa que
conhecem as regras de negócio, como analistas, cientistas de dados e analytics engineers

Comparado ao ETL, o ELT apresenta vantagens como tempos menores de carregamento e de transformação
de dados, e, consequentemente, menor custo de manutenção. (CERTO)

Em primeiro lugar, devemos pensar em quando e como coletar os dados que serão armazenados em
um Data Warehouse. podemos trabalhar com dois tipos de arquiteturas diferentes: uma arquitetura
controlada pela fonte para a coleta de dados, onde as fontes de dados transmitem novas
informações, seja continuamente (quando ocorre o processamento da transação), periodicamente (à
noite, por exemplo) ou uma arquitetura controlada por destino, onde o depósito de dados envia
periodicamente solicitações para novos dados às fontes.
 3.21 Banco de dados em memória.
3.22 Qualidade de dados e gestão de dados mestres e de referência.
3.23 Data Lakes e Soluções para Big Data.

Big Data
o Big Data é o termo em Tecnologia da Informação (TI) que trata sobre grandes conjuntos de dados que
precisam ser processados e armazenados, o conceito do Big Data se iniciou com 5 Vs : Velocidade, Volume
e Variedade, Valor, Veracidade
o Volume dos Dados: Gigabytes para Terabytes e agora estamos falando de Petabytes
o Velocidade: Existência de um alto fluxo de dados na entrada.
o Variedade: poderia ser considerado como Any Data (qualquer dado), capacidade de capturar e
analisar dados estruturados e não estruturados(Varias fontes)
o Valor: Agregar conhecimento
o Veracidade: Veridicos, verdadeiros
o Big Data pode ser definido como um conjunto de técnicas capazes de se analisar grandes quantidades de
dados para a geração de resultados importantes que, em volumes menores, dificilmente seria possível.
o necessitam de ferramentas especiais para comportar o grande volume de dados que são encontrados,
extraídos, organizados, transformados em informações que possibilitam uma análise ampla e em tempo
hábil.
o Há diversas ferramentas para Big Data:
o Hadoop:
 enorme capacidade de processamento de dados em larga escala.
 100% código aberto e executado hardware comum
 Hadoop consiste em quatro partes:
 Sistema de arquivos distribuídos do Hadoop: Comumente conhecido como
HDFS, é um sistema de arquivos distribuídos compatível com largura de
banda de escala muito alta.
 MapReduce: um modelo de programação para o processamento de Big Data.
permite o processamento de dados massivos em um algoritmo paralelo e
distribuído.
 YARN: é uma plataforma usada para gerenciar e agendar os recursos do
Hadoop na infraestrutura do Hadoop.
 Bibliotecas: Para ajudar outros módulos a trabalhar com o Hadoop.

o Apache Spark
 O ponto principal desta ferramenta de código aberto é que preenche as lacunas do
Apache Hadoop em relação ao processamento de dados. Curiosamente, o Spark pode
lidar com dados em lote e em tempo real. Como ele processa dados na memória, isso
acontece muito mais rapidamente que o processamento em disco tradicional. Este é
realmente um ponto positivo para os analistas que lidam com certos tipos de dados para
obter resultados mais rápidos.
 O Apache Spark é flexível para trabalhar com o HDFS e com outros armazenamentos de
dados, por exemplo, com o OpenStack Swift ou o Apache Cassandra. Também é muito
fácil executar o Spark em um único sistema local para facilitar o desenvolvimento e os
testes.
 O Spark Core é o coração do projeto e facilita muitas coisas como:
 Transmissão de tarefas distribuídas;
 Agendamento e
 Funcionalidade de E / S.
 O Spark é uma alternativa ao MapReduce do Hadoop, ele pode executar trabalhos 100
vezes mais rápido que o MapReduce do Hadoop.
o Apache Storm
 O Apache Storm é uma estrutura distribuída em tempo real para o processamento
confiável do fluxo de dados ilimitado. Essa ferramenta suporta qualquer linguagem de
programação e seus recursos exclusivos são:
 Escalabilidade maciça;
 Tolerância ao erro;
 Abordagem “falhe rápido, reinicialização automática”;
 O processo garantido de cada tupla;
 Escrito em Clojure;
 Executa na JVM;
 Suporta topologia de gráfico acrílico direto (DAG);
 Suporta vários idiomas e
 Suporta protocolos como JSON.
 As topologias de tempestade podem ser consideradas semelhantes ao trabalho do
MapReduce. No entanto, no caso do Storm, é o processamento de dados de fluxo em
tempo real, em vez de ser em lote. Com base na configuração da topologia, o
planejador Storm distribui as cargas de trabalho para os nós. E ele pode interoperar com
 o HDFS do Hadoop através de adaptadores, se necessário, que é outro ponto que o
torna útil como uma ferramenta de Big Data de código aberto.
o Cassandra
 é um banco de dados de tipo distribuído NoSql para gerenciar um grande conjunto de
dados nos servidores.
 Essa é uma das melhores ferramentas de Big Data que processa principalmente
conjuntos de dados estruturados, que fornece serviço altamente disponível, sem ponto
único de falha. Além disso, possui certos recursos que nenhum outro banco de dados
relacional e qualquer banco de dados NoSQL podem fornecer. Esses recursos são:
 Disponibilidade contínua como fonte de dados;
 Desempenho escalável linear;
 Operações simples;
 Nos centros de dados, fácil distribuição destes;
 Pontos de disponibilidade na nuvem;
 Escalabilidade e Atuação.
 A arquitetura Apache Cassandra não segue a arquitetura mestre-escravo e todos os nós
desempenham o mesmo papel. Ele pode lidar com vários usuários simultâneos nos data
centers, portanto, adicionar um novo nó não importa no cluster existente, mesmo no
período de atividade.
o RapidMiner
 O RapidMiner é uma plataforma de software para atividades de ciência de dados e
fornece um ambiente integrado para:
 Preparação de dados;
 Aprendizado de máquina;
 Mineração de texto;
 Análise preditiva;
 Aprendizagem profunda;
 Desenvolvimento de aplicações e
 Prototipagem.
 Oferecem suporte a diferentes etapas do aprendizado de máquina, como:
 Preparação de dados;
 Visualização;
 Análise preditiva;
 Validação do modelo;
 Otimização;
 Modelagem estatística;
 Avaliação e
 Desdobramento, desenvolvimento.
 O RapidMiner segue um modelo de cliente / servidor em que o último pode estar
localizado no local ou em uma infraestrutura de nuvem. É escrito em Java e fornece uma
GUI para projetar e executar fluxos de trabalho, além de poder fornecer 99% de uma
solução analítica avançada
o MongoDB
 é um banco de dados NoSQL de código aberto compatível com várias plataformas e com
muitos recursos embutidos. É ideal para empresas que precisam de dados rápidos e em
tempo real para tomar decisões instantâneas. E também para usuários que desejam
experiências baseadas em dados. É executado na pilha de software MEAN, aplicativos
NET e plataforma Java.
o Linguagem R
o Neo4j
 BD baseado em grafos/ gráficos
 Segue a estrutura fundamental do banco de dados de gráficos, que é a relação de
dados interconectada dos nós. Ele mantém um padrão de valor-chave no
armazenamento de dados.

CRISP DM:
o CRISP DM é a abreviação de Cross Industry Standard Process for Data Mining que, trazendo para o
português, pode ser entendida como processo padrão da indústria cruzada para mineração de dados. Essa é
uma metodologia capaz de transformar os dados da empresa em conhecimento e informações de
gerenciamento.
o A metodologia CRISP DM define o ciclo de vida do projeto, dividindo-o em seis etapas, que vamos
conhecer agora:
o Entendimento do problema: A primeira coisa a ser feita é entender de fato qual o problema a ser
resolvido, buscando todos os detalhes sobre o impacto dele na empresa e quais os objetivos em
relação ao trabalho.
o Compreensão dos dados: Essa etapa consiste em organizar e documentar todos os dados que
se encontram disponíveis. É aqui que começa de fato o trabalho de mineração de dados, pois o
profissional deve ser capaz de identificar quais são os dados importantes para a resolução do
 problema. Nesse momento, o lado investigativo deve entrar em campo, para que os dados revelem
problemas, soluções e tendências dos negócios.
o Preparação dos dados: Agora que os dados já foram identificados, documentados e analisados, é
hora de aplicar a parte técnica de análise deles. Agora, serão preparadas as databases e definidos
os formatos e questões técnicas da análise. Nessa etapa, é feita a escolha dos dados que serão
trabalhados e de como eles serão cruzados para resolver o problema da empresa.
 Método de Binning: É um processo de suavização de dados, usado para minimizar os
efeitos de pequenos erros de observação. Os valores dos dados originais são divididos
em pequenos intervalos conhecidos como compartimentos e, em seguida, são
substituídos por um valor geral calculado para esse compartimento. Pode-se substituir
todos os dados em um segmento por seus valores médios ou limites.
o Modelagem: É nesta fase que são aplicadas de fato as técnicas de Data Mining, com base nos
objetivos identificados no primeiro momento.A partir de agora, a mineração de dados pode ser
associada a análises preditivas, para que a empresa prepare-se para o futuro, resolvendo a
questão principal.
o Avaliação: serão acompanhados os resultados em relação aos objetivos e também à aplicação
dos conhecimentos obtidos com o Data Mining. Isso pode ser feito por meio de reuniões, onde os
dados e insights são apresentados para os envolvidos nas tomadas de decisão.
 big data analytic: softwares capazes de tratar dados para transformá-los em
informações úteis às organizações. analisar o que já existe e o que está por vir,
apontando novos caminhos.
o Implementação dos modelos na empresa: Aqui, é a hora da verdade, onde tudo que foi obtido
de conhecimento dos dados são entregues de forma a ser aplicada. A partir disso, podem ser
mudados os processos dentro da organização e criados novos produtos — tudo com base em
dados, garantindo, assim, o sucesso dos negócios.
o Diferença KDD (Knowledge Discovery in Databses) e CRISP
o O KDD (Knowledge Discovery in Databases) tem uma proposta diferente do CRISP DM. Enquanto
este é um método ágil focado na resolução de problemas, o KDD caracteriza-se pela obtenção de
conhecimento.
o KDD é realizado em cinco etapas, que são:
 Seleção: consiste em escolher quais dados terão uma relevância maior durante as
etapas seguintes, de modo que o conhecimento seja gerado;
 Pré-processamento: aqui todas as inconsistências dos dados devem ser removidas;
 Formatação ou transformação: os dados obtidos no pré-processamento são
rearranjados, de modo a estarem o mais organizados possível para a etapa seguinte;
 Mineração dos dados: é aqui que os dados se transformam em informação útil. Isso
porque ocorrem os processos de leitura e interpretação dos registros;
 Interpretação dos dados: as informações obtidas na mineração de dados transformam-
se em conhecimento, que será aplicado, por exemplo, em pesquisas e otimizações.
o

Data Lake
o O Data Lake é um grande repositório capaz de armazenar dados estruturados, semi-estruturados e não-
estruturados, assim como um método para organizar grandes volumes de dados de diversos formatos e
de diversas fontes diferentes.
o Com os data lakes, você tem uma visão não refinada dos dados. Ou seja, os dados são brutos, é
porque eles ainda não foram processados para uma finalidade específica.
o Os dados em um data lake são definidos só depois de serem consultados. Os cientistas de dados
podem acessar os informações brutas quando necessário por meio de modelagem preditiva ou
ferramentas analíticas mais avançadas.
o Todos os dados são mantidos quando você usa um data lake: nada é removido ou filtrado antes do
armazenamento. Os dados podem ser analisados em breve, no futuro ou nunca. Eles também podem
ser usados várias vezes para diferentes finalidades, ao contrário de quando os dados são refinados
para um fim específico e o reaproveitamento é mais difícil.
o Diferença Data Lake x warehouse
o ambos são repositórios de big data
o data warehouse fornece um modelo de dados estruturados projetado para a geração de
relatórios portanto antes de colocar os dados em um data warehouse, é necessário processá-
los.
o data lake armazena dados brutos não estruturados que não têm uma finalidade definida. 
o Refinar os dados antes de armazená-los em um data warehouse pode ser complicado e
demorado: isso pode levar meses ou até mesmo anos no processo e impedindo a coleta
imediata. Com um data lake, você coleta os dados instantaneamente e depois descobre uma
finalidade para eles.
o data warehouses costumam ser mais utilizados por usuários de negócios que sabem com
antecedência quais dados são necessários para a geração de relatórios periódicos.
 o á os data lakes são mais usados por analistas e cientistas porque eles realizam pesquisas por
meio dos dados, que precisam receber análises e filtros mais avançados para se tornarem
úteis.
o Geralmente, os data lakes e data warehouses também têm hardwares de armazenamento
diferentes. Os data warehouses são caros. Já os data lakes custam menos porque têm
hardware comum (apesar do grande tamanho).
o As principais vantagens em contar com essa solução, são:
o Espaço de armazenagem de dados elevado;
o Compatibilidade com qualquer formato de dados ;
o Permite a disponibilidade dos dados a qualquer momento;
o Pode ter acessos simultâneos;
o Entrega os dados brutos, facilitando sua análise por qualquer pessoa da empresa por meio de
outras plataformas;
o Alto poder de organização;

Big Data surgiu a partir da necessidade de manipular um grande volume de dados e, com isso,
novos conceitos foram introduzidos, como o Data Lake, que (é projetado para armazenar dados de
diversas fontes e formatos, não havendo a necessidade da definição de um esquema de dados para
inserir novos itens.)

Assim como o Hadoop foi desenvolvido para possibilitar o processamento em lote de grande
volume de dados, também surgiram tecnologias com suporte ao processamento em tempo
real de Big Data, como o (SPARK)

Big data caracteriza-se, principalmente, por volume, variedade e velocidade, o que se justifica
devido ao fato de os dados serem provenientes de sistemas estruturados, que são maioria, e de
sistemas não estruturados, os quais, embora ainda sejam minoria, vêm, ao longo dos anos,
crescendo consideravelmente.(ERRADO) pois TIPOS DE DADOS PRESENTES NO BIG DATA

DADOS ESTRUTURADOS: 20%: Mesma estrutura de representação, descrições e

atributos, previamente projetados. Organizados e gravados em banco de dados.
organizados em blocos semânticos (blocos do mesmo significado).

DADOS SEMIESTRUTURADOS: Geralmente não mantidos em banco de dados.

possuem organização bastante heterogênea. menos rígidos que os estruturados quanto
ao valor a ser manipulado. Ex XML, OWL etc.

DADOS NÃO-ESTRUTURADOS: 80%: Não possuem estrutura definida. EX: textos,

vídeos, imagens. não possuem descrição para sua estrutura nem mesmo implicitamente
Os Dados não Estruturados representam a maioria dos dados no Big Data
I O volume de dados é uma característica importante de Big Data. II Em Big Data, a qualidade do
dado não tem importância, porque a transformação dos dados não impacta os negócios. III A
característica de velocidade de entrada dos dados impacta o modelo de processamento e
armazenamento. IV A variedade dos dados não é característica intrínseca nos fundamentos de Big
Data. Estão certos apenas os itens I e III

De maneira geral, big data não se refere apenas aos dados, mas também às soluções tecnológicas
criadas para lidar com dados em volume, variedade e velocidade significativos.(CERTO)

Hive e Sqoop são subprojetos do Hadoop destinados a queries e data warehousing,

respectivamente. (ERRADO)
Hive é um framework para aplicar técnicas de data warehousing que realiza o gerenciamento dos
dados armazenados no HDFS e provê uma linguagem de consulta baseada em SQL42
Sqoop é uma ferramenta que tem o o propósito de fazer ingestão de dados, seu foco é em transferir
dados entre o Hadoop e bancos de dados relacionais ou mainframes. O seu nome é uma
abreviação de “SQL to Hadoop”.(Migrar /importar/exportar dados para de um banco de dados
relacional)

A fase de implantação do CRISP-DM (cross industry standard process for data mining) só deve
ocorrer após a avaliação do modelo construído para atingir os objetivos do negócio.(CERTO)

A mineração de textos utiliza técnicas diferentes da mineração de dados, tendo em vista que os
textos representam um tipo específico de dado. (ERRADO) A mineração de textos utiliza das
mesmas técnicas da mineração de dados.

A descoberta de conhecimento em bases de dados, ou KDD (knowledge-discovery), é a etapa

principal do processo de mineração de dados. (ERRADO) A Mineração de Dados faz parte de um
processo muito maior de descoberta de conhecimento chamada KDD .

Os principais métodos de mineração de dados:

Rede Neurais
 Árvore de Decisão
Algoritmos Genéticos
Lógica Fuzzy (Difusa)
Estatística

Os fatores críticos de sucesso da análise de Big Data incluem uma sólida infraestrutura
de dados, além de ferramentas analíticas e pessoal habilitado para lidar com elas.
(CERTO)

3.24 Diferenciação entre bancos relacionais, multidimensionais, documentos e grafos.

4. Computação em Nuvem.
4.1 Conceitos de computação em nuvem: benefícios, alta disponibilidade, escalabilidade, elasticidade,
agilidade, recuperação de desastres.

 Segundo Microsoft: A computação em nuvem é a prestação de serviços de computação, incluindo

servidores, armazenamento, bancos de dados, redes, software, análises, inteligência e muito mais
pela Internet (“a nuvem”) para oferecer inovação mais rápida, recursos flexíveis e economias de
escala.
 Segundo AWS: A computação em nuvem é a entrega sob demanda de energia de computação,
armazenamento de banco de dados, aplicativos e outros recursos de TI por meio de uma
plataforma de serviços em nuvem via Internet, com preços pré-pagos.
 Cloud computing refere-se à utilização da memória e da capacidade de armazenamento e cálculos
de computadores e servidores compartilhados e interligados por meio de internet, seguindo o
princípio da computação em grade (grid computing).
 Os benefícios dos serviços de nuvem são:
 Disponibilidade (Availability) – Porcentagem de tempo que um sistema responde
adequadamente às solicitações, expressa como uma porcentagem ao longo do tempo. A
disponibilidade de 99,99% por exemplo, implica até 4 minutos por mês de tempo de
inatividade de um sistema.
 Alta disponibilidade (High Availability) – Ser resiliente quando algum componente do sistema
falha. Os principais provedores de nuvem (Azure, AWS, GCP) têm vários data centers
espalhados pelo mundo. Os dados e o códigos armazenados na nuvem são copiados para
mais de um data center. Se algo acontecer com um data center, os dados poderão ser
recuperados de outro data center.
 Escalabilidade (Scalability) – Capacidade de um sistema aumentar sua capacidade
“facilmente” quando um sistema atinge sua capacidade máxima.
 Elasticidade (Elasticity) – Capacidade de um sistema crescer automaticamente quando a
capacidade máxima é atingida e diminuir automaticamente para minimizar o desperdício
quando não houver grande utilização dos recursos.
 Tolerância a falhas (Fault Tolerance) – Capacidade de tolerar falhas de hardware em seu
sistema, necessárias para obter alta disponibilidade.
 Recuperação de desastres (Disaster Recovery) – Capacidade de recuperar-se de uma
grande falha dentro de um período de tempo aceitável, com uma quantidade aceitável de
dados perdidos.
 Benefícios comerciais da nuvem:
o Agilidade (Agility) – Capacidade de responder às mudanças “rapidamente” com base
nas mudanças no mercado ou no ambiente computacional.
o Economias de Escala (Economies of Scale) – Cloud é um pool compartilhado de
máquinas e serviços. À medida que o número de clientes aumenta, os provedores de
nuvem podem reduzir os custos ou aumentar a qualidade dos serviços.
o Despesas de capital (Capital Expenditure – CapEx) – Quantia (geralmente grande) de
dinheiro investida em um ativo (edifício, computadores, equipamentos). Geralmente
gasto antecipadamente e retorna os lucros lentamente ao longo do tempo.
o Despesas Operacionais (Operating Expenditure – OpEx) – Quantia gasta “todos os
meses” como despesa operacional. Espera-se que você ganhe mais dinheiro com
receita do que gasta.
o Modelo baseado no consumo (Consumption-Based Model | pay-as-you-go) – Os
usuários da nuvem pagam apenas pelo que precisam, pela duração que precisam.

4.2 Componentes centrais da arquitetura em nuvem:

 distribuição geográfica, regiões, zonas de disponibilidade, subscrições, grupos de gestão,
recursos.
 Características dos serviços na nuvem:
o Disponibilidade de acordo com sua necessidade (Escalabilidade)
o Acessível de qualquer lugar conectado à net (virtualidade)
o Permite deslocamento de dados de uma estrutura para outra (computação
resiliente)
o Preços de serviços de acordo com uso (baixo custo de manutenção)
 o Intensidade de uso de acordo com a necessidade (elasticidade de
processamento, armazenamento, banda etc.)
o Uso intenso de tecnologia de segurança.
 Vantagens:
o Acesso distribuído ao serviço / sistema
o Facilitação de colaboração
o Sem preocupação com hardware
o Uso apenas de software que utiliza
o Atualização de software facilitada
o Uso de backup (copias em ambiente fisicamente seguros e geograficamente
distantes
 Desvantagens:
o Maior risco à privacidade
o Segurança de informação
o Controle de dados por terceiros
o Indisponibilidade de servidor

4.3 Características gerais de identidade, privacidade, conformidade e segurança na nuvem.

4.4 Gestão de custos na nuvem: modelos de faturamento, gerenciamento de subscrições e contas,

definição de preço.

 As categorias de operação de cloud computing são:

o SaaS – Software as a Service (Software como serviço). Usado por USUARIO
FINAL.
o PaaS – Platform as a Service (Plataforma como serviço): Voltados para ambiente
corporativos. Elas incluem recursos como aplicativos, interfaces, BDs,
armazenamento e testes/desenvolvimento de aplicativos operados à distância para
uso local de empresas. Análise de dados ou BI são cenários comuns a este tipo de
serviços de PaaS. Utilizados por desenvolvedores de aplicações
o IaaS – Infraestructure as a Service (Infraestrutura como serviço). Os servidores,
softwares e equipamentos de rede são terceirizados. Quem contrata tem facilidade
de gerenciamento e flexibilidade de operação. Utilizados por arquiteto de
infraestrutura.

4.5 IoT.

 A Internet das Coisas (IoT, Internet of Things) é um conjunto de dispositivos que estão
conectados à Internet.

4.6 Infrastructure as Code (IaC) e Automação.

BLOCO 3:
1. Gerenciamento de Produtos de Software.

o O gerenciamento de produtos de software (às vezes também conhecido como gerenciamento de

produtos digitais ou, no contexto certo, apenas gerenciamento de produtos ) é a disciplina de
construção, implementação e gerenciamento de software ou produtos digitais , levando em
consideração considerações de ciclo de vida e um público.
o É a disciplina e o processo de negócios que governa um produto desde seu início até o mercado
ou entrega e serviço ao cliente, a fim de maximizar a receita
o

1.1 Gerenciamento de produtos com métodos ágeis: Scrum E Kanban.

1.2 Modelos e técnicas de gestão de portfólio (SAFe): características, objetivos, aplicabilidade e benefícios.

2. 2 Análise de Dados e Informações.

2.1 Dado, informação, conhecimento e inteligência.
 Gestão da Informação, mais especificamente sobre Dado, Informação, Conhecimento e Inteligência.
 Dados:
 Dados são registros, fatos brutos coletados que não possuem qualquer significado, contexto ou nexo
com a realidade.
 Um dado pode ser uma letra, um número, uma palavra, bem como conjuntos de números e vocábulos
desorganizados, o qual não transmite nenhuma informação ou conhecimento.
 Informação:
 Quando os dados são estruturados, organizados, processados, contextualizados ou interpretados, há a
geração de informação.
 Assim, quando um ou um conjunto de dados são tratados, de modo a transmitir uma mensagem dentro
de um contexto real, temos as informações, as quais são providas de propósito, significado e
relevância, podendo ser utilizadas pelo ser humano durante a tomada de decisão, por meio da sua
compreensão e análise.
 Conhecimento:
 O conhecimento é gerado através da habilidade em analisar as informações encontradas. Em outras
palavras, o conhecimento acontece quando as informações são integradas e processadas, sendo que,
através da análise do todo, podem ser encontradas determinadas conclusões.
 O conhecimento pode ser dividido em dois tipos, o tácito e o explícito.
 O conhecimento tácito é considerado como sendo aquele gerado através da experiência e
não por meio de palavras escritas. Ele é adquirido através da prática, sendo ele empírico e
de difícil transmissão. Ex: Experiencia da cozinheira (sem a receita)
 Já o conhecimento explícito é aquele codificado, formal, baseado na teoria e transmitido
de forma sequencial e estruturada, geralmente por meio da escrita. Ele pode ser
facilmente transmitido ou explicado. Um exemplo é a receita escrita pela cozinheira onde
você consegue cozinhar uma receita sem a presença da cozinheira.

 O conhecimento pode ser convertido e transferidos em 4 formas:
o Socialização (Tácito em Tácito): duas pessoas conversando, trocando
experiências, ideias e informações.
o Combinação (Explícito em Explícito): conhecimento explícito de duas fontes,
sendo eles combinados, de modo a gerar outra fonte de conhecimento explícito.
o Externalização (Tácito em Explícito): conhecimento tácito de uma pessoa, o
qual estava internalizado, foi extraído e transformado em conhecimento
explícito, por meio da escrita.
o Internalização (Explícito em Tácito): quando uma pessoa adquire
conhecimento por meio da leitura de documentos escritos, como sites, artigos
ou livros, há a conversão do conhecimento explícito, presente nos documentos
codificados, em tácito, pois ele é absorvido pelo leitor.

 Inteligência:
 A inteligência é a aplicação do conhecimento, ou seja, quais ações podem ser tomadas
através do conhecimento que foi adquirido.
 A inteligência é considerada uma qualidade puramente humana, sendo ela baseada na
experiência, bem como na intuição. Diferentes pessoas, de posse do mesmo
conhecimento, podem tomar diferentes decisões, pois cada indivíduo possui a sua
inteligência.

2.2 Conceitos, fundamentos, características, técnicas e métodos de business intelligence (BI).

o BI não é ferramenta. Não é abrir uma ferramenta de visualização ou integração, não se

resume ao uso de softwares como Tableau, Pentaho, QlikView, Power BI ou qualquer outro
que estiver na moda.
o BI nada mais é que um processo. Um conjunto de técnicas e conceitos. Trata de entregar a
informação certa para a pessoa certa no tempo certo.
o Esse processo passa por coleta, organização e análise dos dados, elaboração de
relatórios ou dashboards e todo o acompanhamento e atualização. Esses são os
fundamentos, a base para entender como tudo funciona.
 o BI dá suporte à tomada de decisão. É para você poder olhar uma tela com um dashboard e
em 5 segundos ter a visão completa da empresa, tendo a capacidade de tomar uma decisão
de negócio inteligente, com base em fatos.
o O BI mede o desempenho passado para prever o futuro. Pensa assim: você não faz
cirurgia de coração com um médico sem ter evidências de que ele é um bom profissional, ou
sem alguns dados como sua formação e o sucesso de suas cirurgias passadas.

2.3 Mapeamento de fontes de dados.

2.4 Dados estruturados e dados não estruturados.

 DADOS ESTRUTURADOS:
o Tem uma estrutura totalmente predefinida, detalhada e padronizada com um
esquema EXPLÍCITO. Com uma busca e processamento bem mais fácil. Exemplo:
banco de dados relacionais e tradicionais.
o Os dados estruturados possuem metadados que descrevem previamente o
esquema e as características dos dados. Enquanto os dados não estruturados não
são facilmente entendidos.
o Dados estruturados são planilhas eletrônicas e tabelas em um banco de dados.

 DADOS NÃO ESTRUTURADOS:

o Tem uma estrutura sem predefinição com alta dificuldade na busca e
processamento. Exemplo: imagens, áudios, vídeos e arquivos de textos.
o Não possuem um formato ou uma organização predefinida , tornando muito mais
difícil sua coleta, processamento e análise.
o Não possuem descrição para a sua estrutura, nem mesmo em forma implícita

 DADOS SEMI ESTRUTURADOS: Estrutura é definida a posteriori. Isso significa que, na

maioria das vezes, a estrutura está implícita nos próprios dados e pode ser extraída após
uma análise, uma investigação. Exemplo: documentos XML.

O dicionário de dados é uma das principais ferramentas para administração dos dados corporativos.
Por meio da Engenharia Reversa, pode se armazenar os modelos de dados, as estruturas de dados,
seus relacionamentos e toda a documentação necessária para garantir facilidade na localização e
manipulação dos dados.

2.5 Conceitos de OLAP e suas operações.

o OLAP – Online Analytical Processing

o OLAP é um software cuja tecnologia de construção permite aos analistas de negócios,
gerentes e executivos analisar e visualizar dados corporativos de forma rápida, consistente e
principalmente interativa.
o A funcionalidade OLAP é inicialmente caracterizada pela análise dinâmica e
multidimensional dos dados consolidados de uma organização permitindo que as atividades
do usuário final sejam tanto analíticas quanto navegacionais.
o As ferramentas OLAP (do inglês, Online Analytical Processing) são geralmente
desenvolvidas para trabalhar com banco de dados desnormalizados. Essas ferramentas
são capazes de navegar pelos dados de um Data Warehouse, possuindo uma estrutura
adequada tanto para a realização de pesquisas como para a apresentação de informações.
o Tipo de navegação OLAP:
 drill Across: ocorre quando o usuário pula um nível intermediário dentro de uma
mesma dimensão. Por exemplo, a dimensão tempo é composta por ano, semestre,
trimestre, mês e dia. A operação Drill Across é executada quando o usuário passa
de ano direto para trimestre ou mês;
 drill Down: ocorre quando o usuário aumenta o nível de detalhe da informação,
diminuindo a granularidade (A granularidade determina quais os tipos de consultas
podem ser feitas no DW. Ela influencia diretamente na velocidade do acesso às
informações e no volume de dados armazenados.
 drill Up: é o contrário do Drill Down, ocorre quando o usuário aumenta a
granularidade, diminuindo o nível de detalhamento da informação;
 drill Throught: ocorre quando o usuário passa de uma informação contida em
uma dimensão para uma outra (Dimensão diferente) Por exemplo: Inicia na
dimensão do tempo e no próximo passo analisa a informação por região;
 dlice and Dice: Ele serve para modificar a posição de uma informação, trocar
linhas por colunas de maneira a facilitar a compreensão dos usuários e girar o
cubo sempre que tiver necessidade.

Assinale a opção que indica a forma de navegação por nível de granularidade em um

 modelo de dados dimensional em que os detalhes de uma informação sejam recuperados
de outra estrutura. (DRILL-THROUGHT)

2.6 Conceitos de data warehouse.

o O Data Warehouse é quem otimiza todo o processo de consultas e análises em grandes volumes
de dados, sendo o ponto central para a tomada de decisão.
o O Data Warehouse é quem centraliza os dados da empresa e elimina os ruídos de comunicação
entre os departamentos, deixando tudo unificado.
o E assim você consegue ter uma visão total, e não só parcial, do que realmente está acontecendo.
Por isso ele tem um grande enfoque na consistência e confiabilidade dos dados, além de ser
modelado pensando na consulta rápida dos dados, e não na inserção ou alteração deles.
o Com o Data Warehouse, e com os dados já transformados em informação, você consegue
controlar os níveis de acesso, garantindo que cada pessoa receba os relatórios de que precisa – e
evitando que veja os que não deve.
o O Data Warehouse é a parte mais crítica nos projetos de BI. E por isso é tão necessário ter uma
boa habilidade de modelagem de Data Warehouse, porque se você errar nessa parte, vai
comprometer o ETL, a construção dos cubos, a própria criação dos dashboards e, principalmente,
vai fazer com que erre também na entrega da tomada de decisão.

o
o Arquitetura de Business Intelligence (figura acima) está dividida em diversas fases:
o DATA SOURCE:
 Os dados começam no data source, que são as planilhas, ERPs, CRMs etc.
Os data source são geralmente compostos por dados estruturados ou
semiestruturados, onde não se pode ter redundância, e são modelados para a
inserção e edição dos dados, não para a consulta.
o DATA INTEGRATION
 Os dados são retirados das fontes de origem, transformados de forma que
façam sentido juntos e inseridos no Data Warehouse.
 Ex: ETL/EL-T
o DATA STORAGE:
 é onde entra o Data Warehouse e onde temos nossas informações de fato.
 É importante avisar que mesmo o Data Warehouse vindo em um estágio
depois do ETL, você deve se preocupar com ele antes. O ETL só vai poder ser
feito depois que o Data Warehouse estiver pronto, porque é ele quem define
de que forma os dados vão ser transformados e onde deverão ser inseridos.
 Uso da técnica de modelagem dimensional para modelar o warehouse
o DATA ANALYSYS
 Ex: Cubo / OLAP
o DASHBOARD/VISUALIZATION
o Métricas de Datawarehouse:

OLTP

Banco de dados relacional;

dados individualizados;
dados presentes - passado próximo;
registra simultaneamente poucos dados;
orientado ao processo.

OLAP

Banco de dados multidimensional;

dados sumarizado;
dados históricos ;
registro de múltiplos dados simultâneos;
orientado ao negócio.

As três leis dos dados abertos:

 Se o dado não pode ser encontrado ou indexado na Web, ele não existe;(acesso aos
dados e disponibilidade)
Se o dado não está disponível num formato aberto e legível por máquina, ele não
pode ser reutilizado; (reuso e distribuição)
Se dispositivos legais não permitem que ele seja compartilhado, ele não é útil.
(possibilidade de participação universal das pessoas)

(TCE-RJ/2021/CESPE) As três normas fundamentais que compõem o conceito de

dados abertos são: disponibilidade e acesso; reuso e distribuição; e participação
universal. Certo

(TCE/SC/2016/CESPE) Dados abertos são os dados de livre utilização, reutilização e

redistribuição, exigindo-se, no máximo, créditos à autoria e compartilhamento pela
mesma licença. Certo

2.7 Técnicas de modelagem e otimização de bases de dados multidimensionais.

 Modelagem dimensional é uma técnica de projeto lógico normalmente usada para data
warehouses que contrasta com a modelagem entidade-relacionamento.
 É a única técnica viável para bancos de dados que devem responder consultas em um data
warehouse.
 a modelagem entidade-relacionamento é muito útil para registro de transações e para fase de
administração da construção de um data warehouse, mas deve ser evitada na entrega do sistema
para o usuário final.
 A modelagem multidimensional foi definida sobre dois pilares:
o Dimensões Conformados: diz respeito a entidade que servem de perspectivas de análise
em qualquer assunto da organização. Uma dimensão conformada possui atributos
conflitantes com um ou mais data-marts do data warehouse.
o Fatos com granularidade única: entende-se a unidade de medida de um indicador de
desempenho.
 Esse tipo de modelagem tem dois modelos:
o Modelo Estrela (Star Schema): Mais simples de entender, nesse modelo todas as
dimensões relacionam-se diretamente com a fato.

o Modelo Floco de Neve (Snow Flake): Visa normalizar o banco, esse modelo fica mais
complicado do analista entender, nele temos dimensões auxiliares.
o O Snowflake também é projetado para suportar tomada de decisão, mas economizando
espaço em disco. Para o Star Schema, o Snowflake é apenas mais um tipo de
dimensão.
o Embora o Star Schema ocupe mais espaço em disco, ele é mais fácil de implementar e
acabou sendo mais utilizado porque além de hoje em dia o espaço ser muito barato, ele
permite entregar projetos por pedacinhos. Você pode criar um assunto ou departamento
em uma estrela para só depois projetar outro, e assim por diante.

o - ESTRELA -> NÃO NORMATIZADA (DADOS)

o - FLOCO DE NEVE -> NORMATIZADA (DADOS) O Modelo Snowflake realmente
acrescenta graus de normalização às tabelas de dimensões, eliminando redundâncias.
No entanto, como os dados estão normalizados, as consultas são mais complexas e a
obtenção de informações será menos eficientes do que no Modelo Estrela.

• Toda modelagem dimensional possui dois elementos imprescindíveis: as tabelas Fatos e as

tabelas dimensões. Ambas são obrigatórias e possuem característica complementares dentro de
um Data Warehouse.
• Tabelas Fatos:
o Possui o caráter quantitativo das informações descritivas armazenadas nas Dimensões
(Medidas, Métricas, Quantidades).
 o É onde estão armazenadas as ocorrências do negócio (eventos) e possui
relacionamento de “muitos para um” com as tabelas periféricas (Dimensão).
o A tabela fato armazena os fatos, evento, ocorrências;
o A tabela de fatos armazena métricas (ou fatos) que podem ser utilizados para medir o
desempenho do negócio;
o Existem 6 tipos de tabelas FATOS:
 Fato transacional: mais comuns, usam métricas aditivas que pode se somar
por todas dimensões;
 Fato agregada: Função acelerar o desempenho (reduzir o tempo) das
consultas, consolidam Coisas;
 Fato consolidada: Diferente da tabela agregada serve para consolidar duas
fatos (no processo ETL as duas tabelas fatos são carregadas e misturadas);
 Fato snapshot periódico: baseada no tempo, seja data, dia, semana ou hora
(pega um momento periódico, tira uma fotografia e insere no fato);
 Fato de snapshot acumulado: também é uma fotografia, entretanto em mais
de um momento;
 Fato sem fato: Fato sem métricas, serve para fazer intersecção de
dimensões, cruzamento para comparações, pode inserir fatos fakes sem
conteúdo apenas para cruzamento entre dimensões.

• Tabelas Dimensões: são os descritores dos dados oriundos da Fato.

o Possui o caráter qualitativo da informação e relacionamento de “um para muitos” com a
tabela Fato.
o É a Dimensão que permite a visualização das informações por diversos aspectos e
perspectivas.
o Quem armazena as dimensões e os atributos são as tabelas dimensões;
o Quem armazena os valores descritivos do Banco de dados também são as tabelas
dimensões.
o Hierarquia existe apenas nas dimensões.
o As dimensões armazenam 3 coisas:
 A Surrogate Key (PK da Dimensão; é chave artificial incremental)
 A Natural Key (PK do dado na origem ou legado)
 Os atributos
• Outros conceitos importantes:
o Hierarquia: Hierarquia é o conjunto de atributos que possui uma ordem lógica do maior
ao menor nível. A hierarquia balanceada, que é a mais utilizada, é qualquer
classificação que tenha como base as relações entre superiores e dependentes. Por
exemplo, do avô ao neto ou do general ao soldado. Ela requer sempre uma relação de
pai-filho, onde o superior pode ter zero, um ou muitos dependentes, mas os
dependentes devem ter um e um único superior. A hierarquia existe apenas nas
dimensões, porque a métrica é só um valor, e quem vai dizer se esse valor está
correspondendo a um determinado nível da hierarquia é o atributo. O comum é existir
apenas uma hierarquia por dimensão, mas pode existir múltiplas se for necessário.
o Grão: O grão, também chamado de detalhe, é o menor nível da hierarquia da
dimensão. É a informação base, o menor detalhe da informação. Em uma dimensão de
tempo, nós podemos ter uma hierarquia com ano, mês e dia. O dia é o menor nível, isso
é o grão.
Em uma dimensão com diretoria, gerência, departamento e pessoa, a pessoa é o menor
nível de detalhamento. Ele é o nível mais atômico, o mais detalhado, e é no nível mais
atômico em que será armazenada a informação, sem a oportunidade de “descer”
mais um nível.
Você precisa identificar qual o menor dado necessário, porque quanto menor for o
nível do grão, mais ETL terá para fazer e mais demorado será , então não adianta
colocar sempre o menor possível para tentar evitar o erro.

o 4 Métricas da data warehouses:

o Aditivas: São as métricas que permitem operações matemáticas como soma e
subtração por todas as dimensões. Dentro da fato há diversas linhas, e as métricas
aditivas devem poder somar todas elas. É obvio, todas podem ser somadas se eu quiser,
mas ela precisa fazer sentido. Alguns exemplos de métricas aditivas:
o Quantidade de vendas
o Valor da venda (se não for calculado)
o Quantidade de colaboradores
o Quantidade de demissões
o Quantidade de admissões
Todas essas métricas que podem ser somadas independentemente de onde estiverem
cruzando. Ela tem que fazer um cruzamento completo e perfeito na linha da fato, então a
métrica precisa fazer sentido com cada uma das dimensões sozinhas.
 o Derivadas: É uma métrica calculada, uma métrica que você calcula para ter um
segundo número. Esse cálculo é sempre em cima de métricas que já estão na fato,
não no que está no legado. São métricas que já estavam na fato e que são
calculadas, criando uma nova métrica, que chamamos de derivada.
Ela pode ser armazenada diretamente na fato ou calculada em tempo de execução
nos cubos.
o Semi-aditivas: Extrato bancário. Uma visão geral sobre essa fato: temos a
dimensão de tempo, de cliente e de agência. Também temos algumas métricas:
entrada, saída, saldo e a diferença percentual entre as entradas e saídas. A Entrada
na conta corrente é uma métrica aditiva (soma de todas entradas). Mesmo conceito
se aplica na Saida (soma de todas saídas). E a métrica SALDO é o cálculo da
diferença entre Entrada – Saída da movimentação do DIA. A métrica semi-aditiva
pode ser somada por todas as dimensões exceto a tempo onde você só vai
conseguir somar pela tempo se colocar um filtro que diga que ele só pegue o último
registro.
Saldo de estoque e saldo bancário, quando representado de forma monetária, são
métricas semi-aditivas bem comuns, porque são aditivas em todas as dimensões,
exceto na tempo.
o Não-aditivas: São métricas tipo percentual, algum cálculo feito em tempo de
execução, que não podem ser somadas por nenhuma dimensão. O ideal é salvar as
métricas que levam àquela não-aditiva e deixar para que ela seja calculada na
ferramenta de BI.

Na modelagem dimensional de dados, as tabelas fato armazenam eventos de negócio enquanto as

tabelas dimensão representam entidades de negócio. (CERTO)

Tendo como referência inicial esse modelo, e considerando que, para representar a quantidade de
faltas em valores inteiros, seja inserida em FATO_FREQUÊNCIA a métrica qtd_faltas, em que se
possam realizar drill up e a soma de seus valores ao longo do tempo, julgue o item a seguir, à luz
dos conceitos afetos à modelagem dimensional.
A métrica qtd_faltas é aditiva (CERTO)

A tabela fato não deve possuir atributos do tipo numérico.(ERRADA) A tabela fato possui atributos
do tipo numérico.

A tabela agregada é utilizada para reduzir o tempo de acesso de uma consulta ao banco de dados.
(CERTO)

No modelo estrela, os dados são modelados em tabelas dimensionais, ligadas a uma tabela fato;
uma tabela dimensão armazena o que tiver ocorrido, e a tabela fato contém as características de
um evento.(ERRADO). Está no contrário ou seja, tabela fato contém os eventos, as medidas ou os
fatos ocorridos. Já as dimensões armazenam as características que descrevem o evento.

A tabela agregada é composta de atributos e contém a descrição do negócio. (ERRADA) Uma

tabela agregada é um fato. A agregação dos registros da tabela fato, como ocorre na tabela fato de
Snapshot Periódico, é uma técnica que visa reduzir a quantidade de registros nessa tabela,
melhorando a performance de consulta.

Na modelagem multidimensional, é possível haver mais de uma tabela fato no mesmo modelo. A
tabela fato expressa a relação N:M (muitos-para-muitos) entre as dimensões, que, por sua vez,
implementam a visão e a interface do usuário ao DataWarehouse. (SIM) Sim, pois, nesse caso,
estamos diante do modelo chamado constelação (mais de uma tabela fato no mesmo modelo).

A tabela fato tem uma cardinalidade de mapeamento de um para um com cada tabela dimensão.
(ERRADO) 1:N

A cardinalidade do relacionamento entre tabelas dimensão e tabelas fato é de 1 para 1.(ERRADA)

QUESTÃO CERTA: A tabela fato deve conter atributos numéricos, visando proporcionar dados para
uma análise de atividades da empresa.

De forma bem simplificada, a tabela fato vai apresentar o que realmente ocorreu, o resultado da
análise, através de medidas. Para isso, é fundamental que contenha atributos numéricos, que
expressem quantidades e valores.

QUESTÃO ERRADA: A tabela fato possui pelo menos 4 atributos numéricos, além das chaves
estrangeiras.
 Não há número específico de atributos.

QUESTÃO ERRADA: A cardinalidade de relacionamento da tabela fato para as tabelas dimensão é

de um para um.

Geralmente, a cardinalidade de relacionamento da tabela fato para as tabelas dimensão é de 1:N.

QUESTÃO ERRADA: Em uma tabela fato, pode haver diferentes granularidades entre as métricas,
sendo as métricas não aditivas, em regra, de menor granularidade que as aditivas ou as
semiaditivas.

Cada proposta de granularidade da tabela de fato resultada em uma tabela física separada,
diferentes granularidades não devem ser misturadas na mesma tabela fato.

Segundo Inmon-1997 (pág. 364): “o nível de detalhe contido em uma unidade de dados. Quanto
mais detalhe houver, mais baixo o nível de granularidade. Quanto menos detalhe houver, mais alto
o nível de granularidade”.

Ou seja:

– MAIOR O GRÃO -> MENOS DETALHE

– MENOR O GRÃO -> MAIS DETALHE

QUESTÃO ERRADA: Em um data warehouse, cada linha em uma tabela fato corresponde a uma
medida, representada por um valor aditivo, em que necessariamente essas medidas não
compartilham a mesma granularidade.

A questão está errada porque as linhas compartilham a mesma granularidade, e a medida pode ser
aditiva, semi-aditiva ou não aditiva.

As tabelas fato são compostas obrigatoriamente por uma chave primária composta pelas chaves
primárias das tabelas que contêm as descrições do fato, as de dimensão. Além desta chave
composta uma tabela fato contêm medidas que variam de numéricas ou sem medida e neste
contexto tempos três tipos de tabela fato:

QUESTÃO CERTA: Ao se modelar uma tabela-fato, deve-se considerar que a chave primária é
composta e que a dimensão tempo sempre será parte integrante dessa chave.

Tempo é uma dimensão importante que TODOS os DW’s devem suportar.

Na modelagem multidimensional utilizada em data warehouses para se prover melhor desempenho,

a tabela fato central deve relacionar-se às suas dimensões por meio da chave primária oriunda da
fonte de dados original. O valor dessa chave deve ser idêntico ao da fonte, para que tenha valor
semântico e garanta que o histórico das transações seja mantido.  (ERRADO) pois recomenda-se a
geração de chaves substitutas entre tabelas de dimensão e tabelas fato (E não originais nas fontes
de origens)

2.8 Construção de relatórios e dashboards interativos em ferramentas de BI.

2.9 Manipulação de dados em planilhas.
2.10 Geração de insights a partir de relatórios e dashboards.
2.11 BI como suporte a processos de tomada decisão.

3. Infraestrutura Computacional e Redes.

3.1 Conceitos básicos de processamento paralelo e distribuído.

 A computação paralela é caracterizada pelo uso de várias unidades de processamento, que

trabalham de forma simultânea, com o objetivo de otimizar a execução de uma tarefa.
Baseia-se no conceito de dividir-para-conquistar.
 A execução de tarefas em um ambiente fortemente acoplado permite que a memória seja
compartilhada entre os processos cooperantes.
 Para a elaboração de um programa paralelo, é necessário prévio conhecimento da
arquitetura de comunicação entre os processadores.
  A computação paralela é caracterizada pelo uso de vários processadores para executar uma
computação de forma mais rápida, baseando-se no fato de que o processo de resolução de
um problema pode ser dividido em tarefas menores, que podem ser realizadas
simultaneamente através de algum tipo de coordenação.
 A arquitetura distribuída apresenta algumas desvantagens em comparação ao modelo
centralizado no que se refere a complexidade, segurança, capacidade de gerenciamento e
imprevisibilidade.
 O modelo de computação em grade (grid) tem como objetivo a obtenção de alto desempenho
de processamento distribuído entre diversas máquinas geograficamente próximas ou não.
 Dificuldade de gerenciamento do sistema: É um problema que ocorre na abordagem cliente-
servidor de duas camadas utilizando o modelo cliente-gordo.
 Sistemas que usam a arquitetura, cliente-servidor em duas camadas geralmente possuem
problemas de falta de escalabilidade, dificuldade de manutenção e dificuldade de acessar
fontes heterogêneas.
 Em sistemas distribuídos, clusterização é o nome que se dá ao processo de interconexão de
múltiplas máquinas com o objetivo de obter um aumento de disponibilidade, desempenho ou
capacidade total de um sistema. Em relação à clusterização é correto afirmar: Dependendo
da natureza do serviço, executar uma operação de failover significa interromper as
transações em andamento, perdendo-as, sendo necessário reiniciá-las após o término do
processo

Sistemas com funcionalidade de tuning são capazes de otimizar automaticamente suas próprias
características internas de funcionamento, sem influência externa. (ERRADO) Tuning refere-se
basicamente ao conceito de propor e aplicar mudanças visando otimizar o desempenho na
recuperação ou atualização de dados. Em curtas palavras, Tuning (em TI) é sinônimo de otimização.

Para fazer um bom trabalho de Tuning, é necessário executar criteriosamente os seguintes processos:

1. Entender o problema;
2. Elaborar o diagnóstico;
3. Aplicar as dicas e técnicas de otimização (que se aplicam ao diagnóstico elaborado).

O objetivo principal do trabalho de tuning é minimizar o tempo de resposta e recuperação dos dados
das aplicações.
O atributo confiabilidade da tolerância a falhas refere-se ao fator de disponibilidade do
sistema em determinado período de tempo.  (ERRADO) Confiabilidade é uma medida de
probabilidade, pois a ocorrência de falhas é um fenômeno aleatório. Confiabilidade não
pode ser confundida com disponibilidade. Um sistema pode ser de alta confiabilidade e de
baixa disponibilidade. Um exemplo seria um avião que precisa de reparos e manutenção
nos intervalos de vôo.

Disponibilidade é a probabilidade do sistema estar operacional num instante de tempo

determinado. Disponibilidade é o atributo mais usado em sistemas de missão crítica.
Sistemas de consulta de base de dados on-line, servidores de rede, servidores de
páginas web, são alguns exemplos de sistemas onde alta disponibilidade é requerida.

3.2 High Performance Computing (HPC).

 Conhecido como Computação em alto desempenho

 É uma forma de processar grandes volumes de dados em velocidades muito altas usando vários
computadores e dispositivos de armazenamento como uma estrutura coesa.
 Uso de supercomputadores ou clusters de vários computadores em tarefas que requerem grandes
recurso de computação em quesito de teraflops.
 Um termo relacionado, computação de alto desempenho técnico (HPTC), geralmente se refere às
aplicações de engenharia de computação baseada em cluster (como dinâmica de fluidos
computacional e na construção e teste virtual de protótipos ). Recentemente, a HPC tem vindo a
ser aplicada a negócios usos de supercomputadores baseados em cluster, tais como data
warehouses, linha de negócios (LOB) e processamento de transações.
 A HPC pode ser executada em muitos tipos de cargas de trabalho, mas os dois mais comuns são:
o cargas de trabalho embaraçosamente paralelas: são problemas computacionais
divididos em tarefas pequenas, simples e independentes que podem ser executadas ao
mesmo tempo, geralmente com pouca ou nenhuma comunicação entre elas.
o cargas de trabalho fortemente acopladas: normalmente pegam uma grande carga de
trabalho compartilhada e a divide em tarefas menores que se comunicam
continuamente. Em outras palavras, os diferentes nós no cluster se comunicam uns com
os outros enquanto executam seu processamento.

3.3 Virtualização (computação, armazenamento, rede).

o A virtualização é uma técnica que permite a criação de uma máquina virtual para
funcionar dentro do sistema de um PC.
o permite, por exemplo, a execução de sistemas operacionais completos ou uma
simulação do comportamento do sistema para quem trabalha com desenvolvimento de
software e testes de segurança.
o um monitor de máquina virtual ou hipervisor é o componente que cria a ilusão de
múltiplas máquinas virtuais no mesmo hardware. 
o Tipos de virtualização:
 virtualização de hardware: criação de computadores virtuais para rodar no
seu sistema, capazes de simular o funcionamento completo de outro
computador, com seu próprio sistema operacional, apps e etc. Ex: Virtuabox
 virtualização de aplicativos: a técnica é usada de forma mais discreta,
oferecendo uma camada de compatibilidade para garantir que aplicações de
outros sistemas funcionem no seu computador.
 virtualização de apresentação: a ideia é permitir o acesso a um sistema
completo de forma remota, sem necessidade de contato físico com o
computador que executa o sistema.
o Hypervisor VMWare versão 6.5 é um Hypervisor Tipo 1. Lembrando que o VMWare
também tem soluções de Hypervisor tipo II, como por exemplo o Vmware Workstation.
o Hypervisores – Tipo 1 (SERVER)
 • Também chamado de baremetal
 • O Hypervisor é o próprio S.O
 • Único programa funcionando em modo núcleo
 • Gerenciar várias cópias de hardware real (Máquinas Virtuais)
 • Máquina Virtual executa S.O. hóspede que acredita estar em modo núcleo
 • Máquina virtual executa processos no modo usuário (e está)
 • cada máquina virtual tem a ilusão de que esses recursos são privativos
 • Código de pequeno tamanho interfere pouco no desempenho
o Hypervisores - Tipo 2 (WORKSTATION)
 • É apenas um programa do usuário funcionando
 • Interpretador do conjunto de instruções da máquina
 • SO que funciona sobre o hardware é o SO hospedeiro (executa sobre um
sistema operacional hospedeiro.)
 • Roda sobre o SO nativo como se fosse um processo deste
o Vantagens da virtualização:
 Gerenciamento centralizado
 Facilidade para a execução de backups
 Suporte e manutenção simplificados
 Acesso controlado a dados sensíveis e à propriedade intelectual mantendo-os
seguros dentro do data center da empresa
 Independência de Hardware
 Disponibilização de novos servidores fica reduzida para alguns minutos
 Migração de servidores para novo hardware de forma transparente
 Maior disponibilidade e mais fácil recuperação em caso de desastres
 Compatibilidade total com as aplicações
 Economia de espaço físico / Economia de energia elétrica utilizada em
refrigeração e na alimentação dos servidores.
 Segurança: Usando máquinas virtuais, pode-se definido qual é o melhor
ambiente para executar cada serviço, com diferentes requerimentos de
segurança, ferramentas diferentes e o sistema operacional mais adequado
para cada serviço. Além disso, cada máquina virtual é isolada das demais.
Usando uma máquina virtual para cada serviço, a vulnerabilidade de um
serviço não prejudica os demais.
 Confiança e disponibilidade: A falha de um software não prejudica os demais
serviços.
 Adaptação às diferentes cargas de trabalho:A carga de trabalho pode ser
tratada de forma simples. Normalmente os softwares de virtualização realocam
os recursos de hardware dinamicamente entre uma máquina virtual para a
outra.
 Balanceamento de carga: Toda a máquina virtual está encapsulada, assim é
fácil trocar a máquina virtual de plataforma e aumentar o seu desempenho.
 Suporte a aplicações legadas: Quando uma empresa decide migrar para um
novo Sistema Operacional, é possível manter o sistema operacional antigo
sendo executado em uma máquina virtual, o que reduz os custos com a
migração. Vale ainda lembrar que a virtualização pode ser útil para aplicações
que são executadas em hardware legado, que está sujeito a falhas e tem altos
custos de manutenção. Com a virtualização desse hardware, é possível
executar essas aplicações em hardwares mais novos, com custo de
manutenção mais baixo e maior confiabilidade.
 Segurança: as máquinas virtuais podem ficar isoladas e independentes umas
das outras, inclusive independente da máquina hospedeira.
  Redução de custos: com menos equipamentos físicos para se gerenciar o
custo com pessoal, energia e refrigeração fica mais reduzido
 Melhor aproveitamento do espaço físico: menos dispositivos físicos instalados
maior o espaço  disponível em racks.
 Melhor aproveitamento do hardware: com o compartilhamento do  hardware
entre as máquinas virtuais reduz-se a ociosidade do equipamento.
 Redução do downtime
 Utilização de uma VM como ambiente de desenvolvimento: possibilita testes
em SO’s distintos e, por prover um ambiente isolado, evita que falhas na
configuração e/ou execução, ou até mesmo vírus, danifiquem o hardware da
máquina
o Desvantagens da virtualização:
 Grande uso de espaço em disco, já que é preciso de todos os arquivos para
cada sistema operacional instalado em cada máquina virtual.
 Dificuldade no acesso direto a hardware, como por exemplo placas específicas
ou dispositivos USB
 Grande consumo de memória RAM dado que cada máquina virtual vai ocupar
uma área separada da mesma
 Segurança: As máquinas virtuais podem ser menos seguras que as máquinas
físicas justamente por causa do seu host. Este ponto é interessante, pois se o
sistema operacional hospedeiro tiver alguma vulnerabilidade, todas as
máquinas virtuais que estão hospedadas nessa máquina física estão
vulneráveis.
 Gerenciamento: Os ambientes virtuais necessitam ser instanciados,
monitorados, configurados e salvos. Existem produtos que fornecem essas
soluções, mas esse é o campo no qual estão os maiores investimentos na
área de virtualização, justamente por se tratar de um dos maiores contra-
tempos na implementação da virtualização.
 Desempenho: Atualmente, não existem métodos consolidados para medir o
desempenho de ambientes virtualizados. No entanto, a introdução de uma
camada extra de software entre o sistema operacional e o hardware, o VMM
ou hypervisor, gera um custo de processamento superior ao que se teria sem
a virtualização. Outro ponto importante de ressaltar é que não se sabe
exatamente quantas máquinas virtuais podem ser executadas por
processador, sem que haja o prejuízo da qualidade de serviço.
o Paravirtualização (Não é virtualização completa): A paravirtualização é outra
abordagem para a virtualização de servidores onde, ao invés de emular um ambiente de
hardware completo, a paravirtualização age como uma camada fina, que garante que
todos os sistemas operativos hóspedes partilham os recursos do sistema e convivem
harmoniosamente. Na paravirtualização, o núcleo (kernel) do sistema operativo hóspede
é modificado especificamente para correr no hipervisor. Isto normalmente envolve a
substituição de quaisquer operações privilegiadas, que só seriam executadas no anel 0
da CPU, por chamadas para o hipervisor, conhecidas como hiperchamadas (hypercalls).
O hipervisor, por sua vez executa a tarefa em nome do núcleo hóspede e também
fornece interfaces de hiperchamada para outras operações críticas do núcleo, tais como
gestão de memória ou gestão de interrupções.
Ex: XEN
o Desvantagem paravirtualização: adaptação do SO convidado.
o Uma paravirtualização ocorre quando o servidor virtual simula todo o conjunto do
hardware necessário para sua execução. (ERRADO)
o Virtualização Total → (CESPE) Na virtualização completa, o hipervisor oferece uma
interface idêntica à arquitetura física subjacente.
o Paravirtualização → (CESPE) A paravirtualização proporciona melhor desempenho em
relação à virtualização total, uma vez que não há teste de cada instrução e os
dispositivos de hardware são acessados por drivers da própria máquina virtualizada.
o O hypervisor exporta todo o conjunto do hardware físico (e não: uma versão do
hardware físico), por isso nesse ambiente utiliza-se a técnica de virtualização completa
o VMware vSphere Storage DRS=> faz o balanceamento de carga de dados
o VMware vSphere Replication=> replicação de dados (SIM) para o caso de falhas

3.4 Conceitos básicos de gerenciamento de filas.

3.5 Gerenciamento de processos.

3.6 Protocolos de rede: TCP/IP, HTTP, HTTPS, FTP, SMTP, LDAP, SSL, SAML 2.0, OAuth.
 Protocolos de rede são os conjuntos de normas que permitem que duas ou mais máquinas conectadas à
internet se comuniquem entre si. Funciona como uma linguagem universal, que pode ser interpretada por
computadores de qualquer fabricante, por meio de qualquer sistema operacional.
 Eles são responsáveis por pegar os dados transmitidos pela rede e dividi-los em pequenos pedaços, que são
chamados de pacotes. Cada pacote carrega em si informações de endereçamento de origem e destino.
Os protocolos também são responsáveis pela sistematização das fases de estabelecimento, controle, tráfego
e encerramento.
 A rede é dividida em camadas, cada uma com uma função específica. Os diversos tipos de protocolos de
rede variam de acordo com o tipo de serviço utilizado e a camada correspondente.
o camada de aplicação: WWW, HTTP, SMTP, Telnet, FTP, SSH, NNTP, RDP, IRC, SNMP, POP3,
IMAP, SIP, DNS, PING;
o camada de transporte: TCP, UDP, RTP, DCCP, SCTP;
o camada de rede: IPv4, IPv6, IPsec, ICMP;
o camada de ligação física: Ethernet, Modem, PPP, FDDi.
 Alguns exemplos de protocolos:
o TCP/IP:
 Trata-se do acrônimo de dois protocolos combinados. São eles o TCP (Transmission
Control Protocol — Protocolo de Controle de Transmissão) e IP (Internet Protocol —
Protocolo de Internet).
 ORIENTADO A CONEXÃO - antes de enviar os dados, ele estabelece uma conexão.
 O TCP também realiza o CONTROLE DE FLUXO, de ERROS, o SINCRONISMO, a
SEQUENCIAÇÃO e a MULTIPLEXAÇÃO de mensagens.
 Presente na camada de TRANSPORTE
 Juntos, são os responsáveis pela base de envio e recebimento de dados por toda a
internet. Essa pilha de protocolos é dividida em 4 camadas:
 aplicação: usada para enviar e receber dados de outros programas pela
internet. Nessa camada estão os protocolos HTTP, FTP e SMTP;
 transporte: responsável por transportar os arquivos dos pacotes recebidos da
camada de aplicação. Eles são organizados e transformados em outros
menores, que serão enviados à rede;
 rede: os arquivos empacotados na camada de transporte são recebidos e
anexados ao IP da máquina que envia e recebe os dados. Em seguida, eles
são enviados pela internet;
 interface: é a camada que executa o recebimento ou o envio de arquivos na
web.
 CHECKSUM detecta erros no protocolo:
 IP - por meio de cálculo sobre o cabeçalho
 TCP / UDP - por meio de cálculo sobre cabeçalho e dados
 OSI 7 CAMADAS:
 Camada de Aplicação: fornecimento de serviços aos usuários.
 Camada de Apresentação: conversão de formatos e criptografia.
 Camada de Sessão: controle de estado da sessão.
 Camada de Transporte: transmissão dos dados fim a fim.
 Camada de Rede/Internet: função de roteamento e endereçamento fim a fim.
 Camada de Enlace: roteamento e endereçamento ponto a ponto.
 Camada Física: definição de especificações físicas (meio físico, voltagem,
pinagem, codificação dos bits)

o HTTP/HTTPS:
 O protocolo HTTP (Hypertext Transfer Protocol — Protocolo de Transferência de
Hipertexto) é usado para navegação em sites da internet. Funciona como uma conexão
entre o cliente (browser) e o servidor (site ou domínio).
 O navegador envia um pedido de acesso a uma página, e o servidor retorna uma
resposta de permissão de acesso. Junto com ela são enviados também os arquivos da
página que o usuário deseja acessar.
 Já o HTTPS (Hyper Text Transfer Secure — Protocolo de Transferência de Hipertexto
Seguro) funciona exatamente como o HTTP, porém, existe uma camada de proteção a
mais. Isso significa que os sites que utilizam esse protocolo são de acesso seguro.
 O protocolo HTTPS é comumente usado por sites com sistemas de pagamentos. Esse
tipo de site depende de proteção que garanta a integridade dos dados, informações de
conta e cartão de créditos dos usuários. A segurança é feita por meio de uma
certificação digital, que cria uma criptografia para impedir ameaças e ataques virtuais.
o FTP:
 Significa Protocolo de Transferência de Arquivos (do inglês File Transfer Protocol). É a
forma mais simples para transferir dados entre dois computadores utilizando a rede.
 O protocolo FTP funciona com dois tipos de conexão: a do cliente (computador que faz o
pedido de conexão) e do servidor (computador que recebe o pedido de conexão e
fornece o arquivo ou documento solicitado pelo cliente).
  O FTP é útil caso o usuário perca o acesso ao painel de controle do seu site. Assim
sendo, essa ferramenta pode ser usada para realizar ajustes página, adicionar ou excluir
arquivos, ou ainda solucionar qualquer outra questão no site.
o SMTP:
 Protocolo para transferência de e-mail simples (Simple Mail Transfer Protocol) é
comumente utilizado para transferir e-mails de um servidor para outro, em conexão
ponto a ponto.
 As mensagens são capturadas e enviadas ao protocolo SMTP, que as encaminha aos
destinatários finais em um processo automatizado e quase instantâneo. O usuário não
tem autorização para realizar o download das mensagens no servidor.
o IMAP:
 IMAP — Internet Message Access Protocol — é um meio de acesso entre o servidor de
e-mails e o software cliente. Essa comunicação é feita por meio do protocolo TCP/IP.
 protocolo IMAP utiliza a porta 143 na transferência simples de mensagens ou 993 em
conexões criptografadas via SSL. A utilização dessa porta é recomendada para evitar o
alto volume de mensagens de spam.
 Uma das principais características do protocolo é manter as mensagens no servidor, ou
seja, ao acessá-la por meio do software cliente, os e-mails descarregados não são
apagados.
 O protocolo POP3 descarrega as mensagens do servidor apenas no primeiro dispositivo
que fez a solicitação. Assim, a outra máquina não terá acesso a esses e-mails.
o LDAP:
 O LDAP é um protocolo de rede que roda sobre o TCP/IP e permite organizar os
recursos de rede de forma hierárquica, como uma árvore de diretório, em que temos,
primeiramente, o diretório raiz, em seguida, a rede da empresa, o departamento e, por
fim, o computador do funcionário e os recursos de rede (arquivos, impressoras, etc.)
compartilhados por ele.
 Além disso, o acesso a esses dados pode ser feito de forma segura, pois a maioria dos
servidores LDAP oferece conexões criptografadas usando SSL com uso de TLS.
 OAuth - Single Sign On pra Internet
 LDAP - Single Sign On pra Intranet
 Não há comunicação entre os dois (OAuth x LDAP)
o SSL:
 O protocolo SSL (Secure Sockets Layer — Camada de Portas de Segurança) permite a
comunicação segura entre os lados cliente e servidor de uma aplicação web, por meio
de uma confirmação da identidade de um servidor e a verificação do seu nível de
confiança.
 Ele age como uma subcamada nos protocolos de comunicação na internet (TCP/IP).
Funciona com a autenticação das partes envolvidas na troca de informações.
 A conexão SSL é sempre iniciada pelo cliente, que solicita conexão com um site seguro.
O browser, então, solicita o envio do Certificado Digital e verifica se ele é confiável,
válido, e se está relacionado ao site que fez o envio. Após a confirmação das
informações, a chave pública é enviada e as mensagens podem ser trocadas.
o SAML 2.0:
 SAML (Security Assertion Markup Language) é um padrão aberto que permite que
provedores de identidade (idP) passem credenciais de autorização para provedores de
serviços (SP). Isso significa que você pode usar um conjunto de credenciais para entrar
em diferentes sites. É muito mais simples gerenciar um login por usuário do que
gerenciar logins separados para e-mail, CRM, Active Directory, etc.
 As transações SAML usam XML (Extensigle Markup Language) para comunicações
padronizadas entre o provedor de identidade e os provedores de serviços. O SAML é o
link entre a autenticação da identidade de um usuário e a autorização para usar um
serviço.
o OAuth:
 é um protocolo padrão para autorização. Permite que aplicativos como Web App, Mobile
e Desktop obtenham acesso limitado às informações de usuários através do protocolo
HTTP.
 O OAuth 2.0 define quatro roles.
 Resource Owner - É a pessoa (entidade) que concede o acesso aos seus
dados. Literalmente o Dono do Recurso. É como o OAuth 2.0 classifica o
usuário.
 Resource Server - É a API. Exposta na internet e contém os dados do
Usuário. Para conseguir acesso ao seu conteúdo é necessário um token
emitido pelo Authorization Server.
 Authorization Server - Responsável por autenticação e emitir tokens de
acesso (Access Token). Detém informações dos Resource Owner (Usuários) e
expõe no formato de Claims através do Bearer Token. Autentica e interage
com o usuário após identificar e autorizar o client.
 Client - É a aplicação que interage com o Resource Owner. No caso de uma
App Web, seria a aplicação do Browser.
 o SSH:
 SSH (Secure Shell, já citado acima) é um dos protocolos específicos de segurança de
troca de arquivos entre cliente e servidor. Funciona a partir de uma chave pública. Ela
verifica e autentica se o servidor que o cliente deseja acessar é realmente legítimo.
 O usuário define um sistema de proteção para o site sem comprometer o seu
desempenho. Ele fortifica a segurança do projeto e garante maior confiança e
estabilidade na transferência de arquivos.

O TCP possui capacidade de controle de conexões, utilizando o envio e recebimento de flags para
validar ou testar o estado de uma conexão. A flag do tipo SYN faz o pedido de abertura de conexão.
(CERTO)

O TCP, um protocolo da camada de transporte do TCP/IP, oferece à aplicação solicitante um

serviço confiável, orientado à conexão, além de controle de congestionamento para evitar que outra
conexão TCP encha os enlaces e roteadores entre hospedeiros comunicantes com uma quantidade
excessiva de tráfego. (CERTO)

Na arquitetura TCP/IP, a camada Internet tem como principal função permitir que as entidades
pares dos hosts de origem e de destino mantenham uma conversação.(ERRADO) Camada
Transporte.

Localizado na camada de transporte do modelo TCP/IP, o protocolo UDP tem como características
o controle de fluxo e a retransmissão dos dados. (ERRADO) UDP: •Não orientado à conexão. •Sem
controle de fluxo. •Prioridade: tempo real.

Um protocolo da camada de transporte é implementado no sistema final e fornece comunicação

lógica entre processos de aplicação que rodam em hospedeiros diferentes. (CERTO)

Assinale a opção que indica o protocolo de transporte a ser utilizado na publicação de um serviço
HTTPS acessível a todos os usuários na Internet. (TCP (transmission control protocol))

TCP (transmission control protocol) é um protocolo orientado a conexões, confiável, que permite
que um fluxo de dados entre duas máquinas conectadas em rede seja entregue sem erros.(CERTO)

TCP (transmission control protocol) é um protocolo orientado a conexões, confiável, que permite
que um fluxo de dados entre duas máquinas conectadas em rede seja entregue sem erros.(CERTO)

Na camada de transporte, os protocolos TCP e UDP proveem serviços de fluxo: o primeiro

fragmenta mensagens longas em segmentos mais curtos e provê mecanismo de controle de
congestionamento; o segundo provê serviço não orientado a conexão e controla o
congestionamento por meio de janelas deslizantes.(ERRADO) UDP não controla porra nenhuma

Detecção e correção de erros são mecanismos que acrescentam informações redundantes ao

tráfego da rede de computadores, com o objetivo de viabilizar a identificação e a mitigação de
eventuais falhas nos dados recebidos da transmissão.(CERTO) pois Na detecção de erros, estamos
verificando se ocorreu algum erro. A resposta é simples sim ou não.
Na correção de erros, precisamos saber o número exato de bits que foram corrompidos e, mais
importante, sua localização. O conceito mais importante na detecção e correção de erros é a
redundância. Para sermos capazes de detectar e corrigir erros, precisamos enviar alguns bits extras
redundantes juntos com os dados.

O FTP (File Transfer Protocol) é um protocolo da camada de aplicação do TCP/IP que utiliza duas
conexões TCP paralelas para transferir um arquivo: uma de controle e outra de dados.(CERTO)

O envio de uma mensagem eletrônica que contenha texto e um arquivo anexado é realizado
mediante dois protocolos: SMTP (simple mail transfer protocol), para o texto, e FTP (file transfer
protocol), para o arquivo.(ERRADO)

4. Segurança da Informação.
4.1 Segurança física e lógica.

 É um conjunto de medidas e práticas de segurança da informação organizacional que tem

como finalidade garantir confidencialidade, disponibilidade e integridade da informação
sensível.
 Um ativo: é todo e qualquer item que possa ser economicamente considerado, ao qual possa
ser associada uma ideia de valor, ainda que minimamente expressivo. Pode ser um bem
tangível ou intangível.
 Importante ter integração entre TI (área responsável pela segurança lógica) e área de
segurança patrimonial (área responsável pela segurança física)
 É responsabilidades de todos na organização e principalmente, das áreas de TI e de
Segurança Patrimonial
  Principais riscos à segurança da informação: É fundamental avaliação de risco para definir a
politica de controle de acesso físico
o Perda de confidencialidade: informação não disponível ou revelada a indivíduos,
entidades ou processos não autorizados.
o Perda de integridade: propriedade de salvaguarda da exatidão e completeza dos
dados e informações.
o Perda de disponibilidade: Propriedade de estar acessível e utilizável sob
demanda por uma pessoa ou entidade autorizada.
 Segurança física: refere-se a segurança do ambiente físico da organização.
o São barreiras físicas (obstáculo à progressão física de um indivíduo)
o Ex: método de controle de acesso de pessoas não autorizadas a áreas restritas
(onde encontram dados e informações críticas da empresa)
o Proteção dos equipamentos e informações contra usuários não autorizados.
o Segurança física pode ser abordada sob duas formas:
 Controle de acesso físico: proteção contra acesso físico.
 Segurança do ambiente: Contra danos por causas naturais: terremotos,
chuvas, alagamento etc.
 Segurança lógica: refere-se a segurança do ambiente virtual da organização.
o Conjunto de recursos executados para proteger o sistema, dados e programas
contra tentativas de acesso de pessoas ou programas desconhecidos.
o Permite acesso controlado à ambiente virtual com dados e informações da
organização. Proteção baseia-se na necessidade de acesso de cada usuário.
o Objetivo: Proteger dados, programas e sistemas contra tentativas de acessos não
autorizados, feitas por usuários ou outros programas.
o Métodos: Identificação (identificação do usuário) e autenticação do usuário(login
através de senha)
o Exemplos de segurança lógica:
 Firewall de hardwares e softwares
 Senhas de acesso
 Sistema de detecção de intrusos
 Redes virtuais privadas (VPN)
 Criptografia
 Antivirus
 Protocolos de acessos e uso
 Etc
 Convergência física e lógica:
o Segurança da organização começa pelo ambiente físico e depois ambiente virtual

4.2 Operação de segurança (Firewall, Proxy, IPS/IDS, DLP, CASB, SIEM, Antivírus, EDR, WAF, Gestão de
vulnerabilidades, Monitoração, Backup).

 Honeypot é uma vulnerabilidade proposital para atrair o atacante e desviar sua atenção dos
servidores e recursos importantes.
 Eavesdropping (computadores) é uma técnica de hacking que se baseia na violação da
confidencialidade, onde um atacante através de recursos tecnológicos, aproveitando de
vulnerabilidades nas comunicações de possíveis vitimas, faz um monitoramento sem
autorização nesta comunicação, podendo roubar dados e informações que poderão ser
usadas posteriormente. Uso da técnica de sniffing.
 Biometria, Forma de identificar de maneira única um indivíduo por meio de suas
características físicas ou comportamentais.
 Intrusion Detection System (IDS) Late e não morde
o Sistema de Detecção de Intrusão - é um sistema que possibilita a coleta e o uso de
informações dos diversos tipos de ataques em prol da defesa de toda uma
infraestrutura de rede. É um software que automatiza o processo de detecção de
intrusão.
o É usado para monitorar e proteger redes detectando atividades mal-intencionadas
e relatando-as a um grupo ou contato, como um administrador de rede. Uma vez
que as atividades desse tipo são detectadas, um administrador é alertado.
o O sistema analisa o tráfego da rede em busca de assinaturas que correspondam a
ciberataques conhecidos. Através de comparação de flags definidas em um
cabeçalho TCP com boas e más combinações conhecidas de flags.
o IDS (e não é o FIREWALL) é o primeiro sistema de detecção de intrusão que deve
ser instalado no perímetro da rede de computadores de uma organização, ou seja,
entre a rede local e a Internet.
o Um IDS permite criar regras com o objetivo de monitorar aumentos anormais de
tráfego de rede; além dessa funcionalidade, ele ainda pode alertar o responsável
pela segurança, caso ocorram tais anomalias. (CERTO)
 o Os sistemas de detecção de intrusos consistem em ferramentas auxiliares,
utilizadas para evitar que determinados programas verifiquem a existência de
portas TCP abertas em um computador e venham a invadi-lo por intermédio delas.
(CERTO)
o Um IDS (Intrusion Detection System) pode ser usado para detectar varreduras de
porta e de pilha TCP, além de ataques de DoS, de inundação de largura de banda,
de worms e de vírus. (CERTO)
o Um sistema de detecção de intrusão (intrusion detection system – IDS) consegue
detectar comportamentos maliciosos tanto em computadores individuais quanto em
redes de computadores. (CERTO)
 Intrusion Prevention System (IPS/SPI) = Late e Morde
o Tem a capacidade de identificar uma intrusão, analisar a relevância do evento/risco
e BLOQUEAR determinados eventos (fortalece a técnica de detecção de intrusos).
o É uma ferramenta com inteligência na maneira de trabalhar, pois reúne
componentes que fazem com que ele se torne um repositório de logs e técnicas
avançadas de alertas e respostas.
o É uma ferramenta de maior abrangência de segurança.
o O IPS usa a capacidade de detecção do IDS junto com a capacidade de bloqueio
de um firewall.
 DLP (Data Loss Prevention)
o Evita o vazamento de dados
o Os recursos do software DLP classificam as informações que são confidenciais e
as protegem de forma mais rigorosa, impedindo que os usuários finais acessem e
compartilhem, de forma acidental ou maliciosa, os dados que possam colocar a
organização em situação de risco e exposição livre na internet.
o Para que DLP seja implementada, é necessário que a informação crítica da
organização esteja classificada.
 Firewall baseado em Unified Threat Management (UTM): contempla antivírus, filtros de
pacotes, controle de acesso wireless, suporte à Virtual Private Network (VPN) e controle de
intrusões na rede, chegando a gerar relatórios com diagnóstico de possíveis ameaças
lógicas às quais o centro de dados possa estar vulnerável. Para a melhoria de desempenho,
vários produtos de segurança (firewall e antispyware, por exemplo) podem ser substituídos
por um sistema de gerenciamento unificado de ameaça (UTM – unified threat management).
O UTM pode possuir funções como: antivírus, antispyware, antispam, firewall de rede,
detecção e prevenção de invasões, filtragem de conteúdo e prevenção de vazamentos.

 Multi-Factor Authentication (MFA): submete o usuário a mecanismos de autenticação

combinados, pertencentes pelo menos às categorias: conhecimento (something you know),
possessão (something you have) e herança (something you are).
 Uninterruptible Power Supply (UPS): visa fornecer energia para todos os equipamentos,
sendo composto por conjuntos de nobreaks, baterias, inversores e retificadores. Os nobreaks
redundantes irão assegurar o suprimento contínuo de energia, mesmo em caso de falha de
transformadores ou falta de energia elétrica e as baterias são dimensionadas para garantir
uma autonomia por um período mínimo de tempo.
 BACKUP:
o O fato de várias ferramentas de snapshots (fotografia) configurarem uma
validade para cada cópia e, vencido o prazo, cópia ser apagada e o espaço
reutilizado para um novo becape é um problema que pode ser solucionado, em um
sistema gerenciador web, por meio da desduplicação na origem, tecnologia que
permite guardar apenas os segmentos de dados únicos das VMs em cada
snapshot, o que economiza tanto em armazenamento como em I/O de becape e
tráfego na rede.
o Snapshot (FOTO DO SISTEMA): Cria-se uma fotografia do estado dos dados em
um momento específico, estabelece um ponto de restauração caso haja falha.
Fornece cópias instantâneas dos dados sem consumir muito espaço. São ideais
para testes de backup ou de desenvolvimento, análise da informação e mineração
de dados.
o Desduplicação: processo usado para diminuir a quantidade de dados
armazenados. A ideia é fazer com que nunca exista dois ou mais computadores
armazenando os mesmos dados. Ganha espaço em disco e diminuição no tempo
de backup.
 Modelo da cebola: Segundo Northcutt et. al (2002) propõe que se pense na segurança de
uma rede como uma cebola: Quando você descasca a camada mais externa,muitas
camadas permanecem por baixo dela.
 O firewall pode ser utilizado para detectar tráfego de rede suspeito, especialmente o tráfego
que sai de um computador sem nenhuma razão, no caso, provocado pelo programa
malicioso espião.
 O firewall é indicado para filtrar o acesso a determinado computador ou rede de
computadores, por meio da atribuição de regras específicas que podem negar o acesso
 de usuários não autorizados, assim como de vírus e outras ameaças, ao ambiente
computacional.
 O firewall é capaz de proteger o computador tanto de ataques de crackers quanto de
ataques de vírus.
 Filtros de pacotes tradicionais são considerados firewall porque podem executar uma política
de filtragem com base na combinação de endereços e números de porta, examinando cada
datagrama e determinando, a partir de regras específicas, se ele deve passar ou ficar.
 O firewall, consegue:
o roteamento
o bloqueia pacote ICMP (ex: método PING)
o faz inspeção de estado, porém não faz pelo tcp
o inspeção dados o qual é realizado pela leitura do cabeçalho (IPS analisa o
conteúdo e não cabeçalho) e NÃO pelo estado de conexão
o controla a conexão de entrada e saída
o filtra o tráfego de entrada e saída
o permite regular o tráfego de dados
o Um firewall é capaz de verificar tanto o endereço IP de origem quanto o endereço
IP de destino em um pacote de rede.
 Firewall Stateles: 1° geração, filtro de pacotes, não possui estado de sessão. Filtros de
pacotes são firewall mais simples (nossos programas firewall pessoais são assim) que
normalmente atuam apenas na camada 3 (camada de rede e não da camada de enlace),
analisando e filtrando pacotes do protocolo IP de acordo com informações específicas
contidas em seus cabeçalhos. Como um pacote contém apenas alguns tipos de dados em
seu cabeçalho (como endereço IP de origem, endereço IP de destino, porta do protocolo,
entre outros), os filtros de pacotes conseguem filtrar os pacotes (decidir se passam ou são
bloqueados) por meio desses poucos critérios. (Não permite implementar controles
baseados em políticas mais complexas e personalizadas da organização.)
 Firewall Stateful: 2° geração, filtro de sessão, analisa uma sessão com a passagem dos
pacotes. é um de rede que rastreia o estado operacional e as características das conexões
de rede que o atravessam. O firewall está configurado para distinguir pacotes legítimos para
diferentes tipos de conexões. Somente os pacotes que combinam a conexão ativa conhecida
podem passar pelo firewall. A inspeção dos estados dos pacotes (SPI), também referida
como filtragem de pacotes dinâmicos, é uma característica de segurança que muitas vezes é
incluída nas redes de empresas. O emprego de assinaturas atômicas em um sistema de
prevenção de intrusão (SPI) permite a construção de sistemas mais simples, quando
comparado com os que empregam assinaturas stateful.
 Configuração ideal do firewall: firewall pode bloquear saida e entrada porém, o MAIS
RECOMENDAVEL é liberar a saída e bloquear as entradas.
 O QUE ELE NÃO CONSEGUE FAZER:
o ❌ não estabelece política de comportamento;
o ❌ não detecta sniffer (IDS que detecta sniffer);
o ❌ não bloqueia spam e nem e-mails indesejados;
o ❌ não faz varredura em anexo de e-mail;
o ❌ não impede que arquivos com vírus sejam abertos;
o ❌ não cria VPN; Nenhum firewall cria VPNs;
o ❌ não consegue evitar ataques de dentro da rede; e
o ❌ não criptografa documentos.
o Não consegue bloquear ataque DDoS (excesso de conexões válidas)
 Os NFGW (next generation firewalls) se diferenciam dos firewalls UTM (unified threat
management), entre outras características, pelo uso da tecnologia DPI (deep packet
inspection), que analisa pacotes de dados até a camada de aplicação, e por trazer
inteligência externa aos firewalls.
 Em sistemas virtualizados, escape to host ou guest-to-host virtual machine escape são
ataques em que o atacante explora vulnerabilidades normalmente associadas ao
virtualizador, rompendo o isolamento das máquinas virtuais e acessando o host.
 Um procedimento para identificar as estações de trabalho que executam o código malicioso
é implementar regra no firewall que registre as conexões ao servidor de e-mail, sem
bloquear as conexões, e verificar as estações de trabalho que geraram maior quantidade de
conexões em determinado período de tempo. Esse tipo de procedimento pode ser executado
por equipamentos de firewall com capacidade de filtragem de pacotes.
 Uma das funções dos firewalls é implementar políticas relativas à separação do tráfego
interno e externo à rede a ser protegida, visto que eles filtram o tráfego de entrada e saída
de rede. (roteamento)
 Firewall evita ataque ou seja atua na camada 3 (filtragem de pacotes: IP, porta e protocolo
origem/destino) e 4(inspeção de pacote com estado: conexões de rede ativas e sessões tipo
UDP e TCP) enquanto o buffer overflow é nível de aplicação (camada 7 ex: HTTP POST).
Firewall não analisam o conteúdo de um pacote de dados (payloads dos datagramas).
  Firewall "podem tomar decisões com base em informações das camadas de transporte e
aplicação.": lembre-se que o firewall é capaz de controlar o acesso tanto baseado no
protocolo TCP(transporte), como no firewall por estado de sessão por exemplo, quanto no
protocolo TELNET(aplicação 'modelo tcp/ip'), como no firewall gateway de aplicação.
 Firewall pode ser implementado/instalado por hardware (equipamento de roteamento) ou
por software.
 "firewall que permitiam o acesso de todos os segmentos, internos e externos, ao
servidor web na porta 80 com o protocolo TCP." pessoal, já que esses acessos estão
ocorrendo na porta 80, ou seja, na camada de aplicação, o firewell do tipo Steatefull não tem
a capacidade de impedir conexões na camada de aplicação. esse tipo de firewall atua na
camada de rede e transporte. o firewall que tem a capacidade de impedir conexões na porta
80 é o firewall de aplicação ou proxy firewalls.

4.3 Softwares maliciosos (ransomware, vírus, worms, spywares, rootkit etc.).

Malwares
 Método de identificação de malwares:
o BASEADO EM COMPORTAMENTO/ANOMALIA: OBSERVA OS PORCESSOS EM
BUSCA DE SINAIS REVELADORES DE MALWARE, COMPARADOS A UMA LISTA
DE COMPORTAMENTOS MALICIOSOS CONHECIDOS. Ex: SERIA "SUA ESPOSA"
QUE JÁ TEM UMA LISTA DA SUAS DESCULPAS SÓ DE TE ANALISAR E JÁ ESTÁ
PREPARADA PARA ELAS
o BASEADO EM ASSINATURAS/CONHECIMENTO UTILIZA DE BANCO DE DADOS
COM OS ATAQUES JÁ CONHECIDOS E COMPARA-OS COM AS AÇÕES.É de
extrema importância que o banco de dados com as assinaturas esteja sempre
atualizado
 É possível verificar a entropia de malware por meio do cálculo de entropia de Shannon: -- Certo.
 se um malware usar criptografia para ofuscação, a entropia tende a 0, o que caracteriza alta
entropia -- errado, a entropia tende a aumentar. (Ofuscar código com criptografia tende a uma
entropia maior pq um arquivo criptografado gera caracteres aleatórios, totalmente sem sentido e
desorganizado, pois o conteudo criptografado é completamente embaralhado.)

4.4 Ataques (DDoS, SQL Injection, XSS, CSRF, Path Traversal etc.).

 O termo APT (advanced persistent threat) é utilizado em segurança da informação para

descrever ameaças cibernéticas através de técnicas de coleta de informações que tenham
valor para o atacante. Em geral, uma APT não é detectada por antivírus ou por softwares IDS
firmados em assinaturas.
 A identificação do provedor de conexão do site malicioso deve ser feita no serviço de
diretório Whois brasileiro. (ERRADO) pois o domínio é .uk e não .br

Web Parameter Tampering:

 Esse é um ataque de injeção de parâmetros ou também Web Parameter Tampering.
 Um invasor pode adulterar os parâmetros de URL diretamente. Por exemplo, considere um
aplicativo da web que permite ao usuário selecionar seu perfil em uma caixa de combinação e
debitar a conta:
o http://www.attackbank.com/default.asp?profile=741&debit=1000
 Nesse caso, um invasor pode adulterar o URL, usando outros valores para perfil e débito:
o http://www.attackbank.com/default.asp?profile=852&debit=2000
API Hooking:
 API é o acrônimo de Application Programming Interface ou, em português, Interface de
Programação de Aplicativos. Esta interface é o conjunto de padrões de programação que permite a
construção de aplicativos e a sua utilização de maneira não tão evidente para os usuários.
 O gancho de API do Windows é um processo que permite interceptar chamadas de função API.
Isso lhe dá o controle sobre a forma como o sistema operacional ou um software se comporta.
Algumas das soluções de software que utilizam ganchos incluem: software antimalware, soluções
de segurança de aplicativos, ferramentas de monitoramento de segurança, utilitários de sistema,
ferramentas para programação e muitas outras.

DLL Hijacking:

 A técnica DLL Hijacking tem por objetivo injetar um código malicioso em uma DLL, de modo que
quando um software que necessite da DLL infectada for invocado junto com o carregamento das
legítimas instruções da DLL, o código malicioso também será executado.
 É importante observar que os programas executados no Windows fazem uso de DLLs para seu
correto funcionamento. Esses arquivos armazenam grupos de funções compartilhadas que
padronizam e facilitam o desenvolvimento de softwares, pois reduz a quantidade de código a ser
 escrito pelo programador. Em contrapartida os tornam dependentes de determinadas DLLs para
sua execução.
 Prevenção:
o Sempre utilizar a última versão de softwares e aplicar todas as atualizações e ter certeza
que as atualizações estão sendo fornecidas pelo fabricante e não por alguma entidade
falsa
o Executar varreduras de vulnerabilidades em suas estações e servidores a fim de garantir
que não existam software vulneráveis e/ou desatualizados instalados.

HIJACKERS

➥ Do Português - sequestradores - são spywares invasores que realizam mudanças no browser do

usuário sem a sua autorização.

➥ Em outras palavras, o Browser Hijacker é um software malicioso que modifica o registro do sistema
operacional, alterando o funcionamento do navegador, modificando sua página inicial, abrindo páginas
automaticamente ou inserindo botões inadvertidamente.

➥ Eles alteram a página inicial do navegador, redirecionando qualquer página visitada para outra,
escolhida pelo criador da praga.

✓ Fixa uma página falsa no navegador;

✓ Sequestra o browser → a página de navegação;

✓ Captura os dados inseridos na página falsa;

✓ Faz com que o navegador fique desordenado → botões, propagandas, páginas; e

✓ Usufrui de diversas técnicas para tentar confundir a vítima.

O Browser Hijacker é um software malicioso que modifica o registro do sistema operacional, alterando o
funcionamento do navegador, modificando sua página inicial, abrindo páginas automaticamente ou
inserindo botões inadvertidamente. (CERTO)

Buffer overflow
 é um tipo de ataque que, ao explorar falha na implementação de um programa, permite escrita em
um endereço de memória diferente do previamente alocado.

DDoS:
 Conhecido como Ataque de negação de serviços.
 Um ataque DDoS que utiliza protocolo DNS caracteriza-se por usar servidores de nomes
para transformar consultas pequenas em cargas úteis muito maiores na resposta
redirecionada à vítima.
 DDoS - Várias máquinas deferem o ataque
 DOS - Apenas uma máquina defere o ataque
 Ambos o tipos causarão a negação de serviço
 Denial of Service (DOS): ataque de negação de serviço é uma técnica pela qual um atacante
utiliza um equipamento conectado à rede para tirar de operação um serviço, um computador
ou uma rede conectada à Internet. O objetivo destes ataques não é invadir nem coletar
informações, mas sim exaurir recursos e causar indisponibilidades.
 Os ataques de DoS são realizados geralmente sobre as camadas de transporte ou de
aplicação. Ou seja, os firewalls que analisam essas camadas conseguem perceber com mais
facilidade do que os demais (não mencionou a efetividade, apenas a percepção dos
ataques).
 A fim de evitar um ataque de DDoS, um procedimento apropriado é identificar padrões de
comportamento suspeitos e, então, aplicar filtros aos pacotes cujas características indicam
risco de ataque.
 Um ataque DDoS que utiliza protocolo DNS caracteriza-se por usar servidores de nomes
para transformar consultas pequenas em cargas úteis muito maiores na resposta
redirecionada à vítima. Certo
 Os ataques DDoS de camada de aplicação são caracterizados por explorar aspectos de
arquitetura das aplicações e dos serviços para obstruir a comunicação; além disso, são
difíceis de detectar e podem ser efetivos com poucas máquinas e taxas de tráfego não muito
altas. Certo
XSS
 É um ataque de injeção (e NÃO ataque de execução) de script entre sites.
  Refere-se a uma variedade de falhas de programa relacionadas com o tratamento incorreto
de dados de entrada. Especificamente, esse problema ocorre quando a entrada de dados de
programa pode influenciar acidental ou deliberadamente o fluxo de execução do programa.
 Outra classe geral de vulnerabilidades refere-se a entradas fornecidas por um usuário a um
programa que, subsequentemente, fornece como saída a entrada para outro usuário. Tais
ataques são conhecidos como ataques de execução de script entre sites (cross-site scripting
— XSS6), porque são mais comumente vistos em aplicações web escritas em linguagem de
script.

TROJAN

 O Trojan-DDoS: conduzem ataques de negação de serviço (DoS, Denial of Service) contra

um endereço da Web específico. Ao enviar várias solicitações usando seu computador e
muitas outras máquinas infectadas, o ataque pode sobrecarregar o endereço de destino e
levar a uma negação de serviço. CERTO

PHISHING

 Os ataques de phishing caracterizam-se pelo envio de mensagens eletrônicas que

despertam a atenção de usuários por meio da sugestão de vantagens ou ameaças de
prejuízos e também por induzirem os usuários a fornecer dados pessoais e(ou) financeiros.
 Phishing é a técnica de criar páginas falsas, idênticas às oficiais, para capturar informações
de usuários dessas páginas.(CERTO)
 O phishing é um procedimento que possibilita a obtenção de dados sigilosos de usuários da
Internet, em geral, por meio de falsas mensagens de email.(CERTO)
 Phishing é um tipo de fraude por meio da qual um golpista tenta obter dados pessoais e
financeiros de outro usuário da Internet utilizando, por exemplo, páginas falsas de comércio
eletrônico e redes sociais, bem como mensagens eletrônicas que contenham formulários de
solicitações falsas de recadastramento.(CERTO)
 Os ataques de phishing caracterizam-se pelo envio de mensagens eletrônicas que
despertam a atenção de usuários por meio da sugestão de vantagens ou ameaças de
prejuízos e também por induzirem os usuários a fornecer dados pessoais e(ou) financeiros.
(CERTO)
 Phishing, técnica pela qual é possível capturar senhas de usuários, pode utilizar mecanismos
de engenharia social para tentar enganar as vítimas.(CERTO)
 Um tipo específico de phishing, técnica utilizada para obter informações pessoais ou
financeiras de usuários da Internet, como nome completo, CPF, número de cartão de crédito
e senhas, é o pharming, que redireciona a navegação do usuário para sítios falsos, por meio
da técnica DNS cache poisoning.(CERTO)
 Uma das técnicas de phishing consiste em envenenar cache de servidores DNS, fornecendo,
assim, URLs falsas aos usuários que consultam esse servidor DNS e apontando para
servidores diferentes do original.(CERTO)
 O ataque de spear phishing, que é uma tentativa de fraude por falsificação de email, tem
como alvo uma organização específica e objetiva, normalmente, conseguir acesso não
autorizado a dados sigilosos.(CERTO)
 Uma maneira de proteger o computador de um ataque de phishing é, no caso de
recebimento de e-mails de instituições financeiras ou governamentais suspeitos, nunca clicar
os links, fornecer dados sigilosos ou executar programas fornecidos no e-mail. Ao invés
disso, deve-se procurar o sítio oficial da instituição ou telefone para se informar sobre a
solicitação feita por e-mail.(CERTO)
 PHARMING:
o É uma evolução do phishing.
o Técnica de envenenamento de cache chamado (DNS Chache Poisoning)- Consiste
no corrompimento do DNS em uma rede de computadores para que a URL de um
site aponte para um servidor diferente do original.
 O browser (Navegador) do computador da vítima sofreu um envenenamento de cache, mas
não necessariamente estava infectado por um software malicioso (Malwares ou Vírus).
(CERTO) pois PHISHING.HE E PHARMING NÃO SÃO MALWARES E NEM VÍRUS.
Ransomware
 Nada vai reverter um ataque que já foi bem sucedido, o ataque já aconteceu e ele já foi bem-
sucedido. Você pode contra-atacar para tentar recuperar os seus dados de acesso (neste caso,
como é um rasomware que impede o acesso às informações armazenadas em um dispositivo), se
você contra-atacar, poderá impedir que quem te atacou fique sem acesso as informações dele,
isso não quer dizer que você terá as suas de volta. Solução: Backup.
 Uso de método de pishing para ataque via ransonware

man-in-the-middle: é uma forma de ataque em que os dados trocados entre duas partes, são de alguma
forma interceptados, registrados e possivelmente alterados pelo atacante sem que as vitimas se apercebam.
Exemplo: Em um espaço público ABC, um hacker instalou um ponto de acesso gratuito à Internet, do tipo
wi-fi sem senha, e deu à rede o identificador ABCfree. O hacker configurou essa rede de modo que usuários
que a ela se conectassem e tentassem acessar sítios de mídias sociais fossem direcionados para páginas
clonadas, nas quais as credencias de acesso dos usuários eram solicitadas. De posse dessas credenciais,
um programa criado pelo hacker estabelecia conexões reais com as mídias sociais e interceptava
transparentemente todas as comunicações dos usuários nas plataformas, acessando indevidamente todo o
seu conteúdo.

SIM cloning se refere a clonagem de telefone.

IP spoofing é a técnica na qual o endereço real (endereço IP) do atacante é mascarado, de forma a evitar
que ele seja encontrado.

ping of death é um recurso utilizado na internet que consiste no envio de pacotes TCP/IP de tamanhos
inválidos para servidores, levando-os ao travamento ou ao impedimento de trabalho.

Pixie Dust Attack é possível descobrir o PIN do roteador com apenas uma tentativa, o que anula qualquer
proteção baseada em restrição no número de tentativas (proteção contra ataques de força bruta). O WPS
(Wi-Fi protected setup) é uma funcionalidade que geralmente pode ser ativada no próprio aparelho roteador,
é basicamente um botão que ao ser pressionado libera a rede para acesso (sem senha) por alguns
segundos.

Krack (key reinstallation attack) é um tipo de ataque que funciona contra o Wi-Fi protected access II
(WPA2) O ataque funciona contra todas as redes Wi-Fi modernas protegidas. Dependendo da configuração
da rede, também é possível injetar e manipular dados. Por exemplo, um invasor pode ser capaz de injetar
ransomware ou outro malware em sites.

CSRF (Cross Site Request Forgery) = PEDIDO DE FALSIFICACAO

 O ataque de CSRF (cross site request forgery) ocorre quando um usuário executa um conteúdo
malicioso sem se dar conta, sendo sua principal característica a desnecessidade de o usuário
estar autenticado, além da resistência da aplicação com CSRF a XSS (cross site script).
(ERRADO pois o usuário precisa estar autenticado
 Se ele está pedindo então não faz sentido o usuário não estar autenticado.
 Acrescentando: Diferente do cross site scripting (XSS), que explora a confiança que um usuário
tem para um site específico, o CSRF explora a confiança que um site tem no navegador de um
usuário.
 As seguintes características são comuns ao CSRF:
o Envolvem sites que dependem de uma identificação do usuário
o Exploram a confiança do site nessa identificação
o Iludem o navegador do usuário para o envio de solicitações HTTP para um site de
destino
o Envolvem solicitações HTTP que têm efeitos colaterais
 CSRF é um tipo de ataque para danificar ou roubar dados de um usuário em um serviço web.
Geralmente um site, widget ou aplicativo mal intencionado aproveita-se do usuário estar logado
em algum serviço web e executa ações nesse serviço. Ao executar um script malicioso no browser
da vitima, acessa outro website, sem que a vítima perceba. O atacante consegue, assim,
sequestrar a sessão da vítima podendo, por exemplo, fazer comentários no site, transferir valores
monetários, fazer uma encomenda, etc. A técnica mais comum para prevenir este tipo de ataque
consiste em colocar um token através de um campo escondido no formulário. Quando o formulário
é submetido é garantido que o token está presente e que coincide com o token guardado em
sessão. Isto é chamado de ataque de sequestro de sessão tem por característica o
comprometimento do token de autenticação de um usuário, podendo esse token ser obtido
interceptando-se a comunicação ou predizendo-se um token válido.

Sniffing: Técnica para captura ilegal de informações. A Análise de pacotes (packet sniffing), interceptação
de tráfego (sniffing) ou passive eavesdropping consiste na captura de informações valiosas diretamente pelo
fluxo de pacotes na rede.

Spoofing:

As técnicas de Spoofing consistem em enganar o destinatário dos ataques:

▪ IP Spoofing: técnica na qual o endereço real (endereço IP) do atacante é mascarado,

de forma a evitar que ele seja encontrado. Atua na camada de rede.

▪ MAC Spoofing: técnica para alterar um endereço de controle de acesso à mídia

atribuído pelo fabricante de uma interface de rede em um dispositivo em rede. Atua na
camada de enlace.

▪ ARP Spoofing: técnica na qual o atacante envia mensagens ARP mascaradas para
uma rede local. Atua na camada de rede.
 ▪ Web Spoofing ou o Hyperlink Spoofing: o usuário é iludido a pensar que está em uma
página autêntica, que, na verdade, é falsificada. Ele acessa uma página segura, protegida
pelo protocolo SSL, e é induzido a fornecer suas informações pessoais ao falso servidor.
Atua na camada de aplicação.

▪ Email Spoofing: consiste em alterar campos do cabeçalho de um e-mail, de forma a

aparentar que ele foi enviado de uma determinada origem quando, na verdade, foi
enviado de outra. Atua na camada de aplicação.

4.5 Técnicas de desenvolvimento seguro, SAST/DAST/IAST.

CAPTCHA:
 O sistema de captcha funciona como uma espécie de teste de Turing reverso, ou seja, a
própria máquina propõe uma questão que, presumivelmente, somente um ser humano será
capaz de responder corretamente.

 O CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart,
Teste de Turing público completamente automatizado para distinguir entre computadores e
pessoas) é um tipo de medida de segurança conhecido como autenticação por desafio e
resposta. O CAPTCHA protege contra spam e descriptografia de senhas com um teste
simples que prova que você é um ser humano, não um computador tentando invadir uma
conta protegida por senha. Captcha atua camada de aplicação! Enquanto TCP atua na
camada de transporte!
4.6 VPN

 VPN É um tunelamento criptografado, E não necessita de um firewall! VPN é o caminho, firewall é

o pedágio; Logo, é possível uma estrada sem pedágio!
 Virtual Private Network (Rede Privada Virtual) trata-se de uma rede privada construída sobre a
infraestrutura de uma rede pública. Essa é uma forma de conectar dois computadores através de
uma rede pública, como a Internet. Ao invés de realizar esse procedimento por meio de links
dedicados ou redes de pacotes, como Frame Relay e X.25, utiliza-se a infraestrutura da internet
para conectar redes distantes e remotas. ( VPN e muito utilizadas por empresas, e um meio barato,
proporciona muitos beneficio.
 Por questões de segurança, quando um servidor de VPN está à frente de um firewall e conectado
à Internet, filtros de pacotes devem ser configurados na interface Internet do servidor de VPN para
permitir somente tráfego VPN de e para o endereço IP daquela interface.
 Uma SSL VPN provê acesso de rede virtual privada por meio das funções de criptografia SSL
embutidas em navegadores web padrão, sem exigir a instalação de software cliente específico na
estação de trabalho do usuário final.
 O protocolo GRE é um protocolo GENÉRICO de roteamento. A função do referido protocolo é
apenas encapsular o caminho, para que chegue ao destino, não havendo criptografia/segurança.
Por isso, comumente é utilizado com algum outro protocolo de segurança, como o PPTP, por
exemplo. O GRE e o PAP, utilizados em uma VPN, não trabalham de forma segura, haja vista que
não fazem o uso de criptografia. Para que haja criptografia, é necessário o uso de outros
protocolos. Protocolo GRE: prioriza rapidez de transmissão e sozinho não criptografa as
informações que são tuneladas, portanto não pode ser considerado seguro;

4.7 MDM.
4.8 SSO.
4.9 MFA.
4.10 Gestão de Identidade e acesso (autenticação, autorização e auditoria), RBAC e ABAC.
 Requisitos básicos de segurança que devem orientar os serviços disponibilizados na internet
e as comunicações realizadas por este meio:
 Identificação: permitir que uma entidade se identifique, ou seja, diga quem ela é.
 Autenticação: verificar se a entidade é realmente quem ela diz ser. é uma propriedade
da Integridade.
 Autorização: determinar as ações que a entidade pode executar.
 Integridade: proteger a informação contra alteração não autorizada. (violação e
alteração de conteúdo / não sigiloso / garantia de não repúdio).
 Confidencialidade ou sigilo: proteger uma informação contra acesso não autorizado.
(acesso não autorizado / quebra de sigilo / sistemas e acessos criptografados por
chaves ou senhas);
 Não repúdio: evitar que uma entidade possa negar que foi ela quem executou uma
ação.
 Disponibilidade: garantir que um recurso esteja disponível sempre que necessário.
(conteúdo disponível para acessos autorizados).
Os três tipos de controle de acesso lógico utilizados em segurança de informação são:

 Controle de acesso discricionário

 o O controle de acesso discricionário (discretionary access control ou DAC) é uma
política de controle de acesso determinada pelo proprietário (owner) do
recurso (um arquivo, por exemplo). O proprietário do recurso decide quem tem
permissão de acesso em determinado recurso e qual privilégio ele tem.
o Em um sistema de controle de acesso discricionário, o proprietário do recurso (e
não o administrador do sistema) estabelece os direitos de acesso dos usuários a
determinado recurso. Com o uso de listas de controle de acesso, os direitos de
acesso são concedidos diretamente pelo dono do recurso.
 Controle de acesso obrigatório (não discricionário)
o No controle de acesso obrigatório (mandatory access control ou MAC) a política de
acesso é determinada pelo sistema e não pelo proprietário do recurso.
 RBAC: Role-Based Access Control
o Possibilita ao administrador de sistema criar papéis, definir permissões para esses
papéis e, então, associar usuários para os papéis com base nas responsabilidades
associadas a uma determinada atividade.
 DAC: Discretionary Access Control
o DAC é baseado na noção de que usuários individuais são donos de objetos ( e
não administradores do sistema) e, portanto, tem controle (discreção) total em
quem deve ter permissões para acessar o objeto. Um usuário transforma-se em
dono do objeto ao criá-lo.
 MAC: Mandatory Access Control
o Enquanto o ponto-chave do DAC é o fato de que os usuários são considerados
donos do objeto e, portanto, responsáveis pelas suas permissões de acesso, o
modelo mandatório (MAC) prevê que usuários individuais não têm escolha em
relação a que permissões de acesso eles possuem ou a que objetos podem
acessar. Nesse modelo, os usuários individuais não são considerados donos dos
objetos, e não podem definir suas permissões, isso é realizado pelos
administradores do sistema.

4.11 Conceitos gerais: Gerenciamento de resposta a incidente (NIST SP 800-61).

4.12 Threat intel, threat hunting.
4.13 Testes de penetração.
4.14 Modelagem de ameaças (STRIDE etc.).
4.15 Conhecimento das Táticas do framework Mitre ATT&CK.
4.16 Gestão de riscos (ISO 31000), Gestão de Continuidade de Negócios (ISO 22301) e Lei Sarbannes-
Oxley.

o Gestão de Risco (ISO 31000)

o A ISO 31000 é a Norma Internacional da Gestão de Risco, que trata de estabelecer as diretrizes para
condução desse processo em uma organização empresarial através de boas práticas que regem o
setor e norteiam o modo ideal de realizar o gerenciamento de ameaças.
o Ela faz a recomendação que o processo de gestão de riscos seja conduzido de maneira integrada à
gestão empresarial, sendo considerado inclusive em momentos de tomada de decisão, como por
exemplo na formação de parcerias e da cadeia de suprimentos.
o Os riscos são abordados na norma ISO 31000 como efeitos da incerteza sobre objetivos, portanto,
trazem uma definição ampla das diretivas recomendadas.
o ISO 31000 se direciona a fatores organizacionais para que uma empresa possa otimizar o
planejamento interno e a tomada de decisões para alcançar suas metas.
o Gerenciamento de riscos: O gerenciamento de riscos é de extrema importância para proteger a
operação de uma empresa, ao mesmo tempo que lhe agrega valor e a transforma em uma alternativa
de investimento valiosa para o mercado. 
o Atividade e Práticas recorrentes no PGR:
 Comunicação e consulta: O processo de comunicação e consulta envolve toda interação
da gestão de riscos que engloba a troca de informações, opiniões e mensagens. Comunicar e
consultar servirá para que, antes da tomada de decisões, a organização tome conhecimento
da posição e perspectiva dos seus membros. A comunicação interna de uma empresa é
determinante para seu sucesso, pois garante a qualidade geral das informações
compartilhadas.
 Monitoramento e análise crítica: Aqui, vemos um processo de supervisão e leitura dos
dados obtidos à medida que o processo de gerenciamento de riscos avança em uma
organização.
 Registro e relato: Finalmente, em registro e relato envolve a prestação de contas e
manutenção dos dados levantados para consultas futuras, disponibilizando-os para aqueles
interessados e participantes nos processos de decisão.
o Etapas do gerenciamento de riscos: Os processos recorrentes permeiam as etapas do gerenciamento
de riscos com base na ISO 31000, que se dá no seguinte formato:
 1. Escopo, contexto e critérios: Avaliando o contexto interno e externo, é desenhado um
escopo da gestão de riscos para a empresa, elencando seus critérios, objetivos e
 ambientação completa. É uma etapa inicial de grande importância, em que a comunicação
constante e a análise crítica dos dados apontados devem ser priorizados.
 2. Identificação de riscos: Para dar sequência ao processo de gestão de riscos, deve-se
questionar tudo que possa servir para identificar o risco, incluindo o que pode acontecer,
quando, onde, como e porquê.
 3. Análise de riscos: Na etapa de análise, é onde deve ser criada a matriz de gestão de
riscos, determinando as consequências dos riscos, probabilidade de acontecerem e o nível de
impacto sofrido pela organização em cada evento.
 4. Avaliação de riscos: Considerando a projeção da análise de riscos e os critérios
determinados para o seu gerenciamento por parte da empresa, se estabelecem as
prioridades e os riscos que demandam uma tratativa imediata.
 5. Tratamento de riscos: Por fim, temos a etapa de tratamento efetivo dos riscos, em que a
gestão de riscos baseada na ISO 31000 irá identificar as alternativas, analisar sua viabilidade
e eficiência, preparar um plano de contingência ou mitigação de riscos e avaliar a existência
de ameaças residuais.

o SOX ou Sarbannes Oxley

o foi sancionada no dia 30 de julho de 2002 por George W. Bush.
o responder às sucessivas fraudes financeiras cometidas por grandes organizações,
o objetivo de tornar mais transparentes os processos de prestação de contas e criar novos parâmetros
de compliance,
o Todas as empresas com ações listadas no Security and Exchange Comission (SEC), órgão dos
Estados Unidos responsável por regular o mercado de capitais, estão sujeitas à lei. Ela se aplica
também às empresas estrangeiras que possuem American Depositary Receipts (ADRs) nos níveis 2 e
3, certificados que permitem a negociação de títulos nas Bolsas de Valores norte-americanas.
o Objetivo: implementação de boas práticas de governança corporativa e uma prestação de contas
transparente por parte das empresas, resultando na correta divulgação de informações como receitas,
balanço patrimonial e despesas.
o Com a reestruturação de processos e o estabelecimento de mecanismos confiáveis de auditoria, a lei
tornou mais fácil a identificação e a prevenção de fraudes, reduzindo riscos, evitando a desconfiança
dos investidores e mantendo um sistema financeiro mais saudável.
o SOx determina que os Diretores Executivos e Financeiros têm o papel não só de implementar, como
também de fiscalizar cada etapa do processo de governança, garantindo que todos os relatórios e
informações divulgadas sejam verídicos.
o Características da SOX:
 Dividida em 11 capítulos e 69 artigos, a lei tem alguns pontos a serem destacados.
 Artigo 102: Criação e o papel da Public Company Accounting Oversight Board (PCAOB),
órgão responsável por supervisionar e desenvolver as normas para os processos de auditoria
das empresas.
 103 define as regras para os processos de auditoria, a independência dos auditores e o
controle de qualidade.
 artigo 201 determina os serviços proibidos para os auditores na organização auditada,
 artigo 204 regula a comunicação entre auditores terceirizados e o comitê de auditoria da
empresa contratante.
 artigo 302 fala sobre as funções dos diretores, a quem é atribuída a responsabilidade de
atestar a veracidade de todas as informações, além de declarar todos os pontos fracos nos
processos de prevenção à fraude da organização.
 O artigo 303 proíbe que qualquer funcionário exerça alguma influência sobre o auditor, e o
305 especifica as penalidades impostas aos diretores.
 O artigo 307 atribui aos advogados a obrigatoriedade de relatar qualquer evidência de
violação da empresa para a qual trabalham, devendo reportar aos diretores e ao comitê de
auditoria.
 Artigo 401: determina que as empresas divulguem, de forma trimestral e anual, as
informações de todo fato material que não estão relacionadas com o balanço patrimonial,
como acordos e transações.
 Artigo 402: torna obrigatória a divulgação das transações entre a diretoria da empresa e seus
principais acionistas.
 Artigo 404: determina a realização de avaliações anuais dos processos e controles internos
da empresa para emissão de relatórios contábeis e financeiros.
 Artigo 802: estabelece penas para casos de alteração, destruição ou falsificação de
documentos.
 Artigo 807: estabelece penas em casos onde há prejuízos aos acionistas minoritários de
empresas de capital aberto, devido a informações falsas.
 Artigo 906: Aumenta a responsabilidade dos diretores financeiros em relação à fiscalização,
além de definir as penalidades para as infrações.

4.17 Políticas de Segurança de Informação.

 Não, com elaboração da Política de Segurança de Informação não se tem o encerramento do ciclo. As ISOs
abordam a política de segurança numa perspectiva de melhoria contínua, ou seja o processo é realizado de
forma contínua e não se encerra com elaboração da Política de Segurança de Informação.
 Assegurar os recursos necessários para a gestão da política de segurança da organização é atribuição da
alta direção, como forma de demonstrar comprometimento e liderança.
 No processo de verificação, análise crítica e avaliação da continuidade da segurança da informação,
recomenda-se, quando possível, integrar a verificação dos controles da continuidade da segurança da
informação com os testes de recuperação de desastre ou da continuidade dos negócios da organização.
 Propriedades Básicas de Segurança da Informação: DICAN-R
o Disponibilidade: informação acessível 24h/7.
o Integridade: pressupõe a garantia de não violação dos dados.
o Confidencialidade: garante que a somente pessoas autorizadas tenham acesso às informações.
o Autenticidade: veracidade da fonte das informações, ou seja, garante a identidade de quem está
solicitando o acesso.
o Não-Repúdio: o usuário que gerou ou alterou a informação, não pode negar a autoria.

4.18 Classificação de informações.

4.19 Norma ISO 27002, Criptografia, certificação digital e assinatura digital

 Criptografia
o Compete à infraestrutura de chaves públicas brasileira (ICP-Brasil) o papel de
credenciar e descredenciar participantes da cadeia de certificação.
o Criptografia simétrica: Tanto quem envia quanto quem recebe a mensagem
devem possuir a mesma chave criptográfica (privada), a qual é usada para
criptografar e descriptografar a informação.
 Simétrica tem um (1) "s" , ou seja, uma chave.
 Chave significa uma senha ou código que é gerado por meio de um
programa conhecido como servidor PGP. PGP = Privacidade Muito Boa.
 A criptografia é uma ferramenta de conferência.
 A chave utilizada na criptografia sempre será do destinatário.
 Chave privada: privada no que se refere ao grau de acesso, ou seja,
apenas o seu dono a conhece e não a divulga.
 IMPORTANTE: Chave privada=criptografa / Chave
Pública=Descriptografa
 Chaves Única
 Funcionamento Mesma chave cifra e decifra
 Processamento Veloz
 SEGURANÇA DE SISTEMA CRIPTOGRÁFICO SIMÉTRICO -
Características:
 a. força dos algoritmos
 b. comprimento da chave
 Gerenciamento das chaves Complicado, uma chave para cada usuário
 Ataques de força bruta são perigosos
 Exemplos de algoritmos simétricos: (E são CIFRA DE BLOCOS)
 DES: chave de 56 bits de força efetiva: Bloco 64 bits/8 bits
paridade e já foi quebrado
 AES (Substituiu o DEScartável) Bloco:128 bits/Chave:128,192
ou 256 bits
 Twofish;
 Serpent;
 Blowfish;
 CAST5;
 RC4 (Cifra de Fluxo ou Stream Cipher);
 OTP (Cifra de Fluxo ou Stream Cipher)
 3DES (baseado no DES);
 IDEA.
o Criptografia Assimétrica: Esse tipo de criptografia usa um par de chaves
diferentes (pública e privada, ou seja, 2 chaves).
 Uma consegue decifrar o que foi cifrado pela outra.
 Assimétrica tem dois (2) "ss", ou seja, duas chaves.
 Vantagem: A chave privada se mantém protegida e é só do
conhecimento do seu titular.
 Desvantagem: Seu desempenho é mais lento em consequência de
utilizar um processo algorítmico mais complexo.
 Chave pública: pública no que se refere ao grau de acesso, ou seja,
todos conhecem ou têm acesso a essa chave. Até mesmo o invasor a
conhece? Sim, pois ela é utilizada apenas para criptografar mensagens.
Só é possível decifrar a mensagem com a chave privada.
 A chave privada SOMENTE o DESTINATÁRIO possui.
  Chaves Pública (divulgada livremente) Privada(secreta)
 Funcionamento Chave pública cifra/codifica a mensagem e chave
privada decifra/decodifica
 Processamento Lento
 Gerenciamento das chaves Simples, basta divulgar a chave pública
 Ataques de força bruta São ineficazes (números primos muito grandes)
 Principais algoritmos assimétricos que utilizam chaves públicas:
 Diffie-Hellman; Usa a tecnologia de chave pública para gerar a
chave de sessão simétrica em vez de envelopá-la. Possibilita o
acordo de chaves sem o envio da mesma. É um protocolo de
criptografia, mas não é considerado um sistema criptográfico.
Tem como objetivo fazer a troca de chaves simétricas de
maneira segura em um meio inseguro. Não tem como
função cifrar e decifrar mensagens. É usado em protocolos de
rede seguros como o IPSec. O algoritmo DH (Diffie-Hellman)
efetua troca de chaves e não suporta assinatura digital.
 RSA (faz uso de chaves públicas e privadas, que são
distintas.) O algoritmo criptográfico RSA, assim como outros
sistemas de criptografia de chave pública, é sensível a um
ataque de temporização. Uma das contramedidas que pode
ser usada consiste em multiplicar o texto cifrado por um
número cifrado antes de realizar a exponenciação. Esse
recurso é conhecido como OFUSCAÇÃO (multiplica o texto
cifrado por um número aleatório antes da exponenciação.). O
RSA é suscetível a um ataque conhecido como ataque de
Wiener, que pode expor a chave privada de um sistema
criptográfico RSA se os parâmetros utilizados para definir a
chave privada forem considerados pequenos, e
consequentemente, tido como matematicamente inseguros.
 Merkle-Hellman;
 SSL.
 O sistema de criptografia assimétrica funciona da seguinte forma:
 O servidor e o cliente geram as suas chaves públicas e
privadas. O servidor envia para o cliente sua chave pública, e
o cliente envia para o servidor sua chave pública.
 O cliente criptografa seus dados com a chave pública (do
servidor), e envia para o servidor.
 O servidor descriptografa os dados com a sua chave privada.
 O servidor criptografa o que será enviado para o cliente com a
chave pública do cliente, e envia para o cliente.
 O cliente consegue, por fim, descriptografar o retorno do
servidor, com sua chave privada.
o O resultado da função hash criptográfica será sempre do mesmo tamanho, fixo,
independente do tamanho da mensagem que seja aplicada. Aí só vai variar de
acordo com o método de hash que utilizar.
o ATENCAO: Se o enunciado fala chave pública = é criptografia assimétrica e
garante confidencialidade / chave privada=é criptografia simétrica garanto
autenticação
o O sistema criptográfico pode usualmente alterar a chave privada de um usuário,
gerando uma nova chave pública correspondente. Como princípio de um sistema
de criptografia com base em chave pública e privada, para cada usuário é gerado
um par de chaves para ser usado na encriptação e na decriptação de mensagens.
A qualquer momento, um sistema pode alterar sua chave privada e publicar uma
chave pública correspondente para substituir a antiga.
o HASH é um RESUMO/COMPACTAÇÃO: Se vc tem um dado e usa a função hash
nele, ele gera um código(resumo). Logo, se vc usar novamente a função hash e
gerar o mesmo código, garante a INTEGRIDADE. Dados sobre os quais tenha sido
calculado um valor de hash criptográfico com determinado algoritmo têm garantia
de sua integridade sempre que, em qualquer tempo, um novo cálculo de hash
desses dados com emprego do mesmo algoritmo resultar idêntico ao valor
inicialmente calculado.
o Chave pública é uma chave de descriptografia conhecida por todos.
o A função hash, utilizada para garantir integridade e autenticidade dos dados, gera,
a partir de uma entrada de qualquer tamanho, uma saída de tamanho fixo; caso
dois arquivos tenham o mesmo conteúdo, mas nomes diferentes, os valores do
hash MD5 serão iguais, ou seja, arquivos idênticos (mesmo contéudo) com nomes
diferentes geram o mesmo código hash.
o Uma função hash criptográfica é um algoritmo de encriptação de mão única, ou
seja, muito difícil de inverter.
 o A complexidade e o tamanho das chaves de criptografia são medidos em bits e
quanto maior o número, mais elevada será a segurança. Para uma chave de 256
bits, significa que 2 ^ 256 é o número de chaves possíveis para quebrar a senha, e
mesmo utilizando os computadores com maior poder computacional, ainda sim,
levar-se-iam bilhões de bilhões de anos para varrer todas as possibilidades. 64 bits
= chave fraca / 128= segurança de rotina / 256= considerado seguro
o Em se tratando de chaves simétricas (tema da questão), de fato, o que pode definir
o grau de segurança é o tamanho da chave, pois quanto maior, mais difícil de ser
quebrada. 
o O algoritmo criptográfico RC4, cifra de fluxo com tamanho de chave variável, é
utilizado nos padrões SSL/TLS (secure socket layer / transport layer security)
definidos para a comunicação entre programas navegadores e servidores web.
(CERTO) Vale lembrar que este padrão não é mais utilizado nos padrões SSL/TLS
devido segurança. Foi substituído por proxima questão abaixo:
o Protocolo SSL ou TLS utilizam criptografia assimétrica (chave pública + chave
privada). Confidencialidade e Integridade.
 Início da Conexão: É estabelecida uma conexão de chaves
assimétricas, dentro dessa conexão é compartilhada uma chave
simétrica que será utilizada posteriormente;
 Troca de Dados: os dados são transmitidos criptografados com a chave
simétrica compartilhada no início da conexão. Isso se deve ao fato de a
criptografia simétrica ser muito menos dispendiosa computacionalmente
em relação a criptografia assimétrica.
o Se, para criptografar a disponibilização de um sítio, tiver sido utilizado o HTTPS,
então a criptografia utilizada nesse ambiente é assimétrica pois O HTTPS utiliza a
criptografia híbrida, ou seja, ele usa a criptografia assimétrica apenas para a troca
de chaves públicas e privadas.
o EVITAR COMUNICAÇÃO INSEGURA EM WEB
 aceitar apenas criptografias fortes
 não aceitar protocolos de segurança criados por usuários particulares
o Tanto o protocolo TLS quanto o SSL, seu sucessor (ERRADO pois o TLS é
sucessor do SSL), protegem grande parte das comunicações seguras na Internet,
apesar de uma vulnerabilidade na versão 3.0 do TLS permitir a execução de um
ataque denominado poodle.
o ESTEGANOGRAFIA: técnica para ocultar uma mensagem dentro de outra, de
forma que não sejam percebidas por terceiros.OCULTA O CONTEÚDO
o CRIPTOANÁLISE: é a arte de tentar descobrir o texto cifrado e/ou a lógica
utilizada em sua encriptação (chave). As pessoas que participam desse esforço
são denominadas criptoanalistas. TORNAR O TEXTO CLARO
o CRIPTOGRAFIA: A Criptografia é a técnica de tornar uma mensagem ininteligível!
DEIXAR O TEXTO ININTELIGÍVEL
o Duas técnicas Clássicas de Criptografia:
 Técnica de SUBSTITUIÇÃO: Cada letra ou grupo de letra é trocado por
outro. É um DISFARCE
 Exemplo: CASA A-> E C->L S-> V Então teremos um disfarce,
aparece LEVE, mas na verdade é CASA
 Técnicas:
o Cifra de César
o Cifra Monoalfabética
o Cifra Playfair
o Cifra de Hill
o Cifras Polialfabéticas -> Cifra de Vigénere
o One-Time Pad
 Técnica de TRANSPOSIÇÃO: Reordena as letras, não as
DISFARÇAM. Na questão: mudança na posição de letras ou palavras
 Exemplo: CASA ---> SACA
 Técnicas:
 Máquinas de Rotor
 Esteganografia (Não é criptografia, mas é uma técnica
considerada para ocultar texto)
 Cifra em Rail Fence

 Certificado Digital
 CERTIFICADO DIGITAL UTILIZA CRIPTOGRAFIA ASSIMÉTRICA: Um certificado
digital utiliza criptografia assimétrica utilizando uma chave pública e privada, é uma
implementação do protocolo HTTP sobre uma camada SSL ou TLS..HTTPS ->
criptografia assimétrica; usa chave pública e privada.
 CERTIFICADO DIGITAL é a identidade eletrônica de uma pessoa ou empresa. Ele
funciona como uma carteira de identificação virtual.
 ASSINATURA DIGITAL é como se fosse uma RUBRICA digital. está ligada a
Autenticidade / Integridade e NÃO repúdio. Para verificação de ORIGEM utiliza-se
a ASSINATURA DIGITAL.
 ASSINATURA DIGITAL é diferente de ASSINATURA DIGITALIZADA
 Simples! A banca está falando sobre o conceito de ASSINATURA DIGITAL.
 Certificado Digital → Verifica a confiabilidade da pessoa.
 Assinatura Digital → Técnica criptográfica; Autentica documentos.
 O objetivo do certificado digital é identificar o emissor da mensagem, agora se ele
é ou não responsável pela empresa é outra história.
 Certificado A1/S1 - Tamanho chave: 1024 bits - Geração chave: Software -
Armazenamento: repositório protegido por senha no pc mesmo - Validade: 1 ano
 Certificado A2/S2 - Tamanho chave: 1024 bits - Geração chave: Software -
Armazenamento: Smart/token sem capacidade de gerar chave - Validade: 2 anos
 Certificado A3/S3 - Tamanho chave: 1024 bits - Geração chave: Hardware -
Armazenamento: Smart/token com capacidade de gerar chave - Validade: 1 a 5
anos.
 Um certificado digital consiste em uma chave pública associada a um identificador
do proprietário da chave, sendo assinado por uma autoridade certificadora.
 ICP brasil – Órgão que regula a emissão de certificados digitais
o Primeira Autoridade da cadeia de certificados
o Compete: Emitir, expedir, distribuir, revogar e gerenciar os certificados
das Autoridades Certificadoras.
o Fiscalizar e auditar – AC, AR e demais prestadores de serviços.
 AC – Autoridade Certificadora “entidade pública ou privada”
o Subordinada a hierarquia da ICP Brasil.
o Compete: Emitir, distribuir, revogar e gerenciar certificados digitais ou
seja, chave pública
o Emitir lista de certificados revogados e não confiáveis – LCR (lista negra
de arquivo eletrônico com numero de série dos certificados que não são
mais válidos e a data da revogação.)
o Ex: SRF, Serasa, Correios, Caixa Economica
 AR – Autoridade de Registro.
o Interface com o usuário e a autoridade certificadora.
o Recebe, Valida e encaminha as solicitações emissões ou revogações.
o Identifica de forma presencial de seus solicitantes.
o manter registro de suas operações.
 No padrão X.509, é possível verificar a validade geral de um certificado digital por
meio da consulta à lista de certificados revogados.
 Um certificado digital contém, além de atributos específicos do usuário, uma chave
pública, assinada digitalmente por entidade confiável, responsável pela emissão do
certificado ou pela autenticação da entidade emissora. Correto
 Um certificado digital contém, entre outros aspectos, a chave privada do emissor
do certificado para que seja possível a verificação da chave pública. Errado
 Um certificado digital consiste em uma chave pública associada a um identificador
do proprietário da chave, sendo assinado por uma autoridade certificadora. CERTA
 Por padrão, um certificado digital contém a chave privada do emissor do
certificado; a chave pública é sempre acessada para fins de comprovação da
chave privada. Errado
 Certificados digitais são empregados para assinatura de documentos digitais que
podem ser transmitidos pela Internet, porém podem ser utilizados para autenticar
usuários em sistemas na Internet.
 LEMBRETE:
o CertIficAdo Digital ➜ CIA ➜ Confidencialidade, Integridade,
Autenticidade;
o Quem assina - AssINAtura Digital ➜ INA ➜ Integridade, Não-repúdio,
Autenticidade
 É obrigatório o preenchimento dos seguintes campos do Certificado Digital, com as
informações do Titular do Certificado.
o a) nome completo, sem abreviações;
o b) data de nascimento;
o c) demais campos definidos como obrigatórios na Política de Certificado-
PC.
 Cabe ao Titular, de acordo com a Política de Certificado – PC da Autoridade
Certificadora - AC, informar os documentos de preenchimento facultativo para a
emissão do Certificado Digital. O não preenchimento dos campos facultativos pode
 impossibilitar a sua utilização em aplicações que os exijam. 3.2.1 O Titular declara
ter ciência que o Certificado Digital é um documento eletrônico de caráter público e
seu uso pressupõe a disponibilização de todos os dados nele contidos.
 As funções do HSM (Hardware Security Module):
o Geração segura de chaves: nessa função o importante é que as chaves
são geradas e armazenadas dentro do equipamento, o que garante um
nível de segurança maior, já que as chaves ficam, desde a sua geração,
apenas dentro do HSM;
o uma vez gerada a chave dentro do HSM, ou importada para ele, essa
chave será armazenada e pode ser gerenciada pelos responsáveis pelas
chaves. Essas pessoas podem variar dependendo da organização e de
sua política de segurança da informação;
o Funções criptográficas, como assinatura digital e por exemplo.
 Existem diversas aplicações que podem utilizar o HSM, como:
o PKI geração e armazenamento de chaves;
o Segurança de comunicação SSL/TLS;
o Assinatura de código;
o Validação e assinatura de certificado digital;
o Assinatura Digital de Documentos;
o Criptografia de Base de Dados, VMs e arquivos
 Uma forma de proteger chaves criptográficas com um dispositivo de computação
física é armazená-las em um equipamento do tipo HSM (hardware security
module). CERTO
 Qualquer usuário pode verificar a autenticidade da entidade que gerou um
certificado digital, inclusive as informações e a chave pública do proprietário do
certificado.
 Considerar comprometido o certificado digital da autoridade certificadora é uma
das razões para a revogação de um certificado digital de usuário antes da sua data
de expiração. Motivos de revogação: abuso, Chave privada exposta; Chave
privada da CA exposta;

 ASSINATURA DIGITAL
o Um par de chaves ECDSA consiste em uma chave privada 'd' e uma chave pública
'Q' que está associada a um conjunto específico de parâmetros de domínio
ECDSA; d, Q e os parâmetros do domínio são matematicamente relacionados
entre si.
o A chave privada é normalmente usada por um período de tempo (ou seja, o
criptoperíodo); a chave pública pode continuar a ser usada enquanto as
assinaturas digitais que foram geradas usando a chave privada associada
precisam ser verificadas (ou seja, a chave pública pode continuar a ser usada
além do criptoperíodo da chave privada associada). Ou seja resumindo tudo:
 A chave privada é normalmente usada por um período de tempo (ou
seja, o criptoperíodo);
 a chave pública pode continuar a ser usada além do criptoperíodo da
chave privada associada.
o A assinatura digital foi desenvolvida especialmente com o objetivo de prover
integridade, autenticidade e não-repúdio. Para criá-la, basta que o emissor gere
um hash da mensagem enviada e cifre esse código hash com sua chave privada.
o Algoritmos usados na função HASH da assinatura digital - MD5(128bits), SHA-
1(160 bits). De fato, ambos foram considerados inseguros em virtude de falha em
resistência à colisão: Tal característica permite que dois algoritmos provenientes
de mensagens diferentes não gerem um mesmo código HASH. Quando duas
mensagens diferentes geram códigos HASH iguais, ocorre falha em resistência à
colisão.
o Para verificar a integridade de uma mensagem com assinatura digital, a pessoa
que a recebeu deverá conhecer a chave pública do usuário que a enviou.
o Como funciona Assinatura digital
 1º MENSAGEM É ESCRITA PELO EMISSOR
 2º É CIFRADA COM A CHAVE PRIVADA DO EMISSOR=> ASSINA
 3º A MENSAGEM É ENVIADA AO DESTINO
 4º E DECIFRADA COM A CHAVE PÚBLICA DO EMISSOR.=>
VERIFICA E PROVA ASSINATURA
o Uma assinatura digital direta é formada criptografando-se a mensagem inteira, ou
um código de hash da mensagem, com a chave privada do emissor da
mensagem. CERTO
o Para verificar a integridade de uma mensagem com assinatura digital, a pessoa
que a recebeu deverá conhecer a chave pública do usuário que a enviou. CERTO
o A assinatura digital permite, de forma única e exclusiva, a confirmação da
autoria de um determinado conjunto de dados. Esse método de autenticação
 comprova que a pessoa criou ou concorda com um documento assinado
digitalmente. A verificação da origem dos dados é feita com A CHAVE PUBLICA
DO REMETENTE. CERTO
o A assinatura digital utiliza funções resumo (message digest) de uma via.
o No contexto de uma infraestrutura de chaves públicas, um documento eletrônico
assinado digitalmente com a chave pública do remetente falhará na verificação de
integridade e autoria pelo destinatário, caso essa verificação seja realizada com a
aplicação da mesma chave pública do remetente.
 NORMA ISO 27002:
o ISO/IEC 27002 é um código de práticas com um conjunto completo de controles
que auxiliam aplicação do Sistema de Gestão da Segurança da Informação.
o A norma da Associação Brasileira de Normas Técnicas (ABNT) ISO/IEC
27005/2008 fornece diretrizes e descreve um processo genérico para a Gestão de
Risco de Segurança da Informação de uma organização.
o " 8.3.1. Gerenciamento de mídias removíveis
o g) as mídias removíveis sejam registradas para limitar a oportunidade de
perda de dados;
o h) as unidades de mídias removíveis sejam habilitadas somente se houver
uma necessidade do negócio; "
o A.9.2.3 Segurança do cabeamento
 Controle: O cabeamento de energia e de telecomunicações que
transporta dados ou dá suporte aos serviços de informações deve ser
protegido contra interceptação ou danos.
o "8.2.2 Conscientização, educação e treinamento em segurança da informação
 Convém que todos os funcionários da organização e, onde pertinente,
fornecedores e terceiros recebam treinamento apropriados (não
precisa ser avançado) em conscientização, e atualizações regulares
nas políticas e procedimentos organizacionais, relevantes para as suas
funções.
 O treinamento para aumentar a conscientização visa permitir que as
pessoas reconheçam os problemas e incidentes de segurança da
informação, e respondam de acordo com as necessidades do seu
trabalho."
 *Portanto, a ideia do treinamento descrito na norma 27002 é
conscientizar sobre a segurança, e não desenvolver habilidades
técnicas e específicas.
o Políticas de segurança relacionadas a trabalho remoto devem reafirmar o direito
das organizações de realizar acessos intempestivos para verificações de
segurança em equipamentos de propriedade particular que se conectem a sua
rede para a realização desse tipo de trabalho, sendo tais acessos permitidos
independentemente de qualquer legislação vigente sobre privacidade. (ERRADO
pois não há nenhuma politica relacionados sobre a privacidade de propriedade
particular)
o É importante que a análise crítica de uma política de segurança da informação
tenha um enfoque no gerenciamento da segurança da informação em resposta às
mudanças das condições legais e das circunstâncias do negócio.

4.20 Conceitos de segurança em nuvem.

Sete princípios de segurança em uma rede em nuvem:

 Acesso privilegiado de utilizador (usuário) - A sensibilidade de informações confidenciais

nas empresas obriga um controle de acesso dos utilizadores e informação bem específica de
quem terá privilégio de administrador, para que então esse administrador controle os
acessos;
 Compliance com regulamentação - As empresas são responsáveis pela segurança,
integridade e a confidencialidade de seus próprios dados. Os fornecedores de computação
em nuvem devem estar preparados para auditorias externas e certificações de segurança;
 Localização dos dados - A empresa que usa cloud provavelmente não sabe exatamente
onde os dados estão armazenados, talvez nem o país onde as informações estão
guardadas. O fornecedor deve estar disposto a se comprometer a armazenar e a processar
dados em jurisdições específicas, assumindo um compromisso em contrato de obedecer os
requerimentos de privacidade que o país de origem da empresa pede;
 Segregação dos dados - Geralmente uma empresa divide um ambiente com dados de
diversos clientes. Procure entender o que é feito para a separação de dados, que tipo de
criptografia é segura o suficiente para o funcionamento correto da aplicação;
 Recuperação dos dados - O fornecedor em cloud deve saber onde estão os dados da
empresa e o que acontece para recuperação de dados em caso de catástrofe. Qualquer
aplicação que não replica os dados e a infraestrutura em diversas localidades está vulnerável
 a falha completa. Importante ter um plano de recuperação completa e um tempo estimado
para tal;
 Apoio à investigação - A auditabilidade de atividades ilegais pode se tornar impossível na
computação em nuvem uma vez que há uma variação de servidores conforme o tempo onde
estão localizados os acessos e os dados dos utilizadores. Importante obter um compromisso
contratual com a empresa fornecedora do serviço e uma evidência de sucesso no passado
para esse tipo de investigação;
 Viabilidade em longo prazo - No mundo ideal, o seu fornecedor de computação em nuvem
jamais vai falir ou ser adquirido por uma empresa maior. A empresa precisa garantir que os
seus dados estarão disponíveis caso o fornecedor de computação em nuvem deixe de existir
ou seja migrado para uma empresa maior. Importante haver um plano de recuperação de
dados e o formato para que possa ser utilizado em uma aplicação substituta.

4.21 Segurança em IoT.

 A atual geração de dispositivos IOT (Internet das coisas) não foi concebida com foco em
segurança do software, o que os torna candidatos prováveis a integrar gigantescas botnets
que, entre outras atividades rentáveis, podem ser usadas para acelerar quebras de senhas
para invadir contas online, minerar bitcoins e realizar ataques de negação de serviço sob
encomenda.

 O ciclo de vida de desenvolvimento da segurança (SDL, Security Development Lifecycle) é

um processo de desenvolvimento de software que ajuda a fazer isso. Ele consiste em sete
fases, incluindo:

o Fase de treinamento: conceitos básicos para a criação de software seguro, que

incluem design seguro, modelagem de ameaças, codificação segura, testes de
segurança e práticas recomendadas relacionadas à
o Fase de requisitos: a fase inicial do projeto é o momento ideal para considerar e
estabelecer as questões básicas de segurança e privacidade de seu projeto,
incluindo as exigências regulamentares.
o Fase de design: nem todos os recursos de software são seguros; portanto, crie
um design com base nos pontos fortes e adicione mais camadas de segurança
onde fizer mais sentido.
o Fase de implementação: use ferramentas aprovadas, remova todas as funções
não seguras e realize as análises adequadas durante essas fases.
o Fase de verificação: use essa fase para garantir que seu código atenda aos
princípios de segurança e privacidade estabelecidos nas fases de design e de
requisitos.
o Fase de lançamento: crie um plano para monitorar incidentes de segurança e
responder a eles rapidamente
o Fase de resposta: execute seu plano de resposta a incidentes.

5. Governança de TI.
5.1 Modelos de governança de Tecnologia da Informação: características, objetivos e benefícios.

o Características da governança de TI:

o Um dos objetivos da governança de TI é possibilitar o alinhamento das
atividades da equipe de TI com as prioridades das demais áreas de negócios
da empresa.
o As ferramentas GUT (gravidade, urgência e tendência), o Diagrama de Pareto e a
Curva de Tendência fornecem suporte à atividade do planejamento estratégico de
filtrar informações de interesse da organização.
o A governança de TI busca o alinhamento com o negócio da organização por meio
de dois grandes objetivos: entrega de valor e mitigação de riscos através de
gerenciamento de recursos e pelo monitoramento do desempenho de TI.
o A governança corporativa de TI envolve a avaliação e a direção do uso da TI para
dar suporte à organização no alcance de seus objetivos estratégicos e monitorar
seu uso para realizar os planos. A governança inclui a estratégia e as políticas
para o uso de TI dentro de uma organização.
o A “Governança Corporativa” tem foco no direcionamento e monitoramento da
gestão da instituição, e busca permitir a intervenção dos responsáveis finais
sempre que houver desvio em relação ao esperado.
o
o Os fatores importantes para avaliação da Governança são as 5 áreas foco da
Governança do Cobit:
 Alinhamento estratégico
 Entrega de valor
 Gerência de risco
  Gerência de recursos
 Mensuração de desempenho
o A governança de TI é de responsabilidade da alta administração (incluindo
diretores e executivos), na liderança, nas estruturas organizacionais e nos
processos que garantem que a TI da empresa sustente e estenda as estratégias e
os objetivos da organização."
o Segundo Aragon(2012,p.10,figura 1.2):
 Quando a TI tem alto impacto nas operações chaves (presente) e alto
impacto nas estratégias chaves (futuro), diz-se que a TI é estratégica
para o negócio.
 Quando a TI tem alto impacto nas operações chaves e baixo impacto
nas estratégias chaves, tem a conotação de uma Fábrica para o
negócio, ou seja, o dia a dia do negócio depende da TI, mas o seu futuro
não.
 Quando a TI tem baixo impacto nas operações chaves e baixo impacto
nas estratégias chaves, diz-se que ela está executando apenas tarefas
de suporte, não sendo, do ponto de vista dos dirigentes, essencial para o
negócio.
 Quando a TI tem baixo impacto nas operações chaves e alto impacto
nas estratégias chaves, diz-se que ela está exercendo um papel de
mudança, ou seja, está apoiando fortemente o direcionamento futuro da
organização.
o Segundo Aragon(2012,p.7,figura 1.1),"Os fatores motivadores da governança de
TI são:
 -a TI como prestadora de serviços;
 -a integração tecnológica;
 -a segurança da informação;
 -a dependência do negócio em relação à TI;
 -os marcos de regulação;
 -o ambiente de negócios."

Os quatros modelos de governança de TI:

o COBIT 5: (CAI NA PROVA)

o COBIT são as siglas para (Control Objectives for Information and Related Technology)
em outras palavras é um dos modelos mais requeridos voltados a dinâmica de
governança de TI, isso pois é um facilitador de controle, além de auxiliar o
gerenciamento do uso dos meios tecnológicos da corporação.
o Seu objetivo, visa a permissão das empresas no que diz respeito a gerenciar de maneira
eficiente seus investimentos em tecnologia, com intuito de maximizar: benefícios,
oportunidades de negócio e vantagens competitivas de mercado.
o O COBIT tem foco nos negócios, é orientado a processos e embasado em controles
definidos a partir da operação de cada processo de TI. As informações de controle são
utilizadas na verificação de objetivos preestabelecidos e na melhoria dos processos.
o O Cobit provê métricas e modelos de maturidade para a medição da eficácia da ligação
dos processos de negócios aos processos de TI e, com isso, contribui para a governança
de TI.
o Para adotar esta metodologia é necessário o foco em quatro pilares/domínio:
 planejamento e organização,
 aquisição e implementação,
 Aquisição de soluções de TI
 entrega e suporte,

DS1 Definir e Gerenciar Níveis de Serviço 6 OC

DS2 Gerenciar Serviços de Terceiros 4 OC

DS3 Gerenciar Capacidade e Desempenho 5 OC

DS4 Assegurar Continuidade de Serviços 10 OC

DS5 Assegurar a Segurança dos Serviços 11 OC

DS6 Identificar e Alocar Custos 4 OC

DS7 Educar e Treinar Usuários 3 OC

 DS8 Gerenciar a Central de Serviço e os Incidentes 5 OC

DS9 Gerenciar a Configuração 3 OC

DS10 Gerenciar os Problemas 4 OC

DS11 Gerenciar os Dados 6 OC

DS12 Gerenciar o Ambiente Físico 5 OC

DS13 Gerenciar as Operações 5 OC


 entrega ou desenvolvimento de soluções de TI e suporte
para executar a estratégia de TI
 monitoramento e avaliação.

ME
Monitorar e Avaliar o Desempenho 6 OC
1

ME
Monitorar e Avaliar os Controles Internos 7 OC
2

ME Assegurar a Conformidade com Requisitos

5 OC
3 Externos

ME
Prover a Governança de TI 7 OC
4
 O processo assegurar conformidade com requisitos externos
pertence ao domínio planejamento e organização. (ERRADO)
o O modelo conta com a aplicação de diversas boas práticas para o controle da
informação, desde o planejamento até o monitoramento.
o Benefícios:
 Aumento da eficiência do TI
 Melhora a segurança da informação
 Otimiza aos investimentos no setor
 Cria uma linguagem comum
o Critérios necessários à informação (que é recurso de TI)
 Integridade
 disponibilidade
 confiabilidade
 Autenticidade (NÃO)
o Grau de maturidade:
 Nível 0: Processo incompleto ‐ O processo não foi implementado ou não
cumpre sua finalidade.
 Nível 1: Processo Executado/Realizado – O processo implementado atinge
a finalidade do processo (mas não é gerenciado)
 Nível 2: Processo Gerenciado – O processo é implementado de forma
gerenciada (planejado, monitorado e ajustado) e seus produtos do trabalho
são adequadamente estabelecidos, controlados e mantidos.
 Nível 3: Processo Estabelecido – O processo é implementado usando um
processo definido capaz de atingir os resultados do processo.
 Nível 4: Processo Previsível – O processo opera com limites definidos,
atingidos nos resultados do processo.
 Nível 5: Processo Otimizado – O processo é continuamente melhorado de
modo a atender os objetivos corporativos pertinentes, atuais ou previstos.
o O modelo mais recente do COBIT possibilita a parceria com outros
frameworks, como ITIL. Além disso, tem como diferencial a adição dos
frameworks Val IT (alinha os processos de negócio e responsabilidades para
a criação de valor empresarial) e Risk IT. (fornece uma visão do negócio sobre
o gerenciamento de riscos).
o Os cincos princípios do COBIT: Cinco princípios garantem a concretização de
uma visão holística da empresa sobre as contribuições de TI.
 1- Atender todas as necessidades das partes envolvidas: Para satisfazer o
alinhamento estratégico, deve-se orientar as metas de TI em conformidade
 com as metas empresariais. O COBIT 5 tabelou informações genéricas a esse
respeito, e sugere a reavaliação dos objetivos estratégicos para a certeza
dessa equivalência.
Como cada organização tem suas particularidades, é preciso saber dos
processos da empresa para atender às suas necessidades da melhor maneira
possível. Por isso, o COBIT 5 consegue traduzir os objetivos corporativos para
o setor de TI. O uso do Balanced Scorecard (BSC) cumpre esse pré-requisito.
É esse o indicador que mostra se todos os stakeholders estão realmente
envolvidos nos procedimentos.
 2- Cobrir a organização de ponta à ponta: O COBIT 5 abrange toda a
governança corporativa com o intuito de unir a empresa nas tomadas de
decisão. Portanto, é de se esperar que toda a corporação seja envolvida nos
procedimentos.Para tanto, informações e tecnologias de todos os setores são
tratadas como ativos que devem ser gerenciados pelos respectivos gestores.
O time de TI oferece apenas um auxílio. São os líderes de cada equipe quem
tem a visão clara sobre o impacto de cada recurso. Com uma matriz de
responsabilidades, os papéis são distribuídos e monitorados.
 3- Implantar um modelo único: Uma das características do COBIT 5 é que
ele está alinhado com as normas e frameworks mais recentes utilizadas por
organizações do mundo todo, como ITIL, COSO, ISSO27001, TOGAF, Prince
2 e Six Sigma. Estamos falando de um framework completo para governança
empresarial de TI. Do planejamento às entregas, a filosofia que rege as ações
postas em prática pelo modelo é a de total agrupamento de conceitos de TI.
 4- Permitir uma abordagem holística: O COBIT 5 tem sete facilitadores que
trabalham em conjunto para apoiar a implementação de sistemas abrangentes
em organizações, que são:
 Processos;
 Princípios, políticas e modelos;
 Estruturas organizacionais;
 Cultura, ética e comportamento;
 Informação;
 Serviços de TI, infraestrutura e aplicativos;
 Pessoas, habilidades e competências.

A interatividade entre todos esses pontos é o fator regente da visão

integrada.
 5- Separar Governança e Gestão: Esta versão declara a separação dos
conceitos governança de TI e gerenciamento de TI: enquanto um é disposto
pelo modelo Evaluate, Direct and Monitor (ISSO/IEC38500), o outro assegura
o condicionamento das metas a avaliações de necessidade, com
monitoramento de desempenho, conformidade e progresso dos
planejamentos. As duas áreas englobam muitos tipos de atividades e, por
conta disso, exigem diferentes tipos de estruturas organizacionais que servem
para diversos propósitos.
o Matriz RACI (Matriz de Responsabilidade e Controle):
 R: Responsável por executar uma atividade (o executor);
 A: Autoridade, quem deve responder pela atividade, o dono (apenas uma
autoridade pode ser atribuída por atividade);
 C: Consultado, quem deve ser consultado e participar da decisão ou atividade
no momento que for executada;
 I: Informado, quem deve receber a informação de que uma atividade foi
executada.
o Val IT:
o O Val IT (Value of Information Technology) foi desenvolvido, com o intuito de contribuir
com os gestores a garantir que empresas obtenham o máximo de retorno, segundo o
que foi investido (ROI) em ti. Valeria dizer que este modelo seria um complemento ao
COBIT, pois ambos reunidos proporcionariam um ciclo completo para a governança de
TI.
o Para este modelo é necessário a divisão em três pilares:
 Governança de valor,
 gerenciamento de portifólio e
 gerenciamento de investimentos.
o Como você pode notar este modelo segue muito o gerenciamento de vida do ciclo
econômico.
o Benefícios:
 Melhor compreensão e transparência de custos;
 Entendimento de custo-benefício, risco e benefício de implementação;
 Aumento de probabilidade para uma melhor implementação de solução;
 Maior concentração de controle em benefícios e investimentos;
  Alinhamento de investimento de acordo com estratégias empresariais;
 Melhor comunicação entre o TI e as demais áreas;
o ISO/ IEC 38500
o Essa norma, tem por objetivo fornecer algumas recomendações úteis, no que diz
respeito a governança de TI. Acaba por listar boas práticas, técnicas de gerenciamento
e monitoramento a fim de avaliar o ambiente de TI de cada empresa.
o A definição dada pela ISO/IEC 38500. Governança de TI é “o sistema pelo qual o uso
atual e futuro da TI são dirigidos e controlados. Significa avaliar e direcionar o uso da
TI (gerenciamento de recursos) para dar suporte à organização e monitorar seu usa
para realizar planos (monitoramento do desempenho de TI). Inclui as políticas de uso
da TI dentro da organização”.
o Essas normas podem ser aplicadas em empresas públicas e privadas e independente do
porte.
o Aqui seguem os seis pontos de atenção:
 Responsabilidade;
 Estratégia;
 Aquisição;
 Desempenho;
 Conformidade;
 Comportamento humano;
o CMMI:
o É a sigla para (Capacity Maturity Model Integration) que consiste em um conjunto de
práticas importantes para processos eficientes, que visam a melhoria do desempenho do
ambiente de Tecnologia.
o Dentro este modelo existe outros 3 que podem ser implementados:
 CMMI for Development (CMMI-DEV): Visa as melhores práticas para
desenvolvimento de produtos e serviços;
 CMMI for Acquisition (CMMI-ACQ): Tem o intuito de explicar as melhores
aquisições de produtos e serviços;
 CMMI for Services (CMMI SVC): Tem como principal objetivo fazer com que
empresas entreguem os melhores serviços;
o Áreas de Processo: O modelo CMMI v1.2 (CMMI-DEV) contém 22 áreas de processo.
Em sua representação por estágios, as áreas são divididas da seguinte forma:
o Nível 1: Inicial (Ad-hoc)
 Não possui áreas de processo.
o Nível 2: Gerenciado / Gerido
 Gerenciamento de Requisitos - REQM (Requirements Management)
 Planejamento de Projeto - PP (Project Planning)
 Acompanhamento e Controle de Projeto - PMC (Project Monitoring and
Control)
 Gerenciamento de Acordo com Fornecedor - SAM (Supplier Agreement
Management)
 Medição e Análise - MA (Measurement and Analysis)
 Garantia da Qualidade de Processo e Produto - PPQA (Process and Product
Quality Assurance)
 Gerência de Configuração - CM (Configuration Management)
o Nível 3: Definido:
 Desenvolvimento de Requisitos - RD (Requirements Development)
 Solução Técnica - TS (Technical Solution)
 Integração de Produto - PI (Product Integration)
 Verificação - VER (Verification) Validação - VAL (Validation)
 Foco de Processo Organizacional - OPF (Organizational Process Focus)
 Definição de Processo Organizacional - OPD (Organizational Process
Definition)
 Treinamento Organizacional - OT (Organizational Training)
 Gerenciamento Integrado de Projeto - IPM (Integrated Project Management)
 Gerenciamento de Riscos - RSKM (Risk Management)
 Análise de Decisão e Resolução - DAR (Decision Analysis and Resolution)
o Nível 4: Quantitativamente gerenciado / Gerido quantitativamente
 Desempenho de Processo Organizacional - OPP (Organizational Process
Performance)
 Gerenciamento Quantitativo de Projeto - QPM (Quantitative Project
Management)
o Nível 5: Em otimização
 Gestão do Desempenho Organizacional - OPM (Organizational Performance
Management)
 Análise Causal e Resolução - CAR (Causal Analysis and Resolution)
5.2 Administração de serviços de Tecnologia da Informação.
5.3 Análise de viabilidade técnica e econômica de soluções de Tecnologia da Informação.

Qual é o melhor modelo, é necessária uma análise meticulosa e seguir alguns procedimentos:

o Avaliar o ambiente de TI como um todo;

o Mapear itens e processos;
o Documentar conclusões e informações relevantes;
o Fazer pesquisas de mercado considerando preços e custo-benefício;
o Identificar pontos fortes e deficientes das ferramentas atuais;
o Propor soluções práticas e eficientes para resolver das questões pontuadas;
o Apresentar tudo isso como estratégia para a diretoria.

5.4 Metodologia de gestão e governança de dados.

5.5 Sistemas Integrados de Gestão (ERP).

5.6 ITIL v4.

o ITIL significa Information, Technology, Infraestructure, Library

o ITIL é o conjunto das melhores práticas para Gerenciamento do Ciclo de Vida do Serviço.
Um conjunto de boas práticas testadas e comprovadas no mercado para gerenciamento de
serviços de TI
o Pode ser utilizada por qualquer empresa de qualquer tamanho (Modelo não prescritível)
o Modelo não proprietário e de domínio público
o Define bom senso
o NÃO é ITIL:
o Não é um padrão de implementação de governança de TI
o Não é uma metodologia proposta pela ISSO
o Não é um conjunto de regras usadas para regulamentar a governança de TI
o Não surgiu a partir das pesquisas acadêmicas de renomadas universidades e sim
pelo governo britânico

o Objetivo ITIL:
o Prover um conjunto de práticas de gerenciamento de serviços de TI testadas e
comprovadas que podem servir como balizadoras, tanto para organizações que já
possuem TI em andamento e pretendem empreender melhorias quanto para a
criação de novas operações.
o Orientar o outsourcing de serviços de TI (Fornecedores)
o ERRADO:
 Não tem o objetivo de definir um modelo para planejamento estratégico
de TI
 Não tem o objetivo de definir boas práticas de gerenciamento de projetos
o A ITIL oferece um framework comum para todas as atividades do departamento de TI, como
a parte da provisão dos serviços, baseada na infra-estrutura de TI.
o Estas atividades são divididas em processos, que fornecem um framework eficaz para um
futuro Gerenciamento de Serviços de TI aprimorado. Cada um destes processos cobre uma
ou mais tarefas do departamento de TI, tais como desenvolvimento de serviços,
gerenciamento da infra-estrutura, fornecimento de serviços e suporte a serviços.
o ITIL V4 é a mais recente versão do framework de gerenciamento de serviço.
o ITIL está voltado para gerenciamento de TI enquanto a COBIT é voltado para governança de
TI
o O ITIL V4 oferece uma fundamentação flexível para organizações que precisam integrar
vários frameworks e abordagens em seus modelos operacionais de gerenciamento de
serviços.
o O foco é ajudar negócios a navegar através da era das novas tecnologias e serviços digitais.
o introduzindo uma abordagem holística ao gerenciamento de serviços e focando no
‘gerenciamento de serviços de ponta a ponta, da demanda ao valor’.
o O ITIL V4 consiste em dois componentes chave:
o O modelo de quatro dimensões: O ITIL 4 define quatro dimensões que devem
ser consideradas para garantir uma abordagem holística ao gerenciamento de
serviços:
 Organizações e pessoas: Matrizes de papéis e responsabilidades bem
definidas
 Informação e tecnologia: Abrange tecnologias que dão suporte ao
gerenciamento de serviços em uma organização. Além disso inclui todas
as informações criadas, armazenadas, gerenciadas e usadas durante a
entrega de serviços de TI.
  Parceiros e fornecedores: Inclui relacionamentos de uma organização
com outras organizações ou indivíduos que estão envolvidos no projeto,
desenvolvimento, entrega e suporte de serviços em diferentes níveis.
Uso do método SIAM(Integração e Gerenciamento de Serviços)
 Fluxos de valor e processos: Envolve a definição das atividades,
fluxos de trabalho, processos e procedimentos necessários para atingir
os objetivos de negócios acordados, além de determinar como os
diferentes componentes da organização se unem e trabalham em
uníssono para permitir a criação de valor por meio de produtos e
serviços. Um fluxo de valor é uma série de etapas que uma organização
realiza para criar e entregar produtos e serviços aos consumidores.
Esses fluxos de valor são, por sua vez, ativados por processos que
transformam entradas em saídas. Essa dimensão ajuda a definir o
modelo de entrega de serviço e a identificar processos que não auxiliam
na criação de valor para o negócio.
o O Sistema de valor de serviço (SVS): representa “como todos os componentes e
atividades de uma organização trabalham juntos para facilitar a criação de valor”.
O SVS do ITIL V4 inclui cinco elementos:
 Princípios orientadores: É um conjunto de recomendações do ITIL 4
que orientam uma organização em todo o seu ciclo de vida de
gerenciamento de serviços, independentemente das mudanças que
ocorram nos objetivos, estratégias ou na estrutura da organização.
Existem 7 sete princípios orientadores no livro ITIL 4 Foundation:
 Foco no valor
 Progrida iterativamente com feedback
 Pense e trabalhe holisticamente
 Otimize e automatize
 Comece onde vc está
 Colabora e promova visibilidade
 Mantenha-o simples e prático

 Governança: Independentemente de seu tamanho, todas as

organizações são governadas por uma pessoa ou um grupo de pessoas
que assumem a responsabilidade completa de supervisionar a função da
organização como um todo, ou como unidades individuais. A governança
envolve avaliação, direção e monitoramento de atividades

 Cadeia de valor de serviço: cadeia de valor do serviço como uma

combinação de seis atividades principais que trabalham juntas para
cocriar valor para os usuários finais, entregando um produto ou serviço:
 Plano: A criação de planos, políticas, padrões e definição da
direção para um determinado fluxo de valor.
 Melhorar: Garantir a melhoria contínua das práticas, produtos
e serviços oferecidos pela organização.
 Engajar : Estabelecer boas relações com todas as partes
interessadas e usuários finais, para fornecer transparência e
um entendimento claro dos produtos e serviços.
 Desenho e transição: garante que os produtos e serviços
oferecidos atendam continuamente às demandas dos
stakeholders.
 Obter / construir: garante a disponibilidade de componentes de
serviço, como hardware, software, serviços, etc., quando e
onde forem necessários.
 Entrega e suporte: garante que os serviços sejam entregues e
apoiados de forma que atenda às expectativas das partes
interessadas.
O valor de um serviço, para o ITIL, é medido pela utilidade
e garantia. Utilidade: diz respeito ao que o cliente quer, e
caracteriza o que o serviço faz. Garantia: Relacionado a como
o serviço é feito, ou seja, à sua qualidade.
Em resumo, o que serviço deve oferecer ao cliente e qual o
nível de qualidade que ele deve ter.
O Pacote de Nível de Serviço, consolidado pela Estratégia de
Serviço, provê um nível de utilidade e garantia sob a
perspectiva de entrega do serviço.
 Melhoria contínua: busca constante de oportunidades de melhoria da
eficácia e da eficiência dos serviços de TI que permitem os processos de
negócios. Isso inclui melhorias em toda a organização nas unidades de
negócios, produtos, serviços, processos e relacionamentos. No ITIL 4, a
 melhoria contínua se aplica a todos os elementos da cadeia de valor do
serviço, aos sete princípios orientadores e é recomendada como uma
prática de gerenciamento geral.
 Práticas da ITIL: “um conjunto de recursos organizacionais projetados
para realizar um trabalho ou cumprir um objetivo”. No itil 4, descreve
“práticas” em vez de processos. Embora essas duas palavras sejam
usadas alternadamente, elas significam coisas completamente diferentes
no contexto do gerenciamento de serviços de TI. Essas práticas do ITIL
4 combinam entradas de domínios de gerenciamento de negócios em
geral, o espaço de gerenciamento de serviço e soluções de tecnologia
associadas para fornecer serviços de TI.

o O ITIL 4 inclui 34 práticas de gerenciamento como “conjuntos de recursos organizacionais

projetados para executar o trabalho ou atingir um objetivo”. Para cada prática, o ITIL 4
fornece vários tipos de orientação, como termos e conceitos-chave, fatores de sucesso,
atividades-chave, objetos de informação etc.
o As 34 práticas da ITIL V4 estão agrupadas em três categorias:
o 14 Práticas gerais de gerenciamento incluem:
 Gerenciamento de estratégia: É uma prática de gestão que define os
objetivos da organização e traça o plano de ação, alocação dos recursos
necessários para o alcance desses objetivos. Também ajuda a focar os
esforços da organização, define o que priorizar de acordo com seus
objetivos e atua como orientação.
 Gerenciamento de portfólio: a prática de gerenciamento de portfólio
garante que a organização tenha a combinação certa de produtos,
serviços e processos para atingir seus objetivos de negócios com as
restrições de financiamento e recursos fornecidas.
 Gerenciamento de arquitetura: fornece uma compreensão de como os
diferentes elementos de uma organização estão inter-relacionados e
trabalham para atingir os objetivos de negócios. É fundamental para
planejar, melhorar, projetar e fazer a transição das atividades da cadeia
de valor.
 Gerenciamento financeiro de serviços: O objetivo da prática de
gerenciamento financeiro de serviços é ajudar a administração a decidir
sobre onde gastar seus recursos financeiros para cumprir o objetivo da
organização. É responsável por gerenciar todas as atividades de
orçamento, custeio e contabilidade em toda a empresa. Para que isso
seja eficaz, a prática de gerenciamento financeiro de serviços precisa
estar estreitamente alinhada com as práticas de gerenciamento de
portfólio e relacionamento da organização.
 Gerenciamento de talento e força de trabalho: O objetivo da prática
de força de trabalho e gestão de talentos é garantir que a organização
contenha as pessoas certas, com as competências e habilidades certas
em todos os lugares, em linha com os objetivos de negócios da
empresa. Essa prática inclui todas as atividades relacionadas a
recrutamento, integração, envolvimento com os funcionários da
organização, aprendizado e desenvolvimento e medição de
desempenho.
 Melhoria contínua: alinha os serviços da organização com as
necessidades em constante mudança, melhorando produtos, serviços e
práticas em todas as fases da prestação de serviços. O modelo de
melhoria contínua contém várias etapas que giram em torno de qual é a
visão da organização, onde estão no momento, onde querem estar (o
que desejam alcançar), como chegar lá, agir e analisar se alcançaram
seus objetivos no final.
 Medição e relatórios: essa prática ajuda a melhorar a previsão e a
tomada de decisões em todos os níveis organizacionais, desde o
planejamento até o suporte ao usuário. Fornece informações baseadas
em fatos e mede o progresso e a eficácia de produtos, processos,
serviços, equipes, indivíduos e a organização como um todo. As
organizações usam Fatores Críticos de Sucesso (CSFs) e
Indicadores Chave de Desempenho (KPIs) para medir a obtenção dos
resultados pretendidos. Na frente de relatórios, os dados podem ser
coletados e apresentados por meio de painéis, que ajudam a apoiar uma
boa tomada de decisão.
 Gerenciamento de riscos: os riscos são parte integrante de qualquer
negócio. Para uma empresa se sustentar no longo prazo, riscos
calculados e inteligentes são inevitáveis. Mas antes de correr qualquer
risco, é necessário ter uma compreensão clara e de seus impactos na
organização. A prática de gerenciamento de risco ajuda uma
 organização a compreender, gerenciar e lidar com riscos de forma
eficaz.
 Gerenciamento de segurança da informação: as organizações
armazenam muitos dados confidenciais, como detalhes do cliente,
informações de aplicativos etc. Um entendimento claro de
confidencialidade, riscos e integridade é necessário para garantir que
esses dados estejam seguros. A prática de gestão de segurança da
informação visa alcançar um equilíbrio entre o estabelecimento de
políticas fortes de segurança da informação, a realização de auditorias
regulares para conformidade com os padrões internacionais de
segurança de dados, a implementação de processos de gestão de risco
e o treinamento dos funcionários sobre a importância da segurança da
informação. Ex: LGPD (Lei Geral Proteção de Dados)
 Gestão do conhecimento: o conhecimento em uma organização
compreende informações, habilidades, práticas e soluções em várias
formas. Para proteger esse valioso ativo organizacional, a prática de
gestão do conhecimento mantém e melhora o uso eficaz das
informações em toda a organização por meio de uma abordagem
estruturada.
 Gerenciamento de mudanças organizacionais: qualquer organização
bem-sucedida está sujeita a muitas mudanças. Pode ser na forma como
as pessoas trabalham, seu comportamento, suas funções, a estrutura
organizacional ou as tecnologias utilizadas. A prática de gestão de
mudança organizacional garante que todos os afetados por tais
mudanças aceitem e apoiem, fornecendo treinamento e conscientização
e cuidando de quaisquer impactos adversos que as mudanças possam
ter criado.
 Gerenciamento de Projetos: a prática de gerenciamento de projetos
envolve um conjunto geral de processos e atividades necessários para
coordenar e implementar mudanças em uma organização. Ele garante
que todos os projetos em toda a empresa sejam planejados, delegados,
monitorados e entregues com sucesso nos prazos estipulados. As
abordagens mais comuns em gerenciamento de projetos são o método
em cascata e o método ágil. O primeiro é usado quando os requisitos
são bem conhecidos e o projeto não está sujeito a nenhuma mudança
significativa, enquanto o último é usado quando os requisitos podem
mudar e evoluir rapidamente.
 Gerenciamento de relacionamento: Essa prática de gestão estabelece
e nutre os vínculos entre a organização e seus stakeholders em
diferentes níveis. Se a organização é uma prestadora de serviços, a
maior parte de seus esforços se concentra em manter um bom
relacionamento com seus consumidores. A prática de gestão de
relacionamento contribui para todas as atividades da cadeia de valor dos
serviços.
 Gerenciamento de fornecedores: A prática de gestão de fornecedores
permite a gestão adequada dos fornecedores e vendedores da
organização e garante que os produtos e serviços recebidos sejam de
alta qualidade e não afetem a entrega oportuna do que foi planejado.
Também ajuda a manter um relacionamento saudável com diferentes
fornecedores.
o 17 Práticas de gerenciamento de serviços incluem:
 Análise de negócio: A prática de análise de negócios ajuda a analisar
um negócio ou algum elemento, identifica problemas, comunica as
necessidades de mudança de uma maneira fácil de entender e sugere
soluções para resolver esses problemas. Possui grande importância na
criação de valor para os diferentes stakeholders da organização.
 Gerenciamento de catálogo de serviços: Essa prática envolve
atividades como a criação de um portal que contenha todas as ofertas de
produtos e serviços, com o objetivo de fornecer serviços de TI
consumerizados. Ele permite a comunicação ao público-alvo sobre a
lista de serviços fornecidos pela organização.
 Design de serviço: o projeto ruim de produtos e serviços resulta em
falha em atender às necessidades dos clientes. A prática de
gerenciamento de design de serviço ajuda a projetar produtos e serviços
adequados para o ecossistema da organização, facilita a criação de
valor e ajuda a realizar os objetivos de negócios. Inclui o planejamento e
organização de pessoas, parceiros, fornecedores, TI, comunicação e
processos.
 Gerenciamento de nível de serviço: os serviços fornecidos por uma
organização precisam atingir um nível mínimo de qualidade conforme
 definido. A prática de gerenciamento de nível de serviço ajuda a definir
metas para esses níveis de serviço e envolve todas as atividades
relacionadas ao monitoramento, medição, avaliação e gerenciamento da
entrega de serviços por meio de acordos de nível de serviço (SLAs).
 Gerenciamento de disponibilidade: Em uma organização, para o
gerenciamento de serviços bem-sucedido, os produtos e serviços devem
estar disponíveis quando necessário para as partes interessadas. O
objetivo da prática de gerenciamento de disponibilidade é garantir que
um serviço ou ativo de TI seja capaz de desempenhar sua função
sempre que necessário (estar disponíveis para partes interessadas)
 Gerenciamento de capacidade e desempenho: Para um
gerenciamento de serviço eficaz, convém que os serviços prestados por
uma organização atinjam o desempenho esperado sem exceder os
custos acordados. Além de atender às demandas atuais, eles devem
atender aos requisitos de negócios a longo prazo. Isso é garantido pela
prática de gestão de capacidade e desempenho.
 Gerenciamento de continuidade de serviço: as organizações não
estão livres de desastres. Esses eventos não planejados podem causar
sérios danos à organização, incluindo a falha em fornecer funções
críticas de negócios continuamente. O gerenciamento de continuidade
de serviço fornece orientação para a continuidade de negócios e garante
que a TI e os serviços possam ser retomados após uma crise.
 Monitoramento e gerenciamento de eventos: Ajuda a observar
constantemente os serviços dentro da organização e registrar todos os
eventos associados. Esses eventos são basicamente uma mudança de
estado que tem um impacto sobre o produto na entrega do serviço. O
monitoramento e o gerenciamento de eventos são altamente úteis na
identificação de eventos de segurança da informação e auxiliam na
resposta com soluções apropriadas.
 Central de serviço: Na ITIL, a Central de Serviços tem o intuito de ser
esse ponto único de contato dos usuários com o STAFF da TI. Manter os
usuários informados sobre o andamento de suas solicitações; Escalar
incidentes difíceis ou demorados de resolver e; Fechar incidentes.
(ERRADO: é responsável por fornecer habilidades técnicas para o
suporte de serviços de TI e o gerenciamento de infraestrutura de TI.)
 Gerenciamento de incidentes: A prática de gerenciamento de
incidentes garante que os melhores níveis possíveis de qualidade e
disponibilidade de serviço sejam mantidos em todos os momentos. Tem
como objetivo restabelecer o funcionamento normal do serviço o mais
rápido possível, além de minimizar o impacto adverso nas operações do
negócio causado por esses incidentes.
 Gerenciamento de requisição de serviço: os usuários em uma
organização solicitam informações ou um serviço de TI sempre que
precisam. Essas solicitações são chamadas de solicitações de serviço.
As solicitações de redefinição de senha são ótimos exemplos de
solicitações de serviço. A prática de gerenciamento de solicitações de
serviço envolve o gerenciamento dessas solicitações de maneira
eficiente e amigável.
 Gerenciamento de problemas: O objetivo do gerenciamento de
problemas é prevenir a ocorrência de problemas e incidentes, e eliminar
incidentes recorrentes. Também ajuda a minimizar o impacto de
incidentes que não podem ser evitados. Isso é feito identificando as
causas-raiz de tais incidentes, criando soluções alternativas e mapeando
erros conhecidos.
 Gerenciamento de Liberação/Versão: o gerenciamento de versão visa
construir, testar e entregar os serviços novos e alterados que atendem
aos requisitos de serviço acordados ao atingir os objetivos pretendidos.
Garante a satisfação de todos os stakeholders da organização.
 Controle de mudanças: enquanto o gerenciamento de mudanças
concentra-se no lado das pessoas nas mudanças implementadas na
organização, o controle de mudanças concentra-se nas mudanças em
produtos e serviços. Pode ser causado por vários fatores como TI,
aplicativos, processos, relacionamentos etc.
 Validação e teste de serviço: Todos os produtos e serviços novos ou
alterados em uma organização precisam ser verificados se atendem aos
requisitos definidos e devem passar por testes. Isso é feito por meio de
validação de serviço e prática de teste.
 Gerenciamento de configuração de serviço: esta prática de
gerenciamento envolve a coleta e o gerenciamento de informações
sobre todos os itens de configuração (ICs) disponíveis na organização.
 Os ICs incluem hardware, software, redes, pessoas, fornecedores, etc. O
gerenciamento de configuração de serviço fornece informações sobre
como os ICs contribuem para os negócios e descreve o relacionamento
entre eles.
 Gerenciamento de ativos de TI: Todos os componentes que
contribuem para a entrega de um serviço de TI são chamados de ativos
de TI. A prática de gerenciamento de ativos de TI ajuda no planejamento
e gerenciamento de todo o ciclo de vida desses ativos, o que ajuda a
organização a gerenciar custos e riscos, aumentar o valor e ajudar a
tomar melhores decisões de compra.
o 3 Práticas de gerenciamento técnico incluem:
 Gerenciamento de implantação: trabalhando em estreita colaboração
com o gerenciamento de liberação e controle de alterações, a prática de
gerenciamento de implantação lida com a configuração de hardware,
software, processos novos / alterados ou qualquer outro componente em
um ambiente ativo. Diferentes abordagens incluem implantação em
fases, entrega contínua, implantação big bang e implantação pull.
 Gerenciamento de infraestrutura e plataforma: para a TI de uma
organização, o gerenciamento de infraestrutura e plataforma auxilia no
gerenciamento de recursos de tecnologia como armazenamento, redes,
servidores, software, hardware e itens de configuração usados pelos
clientes. Também inclui os edifícios e instalações que a organização usa
para manter sua infraestrutura de TI.
 Desenvolvimento e gerenciamento de software: A prática de
desenvolver aplicativos de software, desde um único programa até
sistemas operacionais e grandes bancos de dados, é significativa para
as organizações na criação de valor para os clientes em serviços
baseados em tecnologia. Ele é gerenciado usando duas abordagens
amplamente populares – cascata e Agile.
o O ITIL V4 inclui orientações atualizadas sobre integração de vários fornecedores e serviços.
Estes são os principais tópicos na estrutura SIAM®.
o O ITIL V4 adota novas formas de trabalhar, como Agile, Lean e DevOps, além do
gerenciamento de mudanças organizacionais. Essas práticas de gerenciamento e sua
relevância para o gerenciamento de serviços também são descritas na abordagem VeriSM
™.
o O ITIL V4 apresenta o conceito de um sistema de valor de serviço. Isso se encaixa com um
requisito essencial na última edição da ISO 20000 de 2018, para as organizações
“estabelecerem, implementarem, manterem e melhorarem continuamente” um sistema de
gerenciamento de serviços.

5.7 Governança de dados utilizando metodologia do DAMA-DMBoK (Data Management Body of

Knowledge).

o Data Management Body of Knowledge (DAMA DMBOK®) é um framework de boas práticas de gestão de
dados, que tem como intuito transmitir a importância da gestão de dados.
o Governança de dados é o “Exercício de autoridade, controle, planejamento, monitoramento, disponibilidade,
segurança e execução dos ativos de dados e seu respectivo consumo”.
o Governança de dados é uma estrutura que coordena, orienta e define regras para criação, reuso e consumo
dos dados.
o Vantagens da governança de dados:
o Tomada de melhores decisões de negócios através de melhores insight’s, nossos riscos de
segurança de dados serão minimizados.
o Impactos da não aplicação da governança de dados:
o Criação de bases sem critério definido.
o Proliferação de silos informacionais.
o Qualidade duvidosa dos dados.
o Dificuldades em se reutilizar dados existentes.
o Problemas de conformidade regulamentar (auditorias e Compliance).
o A governança de dados DAMA DMBOK tem 10 funções de gestão de dados:
o Arquitetura de dados
o Modelagem de dados e projeto
o Armazenagem de dados
o Segurança de dados
o Integração dos dados
o Documentos e Conteúdo
o Dados Mestres e de Referência
o Data Warehousing e BI
o Metadados
o Qualidade de dados
 1) UML

A Unified Modeling Language (Linguagem de Modelagem Unificada) é uma linguagem gráfica para
visualização, especificação, construção e documentação de artefatos de sistemas complexos. Não é proprietária.

A UML emergiu como notação diagramática padrão para modelagem orientada a objetos criada inicialmente
pela junção de duas metodologias, do BOOCH e OMT (Rumbaugh). Posteriormente, se juntou a eles Jacobson, o
criador do método Objectory (OOSE).

Objetivos da UML:

 A modelagem de sistemas (não apenas de software) usando os conceitos da orientação a objetos;

 Estabelecer uma união fazendo com que métodos conceituais sejam também executáveis;
 Criar uma linguagem de modelagem usável tanto pelo homem quanto pela máquina.

Os Diagramas da UML são classificados como estruturais e comportamentais:

1) Diagramas Estruturais/Estáticos:

 Classe: mostra o conjunto de classes com seus atributos, métodos e relacionamentos.

 Objeto: fazem a modelagem de instâncias de itens contidos em diagramas de classes. Utiliza notação
semelhante.
 Componentes: são empregados para modelagem de coisas físicas que podem residir em um nó, como
executáveis, bibliotecas, tabelas, arquivos e documentos.
 Implantação: modela as necessidades de hardware e características físicas do sistema.
 Pacotes: para organizar seus elementos de modelagem em conjuntos, em subsistemas.

2) Diagramas Comportamentais/Dinâmicos:

 Caso de uso: descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário.
 Máquina de estados: mostra os possíveis estados de um objeto e as transações responsáveis pelas suas
mudanças de estado.
 Atividades: mostra o fluxo de atividades em um único processo. Mostra como uma atividade precisa da
outra.
 Interação:
o Sequência: mostrar como as mensagens entre objetos são trocadas no decorrer do tempo para
realização de uma operação.
o Colaboração: A diferença do diagrama de sequência consiste no fato de que o tempo não é mais
representado por linhas verticais, mais sim através de numeração.

Existem 5 fases do desenvolvimento de um sistema em UML (Estas cinco fases não devem ser executadas na ordem
descrita acima, mas concomitantemente de forma que problemas detectados numa certa fase modifiquem e melhorem
as fases desenvolvidas anteriormente de forma que o resultado global gere um produto de alta qualidade e
performance)
 Análise de requisitos:
o Esta fase captura as intenções e necessidades dos usuários do sistema a ser desenvolvido através
do uso de funções chamadas "use-cases" onde serão manipuladas pelas entidades externas
chamadas atores externos)
o Os atores externos e os "use-cases" são modelados com relacionamentos que possuem
comunicação associativa entre eles ou são desmembrados em hierarquia.
o Cada "use-case" modelado é descrito através de um texto, e este especifica os
requerimentos do ator externo que utilizará este "use-case". O diagrama de "use-cases" mostrará o
que os atores externos, ou seja, os usuários do futuro sistema deverão esperar do aplicativo,
conhecendo toda sua funcionalidade sem importar como esta será implementada.
o A análise de requisitos também pode ser desenvolvida baseada em processos de negócios, e não
apenas para sistemas de software.
 Análise:
o Esta fase preocupa com as primeiras abstrações (classes e objetos) e mecanismos que estarão
presentes no domínio do problema.
o As classes são modeladas e ligadas através de relacionamentos com outras classes, através do
Diagrama de Classe.
o Na análise, só serão modeladas classes que pertençam ao domínio principal do problema do
software, ou seja, classes técnicas que gerenciem banco de dados, interface, comunicação,
concorrência e outros não estarão presentes neste diagrama.
 Design (projeto):
 o Na fase de design, o resultado da análise é expandido em soluções técnicas. Novas classes serão
adicionadas para prover uma infra-estrutura técnica: a interface do usuário e de periféricos,
gerenciamento de banco de dados, comunicação com outros sistemas, dentre outros.
o As classes do domínio do problema modeladas na fase de análise são mescladas nessa nova
infra-estrutura técnica tornando possível alterar tanto o domínio do problema quanto a infra-
estrutura.
o O design resulta no detalhamento das especificações para a fase de programação do sistema
 Programação:
o Na fase de programação, as classes provenientes do design são convertidas para o código da
linguagem orientada a objetos escolhida
 Testes:
o Um sistema normalmente é rodado em testes de unidade, integração, e aceitação.
 Teste de Unidade: são para classes individuais ou grupos de classes e são geralmente
testados pelo programador.
 Teste de Integração: são aplicados já usando as classes e componentes
integrados para se confirmar se as classes estão cooperando uma com as outras como
especificado nos modelos.
 Teste de aceitação: observam o sistema como uma " caixa preta" e verificam se o
sistema está funcionando como o especificado nos primeiros diagramas de "use-cases".
ÊNFASE 4: ANALISTA DE SISTEMAS – ENGENHARIA DE SOFTWARE – BLOCO I: 1.
Engenharia de Software. 1.1 Modelos
de ciclo de vida de software. 1.2 Metodologias de desenvolvimento de software. 1.3
Arquitetura de software. 1.4 Conceitos e
técnicas do projeto de software. 1.5 Processos e práticas de desenvolvimento de
software. 1.6 Processo interativo e incremental.
1.7 Práticas ágeis de desenvolvimento de software. 1.8 Gerenciamento de ciclo de vida
de aplicações. 1.9 Desenvolvimento
orientado por comportamento (BDD). 1.10 Desenvolvimento guiado por testes (TDD).
1.11 Integração contínua. 1.12 Diagrama
Entidade Relacionamento (ER). 1.13 Notação BPMN. 1.14 Conceitos e ferramentas de
DevOps. 1.15 Técnicas de Integração e
Implantação Contínua de Código (CI/CD). 2. Requisitos e Experiência do Usuário. 2.1
Elicitação e Gerenciamento de Requisitos,
design thinking. 2.2 Histórias do usuário. 2.3 Critérios de Aceitação. 2.4 Lean UX. 2.5
Minimum Viable Product (MVP). 2.6
Prototipação. 2.7 Projeto centrado no usuário de software. 2.8 Storytelling. 2.9 Análise de
personas (papéis, perfis etc.) de
usuários de software. 3. Arquitetura de Aplicações. 3.1 Padrão arquitetural Model-View-
Controller (MVC). 3.2 Sistemas de N
camadas. 3.3 Microsserviço. 3.4 Arquitetura orientada a eventos. 3.5 DevOps e CI/CD.
3.6 Refatoração e Modernização de
aplicações. 3.7 Práticas ágeis. 3.8 Mediate APIs. 3.9 Arquitetura Cloud Native. 3.10
Padrões de design de software. 3.11 Técnicas
de componentização de software. 3.12 Padrões de projeto (design patterns) e anti-
patterns. 3.13 Padrões de arquitetura de
aplicações corporativas (Patterns of Enterprise Applications Architecture). 3.14
Arquitetura de Sistemas WEB e WEB Standards
(W3C). 3.15 Arquitetura Orientada a Serviços (SOA). 3.16 Barramento de Serviços
Corporativos (ESB). 3.17 Interoperabilidade
entre aplicações. 3.18 Conceitos básicos sobre servidores de aplicações. 3.19
Conteinerização de Aplicação. 3.20 Frameworks
de persistência de dados. 3.21 Mapeamento objeto-relacional. 3.22 Serviços de
mensageria. 3.23 Padrões: SOAP, REST, XML,
XSLT, UDDI, WSDL, JSON, RMI, XML-HttpRequest. 3.24 Soluções de busca de dados
não estruturados. 3.25 Streaming de
Dados. 3.26 Arquitetura Publish-Subscribe. 4. Linguagens de Programação. 4.1
Características estruturais das linguagens de
programação. 4.2 Orientação a objetos. 4.3 Coleções. 4.4 Tipos genéricos. 4.5 Threads.
4.6 Escalonamento. 4.7 Primitivas de
sincronização e deadlocks. 4.8 Garbage collector. 4.9 Tratamento de exceções. 4.10
Anotações. 4.11 Técnicas de profiling. 4.12
Linguagens de desenvolvimento de interfaces ricas (HTML 5, CSS 3). 4.13 JavaScript.
4.14 Python (versão 3.7 ou superior). 4.15
.Net Core (versão 5 ou superior). BLOCO II: 1. Qualidade de Software. 1.1 Garantia da
qualidade de software. 1.2 Gerência de
configuração de software (GIT). 1.3 Testes de software (unitário, integração, funcional,
aceitação, desempenho, carga,
vulnerabilidade). 1.4 Técnicas para aplicação de testes de software (caixa-branca, caixa-
preta, regressão e não funcionais). 1.5
Ferramentas para automatização de testes; Técnicas de refatoração de software. 1.6
Tratamento do débito técnico. 1.7 Métricas
de qualidade de código. 1.8 Code Smell. 1.9 Auditoria de Sistemas. 2 Estrutura de
Dados e Algoritmos. 2.1 Tipos básicos de
dados. 2.2 Tipos abstratos de dados (lista, fila, pilha, árvore, heap). 2.3 Sub-rotinas:
chamadas por endereço, referência e valor.
2.4 Algoritmos para pesquisa e ordenação. 2.5 Algoritmos para determinação de
caminho mínimo. 2.6 Listas lineares e suas
generalizações: listas ordenadas, listas encadeadas, pilhas e filas; Vetores e matrizes.
2.7 Árvores e suas generalizações:
árvores binárias, árvores de busca, árvores balanceadas (AVL), árvores B e B+. 2.8
Complexidade de algoritmos. 2.9
Programação recursiva. 3 Arquitetura de Dados. 3.1 Modelagem de dados (conceitual,
lógica e física). 3.2 Criação e alteração
dos modelos lógico e físico de dados. 3.3 Abordagem relacional. 3.4 Normalização das
estruturas de dados. 3.5 Integridade
referencial. 3.6 Metadados. 3.7 Modelagem dimensional. 3.8 Avaliação de modelos de
dados. 3.9 Técnicas de engenharia reversa
para criação e atualização de modelos de dados. 3.10 Linguagem de consulta
estruturada (SQL). 3.11 Linguagem de definição
de dados (DDL). 3.12 Linguagem de manipulação de dados (DML). 3.13 Sistema
Gerenciador de Banco de Dados (SGBD). 3.14
Propriedades de banco de dados: atomicidade, consistência, isolamento e durabilidade.
3.15 Independência de dados. 3.16 Transações de bancos de dados. 3.17 Melhoria de
performance de banco de dados. 3.18 Bancos de dados NoSQL. 3.19
Integração dos dados (ETL, Transferência de Arquivos e Integração via Base de Dados).
3.20 Banco de dados em memória. 3.21
Qualidade de dados e gestão de dados mestres e de referência. 3.22 Data Lakes e
Soluções para Big Data. 3.23 Diferenciação
entre bancos relacionais, multidimensionais, documentos e grafos. 4 Computação em
Nuvem. 4.1 Conceitos de computação em
nuvem: benefícios, alta disponibilidade, escalabilidade, elasticidade, agilidade,
recuperação de desastres. 4.2 Componentes
centrais da arquitetura em nuvem: distribuição geográfica, regiões, zonas de
disponibilidade, subscrições, grupos de gestão,
recursos. 4.3 Características gerais de identidade, privacidade, conformidade e
segurança na nuvem. 4.4 Gestão de custos na
nuvem: modelos de faturamento, gerenciamento de subscrições e contas, definição de
preço. 4.5 IoT. 4.6 Infrastructure as Code
(IaC) e Automação. BLOCO III: 1 Gerenciamento de Produtos de Software. 1.1
Gerenciamento de produtos com métodos ágeis:
Scrum E Kanban. 1.2 Modelos e técnicas de gestão de portfólio (SAFe): características,
objetivos, aplicabilidade e benefícios. 2
Análise
de
Dados
e
Informações.
2.1
Dado,
informação,
conhecimento
e
inteligência.
2.2
Conceitos,
fundamentos,
características, técnicas e métodos de business intelligence (BI). 2.3 Mapeamento de
fontes de dados. 2.4 Dados estruturados
e dados não estruturados. 2.5 Conceitos de OLAP e suas operações. 2.6 Conceitos de
data warehouse. 2.7 Técnicas de
modelagem e otimização de bases de dados multidimensionais. 2.8 Construção de
relatórios e dashboards interativos em
ferramentas de BI. 2.9 Manipulação de dados em planilhas. 2.10 Geração de insights a
partir de relatórios e dashboards. 2.11 BI
como suporte a processos de tomada decisão. 3 Infraestrutura Computacional e Redes.
3.1 Conceitos básicos de processamento
paralelo e distribuído. 3.2 High Performance Computing (HPC). 3.3 Virtualização
(computação, armazenamento, rede). 3.4
Conceitos básicos de gerenciamento de filas. 3.5 Gerenciamento de processos. 3.6
Protocolos de rede: TCP/IP, HTTP, HTTPS,
FTP, SMTP, LDAP, SSL, SAML 2.0, OAuth. 4 Segurança da Informação. 4.1 Segurança
física e lógica. 4.2 Operação de
segurança (Firewall, Proxy, IPS/IDS, DLP, CASB, SIEM, Antivírus, EDR, WAF, Gestão
de vulnerabilidades, Monitoração,
Backup). 4.3 Softwares maliciosos (ransomware, vírus, worms, spywares, rootkit etc.).
4.4 Ataques (DDoS, SQL Injection, XSS,
CSRF, Path Traversal etc.). 4.5 Técnicas de desenvolvimento seguro, SAST/DAST/IAST.
4.6 VPN. 4.7 MDM. 4.8 SSO. 4.9 MFA.
4.10 Gestão de Identidade e acesso (autenticação, autorização e auditoria), RBAC e
ABAC. 4.11 Conceitos gerais:
Gerenciamento de resposta a incidente (NIST SP 800-61). 4.12 Threat intel, threat
hunting. 4.13 Testes de penetração. 4.14
Modelagem de ameaças (STRIDE etc.). 4.15 Conhecimento das Táticas do framework
Mitre ATT&CK. 4.16 Gestão de riscos
(ISO 31000), Gestão de Continuidade de Negócios (ISO 22301) e Lei Sarbannes-Oxley.
4.17 Políticas de Segurança de
Informação. 4.18 Classificação de informações. 4.19 Norma ISO 27002, Criptografia,
certificação digital e assinatura digital. 4.20
Conceitos de segurança em nuvem. 4.21 Segurança em IoT. 5 Governança de TI. 5.1
Modelos de governança de Tecnologia da
Informação: características, objetivos e benefícios. 5.1 Administração de serviços de
Tecnologia da Informação. 5.3 Análise de
viabilidade técnica e econômica de soluções de Tecnologia da Informação. 5.4
Metodologia de gestão e governança de dados.
5.5 Sistemas Integrados de Gestão (ERP). 5.6 ITIL v4. 5.7 Governança de dados
utilizando metodologia do DAMA-DMBoK (Data
Management Body of Knowledge).