Arquitetura de Software

PRINCÍPIOS DE ARQUITETURA DE SOFTWARE
1
NOSSA HISTÓRIA
A nossa história inicia com a realização do sonho de um grupo de empre-

sários, em atender à crescente demanda de alunos para cursos de Graduação
e Pós-Graduação. Com isso foi criado a nossa instituição, como entidade ofere-
cendo serviços educacionais em nível superior.
A instituição tem por objetivo formar diplomados nas diferentes áreas de

conhecimento, aptos para a inserção em setores profissionais e para a partici-
pação no desenvolvimento da sociedade brasileira, e colaborar na sua formação
contínua. Além de promover a divulgação de conhecimentos culturais, científicos
e técnicos que constituem patrimônio da humanidade e comunicar o saber atra-
vés do ensino, de publicação ou outras normas de comunicação.
A nossa missão é oferecer qualidade em conhecimento e cultura de forma

confiável e eficiente para que o aluno tenha oportunidade de construir uma base
profissional e ética. Dessa forma, conquistando o espaço de uma das instituições
modelo no país na oferta de cursos, primando sempre pela inovação tecnológica,
excelência no atendimento e valor do serviço oferecido.
2
Sumário
INTRODUÇÃO ........................................................................................ 4
O QUE É A ARQUITETURA DE SOFTWARE? ...................................... 5
OBJETIVOS DA ARQUITETURA DE SOFTWARE ................................. 6
A FUNÇÃO DO ARQUITETO DE SOFTWARE ....................................... 7
PRINCÍPIO DA RESPONSABILIDADE ÚNICA ....................................... 9
PRINCÍPIO ABERTO-FECHADO .......................................................... 10
PRINCÍPIO DA SUBSTITUIÇÃO DE LISKOV ....................................... 12
PRINCÍPIO DE SEGREGAÇÃO DE INTERFACE ................................. 13
PRINCÍPIO DE INVERSÃO DE DEPENDÊNCIA .................................. 15
O PRINCÍPIO DA MENOR SURPRESA................................................ 16
O PRINCÍPIO DO MENOR ESFORÇO ................................................. 17
O PRINCÍPIO DO CUSTO DE OPORTUNIDADE ................................. 18
O PRINCÍPIO DO ÚLTIMO MOMENTO RESPONSÁVEL .................... 20
PRINCÍPIOS DE DESIGN DE SOFTWARE .......................................... 21
SEPARAÇÃO DE INTERESSES ....................................................... 21
ENCAPSULAMENTO ........................................................................ 22
INVERSÃO DE DEPENDÊNCIA ........................................................ 23
OS PRINCÍPIOS DA BOA ARQUITETURA........................................... 25
CONSIDERAÇÕES FINAIS................................................................... 26
REFERÊNCIAS ..................................................................................... 27
3
INTRODUÇÃO
À medida que a complexidade e o tamanho dos sistemas de software têm

aumentado, engenheiros de software têm lançado mão de princípios de projeto,
tais como a modularização e o ocultamento da informação, de modo a obter sis-
temas com maior qualidade e a um baixo custo.
Para isso, o projeto da estrutura global do software (arquitetura de sof-

tware) é uma questão que vem sendo considerada.
Esses pontos de vista compreendem princípios, padrões, antipadrões, re-

gras práticas e essenciais para as tomadas de decisões em direção a uma dire-
ção específica e também para avaliar o sucesso do projeto.
Em geral, esses princípios orientarão você para a criação de aplicativos

fora de componentes discretos que não têm um acoplamento rígido com outras
partes do aplicativo, mas que, em vez disso, se comunicam por meio de interfa-
ces explícitas ou sistemas de mensagens.
4
O QUE É A ARQUITETURA DE SOFTWARE?
Definição pela IBM
Uma arquitetura é o conjunto de decisões significativas sobre a organiza-

ção de um sistema de software, a seleção de elementos estruturais e suas inter-
faces, juntamente com o comportamento especificado nas colaborações entre
estes elementos, a composição destes elementos em subsistemas progressiva-
mente maiores e o estilo arquitetural que guia esta organização. (The Rational
Unified Process: An Introduction)
Definição pela Microsoft
Arquitetura de Software é o processo de definição de uma solução estru-

turada que atende a todos os requisitos técnicos e operacionais e ao mesmo
tempo otimiza atributos de qualidade padronizados como desempenho, segu-
rança e gerenciamento. Arquitetura envolve uma série de decisões baseadas em
uma vasta gama de fatores e cada uma destas decisões pode provocar um im-
pacto considerável no sucesso ou fracasso da aplicação.
Definição pela IEEE
Arquitetura é a organização fundamental de um sistema materializada em

seus componentes, na relação entre eles e com o ambiente e nos princípios que
guiam seu projeto e evolução.
Em resumo, as definições apresentadas concordam que a Arquitetura de

Software tem relação com as tomadas de decisões durante o processo de de-
senvolvimento assim como a estruturação dos elementos que compõe o sistema.
Em poucas palavras:
 Decisões  Organização fundamental  Elementos de software  Rela-
cionamento entre elementos  Relacionamento com o ambiente  Princípios que
guiam o desenho e evolução  Pode determinar o sucesso ou fracasso
5
OBJETIVOS DA ARQUITETURA DE SOFTWARE
Uma série de causas individualmente ou em conjunto pode fracassar um

projeto de desenvolvimento de software. Diversos riscos e restrições associados
ao processo aumentam a probabilidade de cancelamento. Falta de controle, es-
copo volátil, prazos exorbitantes, falta de recursos e entre outros vários motivos.
Shaw e Garlan (96) a arquitetura define o que é o sistema em termos de

componentes computacionais e, os relacionamentos entre estes componentes,
os padrões que guiam a sua composição e restrições.
Além da escolha dos algoritmos e estruturas de dados, a arquitetura en-

volve: decisões sobre as estruturas que formarão o sistema, controle, protocolos
de comunicação, sincronização e acesso a dados, atribuição de funcionalidade
a elementos do sistema, distribuição física dos elementos escalabilidade e de-
sempenho e outros atributos de qualidade; e seleção de alternativas de projeto.
6
A FUNÇÃO DO ARQUITETO DE SOFTWARE
O profissional Arquiteto de Software é responsável por uma grande vari-

edade de atividades dentro do processo de desenvolvimento de sistemas. Como
é ele quem define a arquitetura do software que será construído, ele tem a mis-
são de garantir que toda a equipe seguirá as diretrizes da arquitetura até o final
do projeto.
Além disso, faz parte do trabalho de um Arquiteto de Software envolver-

se com todo o processo de desenvolvimento, comunicar a arquitetura os interes-
sados pelo projeto, apoiar desenvolvedores na implementação e por ser um líder
técnico, também terá a função de mentor e ajudará na formação de novos arqui-
tetos.
 Definir, criar e manter a documentação arquitetural para

guiar a construção e manutenção do sistema.
 Definir estratégias, estilos e padrões arquiteturais.
 Garantir que as diretrizes da arquitetura serão aplicadas até
o final do projeto.
 Envolver-se com todo o processo de desenvolvimento.
 Comunicar a arquitetura aos stakeholders.
 Apoiar desenvolvedores na implementação.
 Atuar como mentor e formar novos arquitetos.
Durante todo o projeto de desenvolvimento de um software, o Arquiteto

será cobrado, ou melhor, será exigido de forma a garantir certas necessidades
do projeto e atender a determinadas restrições que são impostas do início ao
fim. O Arquiteto será cobrado pelo desenvolvimento ágil, com qualidade e de
baixo custo. O atendimento de requisitos funcionais e não-funcionais severos,
além de sua própria experiência, do seu time, do contexto organizacional e am-
biente técnico que podem influenciar positivamente ou negativamente.
7
Uma das habilidades vitais de um arquiteto é poder visualizar a arquitetura
de software de vários pontos de vista diferentes: cada uma delas individualmente
pode não ser totalmente relevante, mas combiná-las oferece uma visão de alto
nível do produto.
Arquitetos de soluções são os especialistas designados responsáveis

pela arquitetura de software de um sistema, bem como os padrões técnicos (in-
cluindo tecnologias, plataformas, infraestrutura) de um produto específico. Eles
definem a visão e sua análise é essencial para a definição, o design, a entrega
e o suporte ao longo da vida útil do produto. Portanto, eles precisam entender
não apenas o que os negócios precisam, mas também o que é lógico, escalável,
econômico e alinhado com os objetivos gerais de tecnologia da organização.
8
PRINCÍPIO DA RESPONSABILIDADE ÚNICA
Cada capacidade do sistema (por exemplo, serviço/módulo/API) deve ter

apenas uma responsabilidade e um motivo para mudar. Manter as responsabili-
dades o mais restritas possível significa que os usuários sabem da finalidade
pretendida, o que leva a menos erros.
A reposta é simples: quanto maior o número de responsabilidades, maio-

res as chances de modificação dessa classe no futuro e maiores as chances de
inserção de bugs que atrapalharão a classe por inteiro.
A extensibilidade! É comum a manutenção de códigos. Você deve, então,

lidar com as classes já criadas e, possivelmente, adicionar ou remover funciona-
lidades. Para uma classe ‘não-extensível’, a adição ou remoção de funcionalida-
des implica na modificação da classe por si só. Ao fazer tal mudança, você estará
propenso a fazer com que outras partes do seu código não funcionem mais.
9
PRINCÍPIO ABERTO-FECHADO
Este princípio postula que é preferível estender um comportamento do

sistema, sem modificá-lo. Embora muitas vezes não seja uma boa ideia tentar
antecipar alterações nos requisitos com antecedência (pois isso pode levar a
projetos excessivamente complexos), poder adaptar novas funcionalidades com
alterações mínimas nos componentes existentes é essencial para a longevidade
do aplicativo.
O princípio de Aberto/Fechado propõe que entidades (classes, funções,

módulos, etc.) devem ser abertas para extensão, mas fechadas para modifica-
ção.
Aberto para extensão significa que, ao receber um novo requerimento, é

possível adicionar um novo comportamento. Fechado para modificação significa
que, para introduzir um novo comportamento (extensão), não é necessário mo-
dificar o código existente.
Dependency Injection nada mais é do que passar uma dependência como

argumento para uma entidade qualquer. Isso permite que o código dependa mais
de uma abstração do que de algo concreto. No exemplo de código acima, a
classe Mailer pode receber um template qualquer, mas por padrão ela recebe
WelcomeTemplate.
Dependency Injection é apenas uma maneira de estender uma classe

sem alterar seu comportamento. Existem muitas outras soluções como Decora-
tor Pattern, Strategy Pattern, Composição e Herança.
10
Entre essas soluções, é importante atentar-se a Herança. Apesar da he-
rança permitir resolver o OCP, se não houver o devido cuidado, ela pode aumen-
tar o acoplamento do código, dificultando a manutenção, extensão e permitindo
criar código que viole o Single Responsibility Principle.
O problema é que a herança pode fazer com que aumente o acoplamento
entre as classes, se dependermos mais da forma como a classe é implementada,
do que da maneira como ela é representada no sistema (sua abstração).
O ideal é que a entidade dependa de uma abstração que forneça uma

interface para interagirmos, sem nos importarmos como ela funciona.
11
PRINCÍPIO DA SUBSTITUIÇÃO DE LISKOV
O princípio da Substituição de Liskov leva o nome da sua criadora Barbara

Liskov, que introduziu o conceito deste princípio em uma conferência em 1987 e
posteriormente, em 1994 no artigo Family Values: A Behavioral Notion of Sub-
typing com a parceria de Jeannette Wing. Podemos dizer que sua definição ori-
ginal de forma resumida é a seguinte:
Seja q(x) uma propriedade que se pode provar do objeto x do tipo T. En-
tão, q(y) também é possível provar para o objeto y do tipo S, sendo S um subtipo
de T.
O que isso quer dizer afinal?
Significa dizer que classes derivadas devem poder substituídas por suas
classes base e que classes base pode ser substituídas por qualquer uma das
suas subclasses. Uma subclasse deve sobrescrever os métodos da super-
classe de forma que a funcionalidade do ponto de vista do cliente continue a
mesma.
No desenvolvimento de software, isso significa que as classes derivadas

devem ser substituídas por suas classes base, mas a semelhança desse princí-
pio com o Design by Contract de Bertrand Meyer é como ela pode ser aplicada
à arquitetura de software distribuída: dois serviços se comunicam de forma eficaz
e repetida quando há um contrato comum ‘entre eles, que define as entradas/sa-
ídas, sua estrutura e suas restrições. Portanto: dados dois componentes distri-
buídos com o mesmo contrato, um deve ser substituível por outro componente
com o mesmo contrato, sem alterar a correção do sistema.
12
PRINCÍPIO DE SEGREGAÇÃO DE INTERFACE
As interfaces/contratos devem ser o mais detalhados possível e específi-

cos do cliente, para que os clientes que se ligam não dependam da funcionali-
dade que não usam. Isso anda de mãos dadas com o princípio da responsabili-
dade única: ao quebrar as interfaces, favorecemos a composição separando por
papéis/responsabilidades e o desacoplamento por não acoplar módulos deriva-
tivos a responsabilidades desnecessárias.
Em programação orientada a objetos, quando falamos de interface, esta-

mos falando do conjunto de métodos que um objeto expõe, ou seja, das manei-
ras como nós podemos interagir com esse objeto. Toda mensagem (ou chamada
de método) que um objeto recebe constitui uma interface.
A interface funciona como um contrato: nós definimos o comportamento

da interface na forma de diferentes métodos que ela possui. Cada classe que
deseja compartilhar o comportamento dessa interface precisa implementar os
métodos dela. Quando a classe utiliza uma interface, ela assina esse contrato
dizendo que irá implementar todos os métodos dessa interface.
As interfaces são comumente utilizadas por linguagens de programação

estaticamente tipadas (como Java e C#) para adicionar novos comportamentos
às classes, isso é feito utilizando a palavra reservada interface.
Linguagens como Ruby ou Python, definem sua interface de forma implí-

cita, através dos métodos que a classe implementa. Comumente nos referimos
a essa propriedade como Duck Typing. A ideia por trás do Duck Typing é que o
objeto é representado pelos métodos que ele possui e pelo que esses métodos
fazem.
13
Outra forma de implementar interfaces em Ruby é utilizando herança. Nós
podemos fazer com que a classe base lance exceções para cada método, de
forma que a classe herdeira é obrigada a implementar esses métodos. O mesmo
pode ser obtido com mixins. Dessa maneira, ao herdar uma classe ou incluir um
módulo, a classe herdeira precisa implementar o método.
O ISP é violado quando uma classe é obrigada a implementar métodos

que não utiliza. Por esse motivo, o ISP diz que as interfaces devem ser especí-
ficas (ou pequenas) para que as classes possam implementar somente os com-
portamentos necessários. Caso contrário, erros serão lançados.
14
PRINCÍPIO DE INVERSÃO DE DEPENDÊNCIA
Módulos de alto nível não devem depender dos de baixo nível; ambos
devem depender de abstrações. Da mesma forma, as abstrações não devem
depender de detalhes, mas os detalhes devem depender de abstrações. Como
tal, esse princípio introduz uma abstração de interface entre componentes ou
camadas de software de nível superior e inferior para remover as dependências
entre eles.
O princípio da inversão de dependência refere-se à dissociação de mó-

dulos de software. Dessa forma, em vez de módulos de alto nível, dependendo
de módulos de baixo nível, ambos dependerão de abstrações.
Para cumprir esse princípio, precisamos usar um padrão de design co-

nhecido como padrão de inversão de dependência , geralmente resolvido
usando injeção de dependência .
A injeção de dependência é um tópico enorme e pode ser tão complicado ou

simples quanto se possa perceber.
Normalmente, a injeção de dependência é usada simplesmente ‘inje-

tando’ quaisquer dependências de uma classe através do construtor da classe
‘como um parâmetro de entrada’.
15
O PRINCÍPIO DA MENOR SURPRESA
O princípio de menos espanto (ou menos surpresa) sugere que uma so-
lução ou abordagem não surpreenderia uma pessoa razoavelmente experiente
na área de assunto quando encontrada pela primeira vez (o público pode variar,
por exemplo, usuário final, programador, testador etc.).
Em termos mais práticos, o princípio visa alavancar o conhecimento pré-

existente dos usuários para minimizar sua curva de aprendizado ao usar um mó-
dulo; portanto, qualquer coisa com alto fator de imprevisibilidade é um bom can-
didato para o redesenho.
Aplica-se a todos os aspectos da arquitetura de software: dos serviços de

nomeação, à visualização de interfaces do usuário e ao design do modelo de
domínio.
16
O PRINCÍPIO DO MENOR ESFORÇO
Seu princípio (também chamado de Lei de Zipf) deriva de um comporta-

mento humano básico: todo mundo tende a seguir o caminho que é o mais pró-
ximo possível do esforço. Por exemplo, se nosso design seguir um padrão es-
pecífico, o próximo desenvolvedor seguirá o mesmo padrão repetidamente, a
menos que haja uma maneira significativamente mais fácil de executar a tarefa;
nesse caso, eles serão alterados! Ou, levando isso adiante, uma vez que eles
encontram resultados aceitáveis para uma tarefa, não há necessidade imediata
de melhorar a solução atual.
Como tal, é imperativo almejar um começo forte, colocando a arquitetura

de software certa no lugar: estabelece altas expectativas e garante que todos
entendam que a qualidade não é comprometida no ciclo de vida do projeto e
será respeitada em caso de mudanças futuras.
A grandeza desse princípio reside no fato de que seus benefícios extra-

polam: uma vez que implementamos um design correto, podemos criar uma es-
trutura arquitetônica que será a base dos próximos sistemas que construímos.
Em outras palavras, somos capazes de estabelecer um modelo bem-sucedido e
à prova de futuro para os sistemas de software da organização.
17
O PRINCÍPIO DO CUSTO DE OPORTUNIDADE
Toda vez que fazemos uma escolha, há um certo valor que colocamos
nessa escolha. O valor tem duas partes: benefícios e custos. O custo de oportu-
nidade de uma escolha é o que desistimos de obtê-la. Para tomar uma boa de-
cisão econômica, queremos escolher a opção com o maior benefício para nós,
mas com o menor custo. Por exemplo, se tivermos duas opções, um sistema
interno ou um produto de fornecedor pronto para uso e escolhermos o último,
nosso custo de oportunidade será o novo sistema brilhante que nossa equipe de
desenvolvimento poderia ter desenvolvido, mas não o fez . É disso que se trata
a arquitetura de software: ponderar as opções umas das outras e tentar tomar
uma decisão informada sobre qual delas agregará mais valor ao projeto. Por
exemplo, uma dicotomia muito comum é criar uma solução tática com tempo de
comercialização rápido ou uma solução mais estratégica, que agora será mais
cara, com o objetivo de alavancá-la em projetos futuros e, portanto, minimizar o
custo posteriormente. Aqui estão alguns pontos a considerar:
 Qual é o tempo disponível para a análise ou avaliação ar-

quitetônica?
 Qual é o pipeline de produtos para os próximos 1 a 3 anos?
E que outros projetos estão alinhados? Você consegue ver alguma siner-
gia?
 Qual é a sua dívida técnica atual que você poderia enfren-
tar?
 E, invertendo isso: quanta dívida técnica nova incorrerá se
você buscar uma solução tática?
 Quais atributos de qualidade tendem a ser os mais impor-
tantes para os sistemas em sua organização e como eles serão compro-
metidos pela solução proposta?
 Além da equipe de arquitetura de software, quem mais é
uma parte interessada que afetará a decisão? O negócio? Seu chefe?
 A Autoridade de Projeto Técnico?
18
 Quais são os principais objetivos de cada parte interessada?
 Como você irá mitigar necessidades conflitantes?
19
O PRINCÍPIO DO ÚLTIMO MOMENTO RESPONSÁVEL
Esse princípio (também conhecido como Custo do atraso) é originado do

Lean Software Development e enfatiza a realização de ações importantes e de-
cisões cruciais pelo maior tempo possível. Isso é feito para não eliminar alterna-
tivas importantes até o último momento possível, ou seja, aguarde para restringir
as opções até que você esteja melhor informado.
Uma estratégia de não tomar uma decisão prematura, mas adiar o com-
promisso e manter em aberto decisões importantes e irreversíveis até que o
custo de não tomar uma decisão se torne maior que o custo de tomar uma deci-
são.
Uma maneira de mitigar o risco de decidir tarde demais é criar a Prova de

Conceitos (POCs) para prototipar as opções alternativas e demonstrar às partes
interessadas o que elas estão pedindo.
Os princípios de arquitetura de software nos ajudam a avaliar as decisões

que tomamos ao longo do projeto e também para garantir que estamos alinhados
com os objetivos gerais, não apenas para o projeto, mas também a tecnologia
da organização.
20
PRINCÍPIOS DE DESIGN DE SOFTWARE
SEPARAÇÃO DE INTERESSES
Um princípio norteador durante o desenvolvimento é o da Separação de

Interesses. Esse princípio declara que o software deve ser separado de acordo
com os tipos de trabalho que ele executa. Por exemplo, considere um aplicativo
que inclua uma lógica para identificar itens importantes a serem exibidos ao usu-
ário, e que formata esses itens de uma maneira específica para torná-los mais
perceptíveis.
O comportamento responsável por escolher os itens a serem formatados

deve ser mantido separado do comportamento responsável por formatar os
itens, uma vez que esses comportamentos são questões separadas que são re-
lacionadas apenas coincidentes entre si.
Em termos de arquitetura, os aplicativos podem ser logicamente criados

para seguir esse princípio, separando o comportamento principal de negócios da
infraestrutura e da lógica da interface do usuário.
O ideal é que a lógica e as regras de negócio residam em um projeto

separado, que não deve depender de outros projetos no aplicativo.
Essa separação ajuda a garantir que o modelo de negócios seja fácil de

testar e possa evoluir sem estar rigidamente acoplado a detalhes de implemen-
tação de baixo nível.
A separação de interesses é uma consideração fundamental por trás do

uso de camadas em arquiteturas de aplicativo.
21
ENCAPSULAMENTO
Diferentes partes de um aplicativo devem usar o encapsulamento para

isolá-las de outras partes do aplicativo. As camadas e os componentes do apli-
cativo devem poder ajustar sua implementação interna sem dividir seus colabo-
radores, desde que contratos externos não sejam violados.
O uso adequado do encapsulamento ajuda a obter um acoplamento flexí-

vel e uma modularidade nos designs do aplicativo, pois os objetos e os pacotes
podem ser substituídos por implementações alternativas, desde que a mesma
interface seja mantida.
Nas classes, o encapsulamento é obtido por meio da limitação do acesso

externo ao estado interno da classe. Se um ator externo desejar manipular o
estado do objeto, ele deverá fazer isso por meio de uma função bem definida (ou
um setter de propriedade), em vez de ter acesso direto ao estado particular do
objeto.
Da mesma forma, os componentes do aplicativo e os próprios aplicativos

devem expor interfaces bem definidas para uso de seus colaboradores, em vez
de permitir que seu estado seja modificado diretamente.
Essa abordagem libera o design interno do aplicativo para evoluir ao longo

do tempo sem se preocupar que isso fará com que os colaboradores quebrem,
desde que os contratos públicos sejam mantidos.
22
INVERSÃO DE DEPENDÊNCIA
A direção da dependência dentro do aplicativo deve ser na direção de

abstração, não os detalhes de implementação. A maioria dos aplicativos é escrita
de forma que os fluxos de dependência de tempo de compilação estejam na
direção da execução do tempo de execução, produzindo um grafo de dependên-
cia direta. Ou seja, se A classe A chamar um método da classe B e a classe B
chamar um método da classe C, em seguida, em uma classe de tempo de com-
pilação A dependerá da classe B, e a classe B dependerá da classe C, como
mostra a Figura abaixo:
(Fonte: https://docs.microsoft.com/pt-br/dotnet/architecture/modern-web-apps-azure/architectu-
ral-principles )
23
A aplicação do princípio da inversão de dependência permite que A
chame métodos em uma abstração implementada por B, possibilitando que A
chame B em runtime, mas que B dependa de uma interface controlada por A em
tempo de compilação (invertendo, portanto, a dependência típica em tempo de
compilação). Em tempo de execução, o fluxo da execução do programa perma-
nece inalterado, mas a introdução de interfaces significa que diferentes imple-
mentações dessas interfaces podem ser conectadas com facilidade.
A inversão de dependência é uma parte fundamental da criação de apli-

cativos menos rígidos, já que os detalhes da implementação podem ser escritos
para depender e implementar abstrações de nível superior, em vez do contrário.
Como resultado, os aplicativos resultantes são mais testáveis, modulares e de
manutenção mais fácil. A prática da injeção de dependência se tornou possível
pela observância do princípio da inversão de dependência.
24
OS PRINCÍPIOS DA BOA ARQUITETURA
Já nos tempos antigos, os princípios de uma arquitetura bem projetada

eram conhecidos e descritos, por exemplo, pelo arquiteto romano Vitru-
vius em ‘De architectura’; “ Firmitas, utilitas, venustas”. A arquitetura deve ser
estável, útil e bonita.
(https://oieduardorabelo.medium.com/flexibilidade-um-princ%C3%ADpio-de-arquite-
tura-de-software-de1d9e2314bb)
Para a arquitetura de software, os princípios de estabilidade e utilidade

representam a resiliência e o ciclo de vida do sistema, e estão intimamente rela-
cionados a como a arquitetura resiste que permite mudanças ao longo do tempo.
O princípio da beleza surge quando a arquitetura está em harmonia com o am-
biente e sem desordem e complexidade desnecessárias.
Uma arquitetura de software flexível é capaz de se adaptar às mudanças

nos requisitos de ambiente e usabilidade, sem abranger mudanças estruturais.
Também é livre de estruturas rígidas que de outro modo obstruiriam a evolução
e o crescimento funcional.
25
CONSIDERAÇÕES FINAIS
Certamente há cenários em que o foco inicial na flexibilidade da arquite-

tura é de menor importância. No entanto, lembre-se de que até mesmo um apli-
cativo independente que nunca deveria ser alterado pode, de repente, ser obri-
gado a integrar-se a sistemas externos ou evoluir com novas funcionalidades.
Para a maioria dos sistemas críticos em larga escala e de negócios, é

necessário investir esforços no projeto de uma boa arquitetura para garantir que
eles possam possibilitar mudanças, alcançar a longevidade e ter uma boa apa-
rência em todos os estágios de seus ciclos de vida.
26
REFERÊNCIAS
BENJAMIM, André. Princípio Aberto/Fechado. 2020.
CASTRO, Victor. Responsabilidade única e aberto/fechado. DTI Digi-

tal. 2018.
FELIPE, Marcos. O Princípio da Substituição de Liskov. 2018.
HENRIQUE, Jefferson. 5 princípios fundamentais da arquitetura de

software. Pastelaria de software. 2020.
LOPES, Felipe Tório. Princípios e Práticas em Arquitetura de Sof-

tware. Instituto de Gestão em Tecnologia da Informação.2016.
NAKAGAWA, Elisa Yumi. Análise e Projeto Orientados a Objeto, SCE

526. 2013.
RABELO, Eduardo. Flexibilidade: Um princípio de Arquitetura de Sof-

tware. 2019.
ROBERTO, Jones. Princípio de inversão de dependência. 2019.
VERGÍLIO, Silvia Regina. Arquitetura de Software.
27
28
BANCO DE DADOS E ARQUITETURA PARA BIG DATA
1
NOSSA HISTÓRIA



2
Sumário
INTRODUÇÃO ........................................................................................ 4
CONTEXTO HISTÓRICO ........................................................................ 6
O QUE É O BIG DATA ............................................................................ 7
FASES DO PROCESSO DE ANÁLISE DO BIG DATA ......................... 10
VANTAGENS DO USO DO BIGA DATA ............................................... 11
DESAFIOS DA UTILIZAÇÃO DO BIG DATA ........................................ 14
O QUE É UMA ARQUITETURA DE DADOS ........................................ 16
ARQUITETURA PARA BIG DATA ........................................................ 17
IMPLANTAÇÃO DE BIG DATA ............................................................. 19
VISÃO FUNCIONAL DO BIG DATA ...................................................... 21
O QUE É PRECISO PARA SE OBTER SUCESSO NA

IMPLEMENTAÇÃO DO BIG DATA .................................................................. 23
REFERÊNCIAS ..................................................................................... 26
3
INTRODUÇÃO
Seu conceito pode ser definido como ferramentas e práticas que geren-
ciam e analisam grandes volumes de dados de diferentes fontes, em velocidade
considerável, buscando agregar as organizações, valor de negócios e maior con-
fiabilidade em relação às decisões a serem tomadas.
Este artigo visa esclarecer a concepção e conceito de Big Data, sua utili-
zação nas organizações, apresentar as tecnologias envolvidas, para que desta
maneira as empresas possam utilizar desses recursos, contando com os bene-
fícios de que dispõe para um maior gerenciamento e apoio na tomada de deci-
sões.
Com a popularização da internet e o surgimento de mídias sociais, o nú-

mero de dados digitais gerados aumentou de forma significativa. Esses dados
podem ser classificados em estruturados e não estruturados, com base no seu
gerenciamento e armazenamento.
Os dados estruturados são organizados em linhas e colunas, geralmente

são encontrados em banco de dados relacionais, são eficientes quanto à recu-
peração e processamento. Já os dados não estruturados referem-se a dados
que não podem ser organizados em linhas e colunas, como vídeos, comentários
em redes sociais e e-mails, entre outros.
Geralmente são dados de difícil acesso e recuperação e muitas vezes não

dispõem de componentes necessários para identificação de tipo de processa-
mento e interpretação, tornando o seu uso um desafio principalmente em aplica-
tivos empresariais.
Grande parte dos dados digitais gerados atualmente, principalmente atra-

vés de mídias sociais, os quais vêm despertando o interesse das organizações
para serem usados como estratégias de negócio, são do tipo não estruturados.
4
Esse tipo de dados requer dispositivos de armazenamento e processamento que
suportem seu formato e garantam melhor eficiência em suas análises. Diante
desta necessidade crescente de armazenar, manipular e analisar de forma rá-
pida e inteligente, grandes volumes de dados não estruturados foi criado o con-
ceito de Big Data.
5
CONTEXTO HISTÓRICO
Na década de 1940 já se falava em "explosão de dados" e "grandes volu-

mes de dados", porém, foi na década de 1990 que na divulgação de um artigo,
a IEEE mencionou o termo “Big Data" pela primeira vez. Em 2001, o termo pas-
sou a ser definido pelos 3Vs, de: Volume, Velocidade e variedade. O conceito
de Big Data pode ser definido como ferramentas e práticas que gerenciam e
analisam grandes volumes de dados, de diferentes fontes, em velocidade consi-
derável, buscando agregar às organizações valor de negócios e maior confiabi-
lidade em relação às decisões a serem tomadas.
Para as organizações aderirem com sucesso a esse novo conceito de

análise e gerenciamento de grandes volumes de dados, é recomendado o cum-
primento de algumas fases, são elas:
1) aquisição e gravação;
2) limpeza, formatação e validação;
3) integração, agregação e representação;
4) análise e modelagem; e
5) interpretação dos dados.
O cumprimento das fases acima garante maior confiabilidade quanto à
utilização do conceito Big Data.
6
O QUE É O BIG DATA
Big Data são tecnologias e práticas emergentes que possibilitam a sele-

ção, processamento, armazenamento e geração de insights de grandes volumes
de dados estruturados e não estruturados de maneira rápida, efetiva e a um
custo acessível. Big Data pode ser considerado como um conjunto de dados que
cresce exponencialmente e necessita de habilidades além das quais as ferra-
mentas típicas de gerenciamento e processamento de informações dispõem.
Taurion descreve ainda que se trata de "Um conjunto de tecnologias, pro-

cessos e práticas que permitem às empresas analisarem dados a que antes não
tinham acesso e tomar decisões ou mesmo gerenciar atividades de forma muito
mais eficiente”. Segundo o autor citado acima "não é teoria ou futurologia, é algo
que se encontra agora”.
Big Data pode ser definido também, como um grande data warehouse ou
um BI em cima de um data set de terabytes de dados ou também como um
volume de dados muito significativo, porém não se trata apenas de volume, mas
também de uma variedade imensa de dados não estruturados que precisam ser
avaliados e tratados em velocidade adequada para terem valor ao negócio.
De maneira mais simples, resume-se em "Big Data = volume + variedade

+ velocidade + veracidade, gerando valor". Volume refere-se à quantidade de
dados gerados a cada segundo, variedade, porque os dados vêm de diversas
fontes (estruturados e não estruturados), velocidade, pois se trata muitas vezes
de informações em tempo real, veracidade, porque é necessário que os dados
sejam autênticos e façam sentido e, por fim, valor, pois é o que as organizações
buscam, ou seja, o retorno dos investimentos.
7
Com a expansão dos conceitos de Big Data, diversas empresas já estão
tomando iniciativas para aderir ao mesmo, porém, sem uma estratégia bem de-
finida, afinal, "Big Data não é apenas comprar pacotes de tecnologia, mas uma
nova maneira de explorar esse imenso volume de dados que circula dentro e
fora das empresas". Para aderir ao Big Data , as empresas devem estar cientes
de que serão embutidas transformações em processos de negócio, fonte de da-
dos, infraestrutura de tecnologia, capacitação e mudanças organizacionais na
empresa e em TI.
O conceito de Big Data dispõe de inúmeras vantagens para as organiza-

ções, mas a principal vantagem é a identificação das necessidades dos clientes,
sendo possível desenvolver estratégias de mercado e apoio a tomada de deci-
sões mais precisas. Contudo, surgem também alguns desafios, como trabalhar
com a segurança e confiabilidade dos dados.
Para auxiliar as organizações nos processos relacionados ao Big

Data existem ferramentas analíticas como o Hadoop e MapReduce, tam-
bém banco de dados NoSQL, que estão preparados para armazenar, gerenciar
e analisar grandes volumes de dados de diferentes formatos.
O número de dados gerados por meios eletrônicos tem aumentado signi-

ficativamente com o desenvolvimento da tecnologia. Atualmente são gerados
mais dados do que a civilização gerou desde o seu início até o ano de 2003.
Com todo este volume de dados surgem possibilidades de análise e gerencia-
mento, de maneira a gerar informações úteis na tomada de decisão das empre-
sas. Esta nova maneira de armazenar, gerenciar e analisar grandes volumes de
dados de diversas fontes, a uma velocidade considerável denomina-se Big Data.
Contudo, a maioria das empresas ainda não tem uma visão clara do con-
ceito Big Data, do seu potencial e de como alavancar esta potencialidade. Bem
como, de que a ideia de que Big Data só faz sentido se o valor da análise dos
dados compensar o custo de sua coleta, armazenamento e processamento e as
questões legais envolvidas.
8
Dados podem ser caracterizados como uma descrição primária de obje-
tos, eventos, atividades e transações que são gravados, classificados e armaze-
nados, mas não chegam a ser organizados de forma a transmitir algum signifi-
cado específico. Quando esse conjunto de registros sobre um determinado
evento, fato, número, texto ou qualquer mídia que possa ser processada pelo
computador, é agrupada, caracterizado e padronizado, transforma-se em infor-
mação.
Antes de serem transformados em informação, os dados podem ser divi-

didos em dois grupos, segundo o armazenamento e gerenciamento. No primeiro
grupo encontram-se os dados estruturados e no segundo os dados não estrutu-
rados.
Os dados estruturados são organizados em linhas e colunas em um for-

mato definido de forma rígida, de modo que os aplicativos possam recuperá-los
e processá-los com eficiência. Já os dados não estruturados são os que não
podem, ou são difíceis de serem armazenados em linhas e colunas.
Geralmente são de difícil acesso e recuperação e requerem maior espaço

e velocidade para armazenamento e gerenciamento. São muitas vezes dados
que não dispõem de componentes necessários para identificação de tipo de pro-
cessamento e interpretação, tornando o seu uso um desafio, principalmente em
aplicativos empresariais.
O formato de dados não estruturados corresponde a 80% dos dados cor-

porativos, podendo ser encontrados na forma de e-mails, comentários em redes
sociais, vídeos, entre outros.
9
FASES DO PROCESSO DE ANÁLISE DO BIG DATA
Para que ocorra sucesso com o uso desse novo conceito, é necessário
que as organizações sigam algumas fases do processo de Big Data.
A coleta de dados ou aquisição e agravação é a primeira fase do processo

de Big Data. Nesse momento devem ser analisados o volume e a variedade dos
dados que serão coletados. É necessário que se faça uma limpeza, formatação
e validação dos dados coletados, para que sejam eliminados erros, dados in-
completos e incoerentes, evitando assim contaminar análises futuras.
Depois disso vem a fase de integração, agregação e representação dos

dados obtidos, pois diferentes tipos e formatos de dados devem receber trata-
mentos específicos. Nesta fase é importante definir categorias de dados e crité-
rios de validação e aceitação, também critérios de segurança variam de acordo
com as fontes de dados.
Em seguida encontra-se a fase de análise e modelagem dos dados. Como

se trata de dados de diversas fontes para serem analisados, requer conheci-
mento elevado por parte dos usuários. Aqui entra o "datascientist", um profissio-
nal com habilidades em ciência da computação, matemática, estatística e conhe-
cimento de negócio. Esta fase também requer investimentos em pesquisas de
novas formas de visualização, que ajudam na melhor interpretação dos dados,
que se trata da última fase do pipeline.
10
VANTAGENS DO USO DO BIGA DATA
Algumas das possíveis vantagens de seu uso são:
Saber exatamente o que os clientes querem, estudando seus hábitos de

consumo. O conhecimento das necessidades do cliente faz com que possa ser
oferecido ao mesmo exatamente o que deseja, ganhando assim a confiança;
Encontrar potenciais compradores a partir da mensuração em tempo real

das redes sociais. O desenvolvimento da tecnologia permite que pessoas de di-
versas localidades geográficas conheçam o produto e ofertas em tempo real,
com isso pode ocorrer expansão nas vendas;
Prevenir possíveis riscos para o negócio graças a análises em tempo real

de distintas variáveis do mercado. Pode ser analisado em tempo real tudo o que
está ocorrendo no mercado, sendo assim, existe possibilidade de tomar medidas
preventivas e antecipatórias em relação a dificuldades e oportunidades;
Observar o que a concorrência está fazendo para desenhar ofertas espe-

ciais. Conhecer o concorrente e pensar alternativas para aumentar lucros.
Todas as observações citadas pela SAP dispõem às organizações um

diferencial de mercado e vantagem competitiva em relação a seus concorrentes.
As vantagens do Big Data estão relacionadas a dois fatores:
 O efeito dos grandes números, que garante a validade das

análises;
A capacidade de adicionar uma multiplicidade de novos vetores de

preferência, complementando e enriquecendo a qualidade das análises
devido à observação de comportamentos específicos em indivíduos com
características similares.
11
Estes fatores podem ser melhor explicados nos seguintes itens:
 Transformação de dados não estruturados em informação

útil para análise sistemática, através de técnicas de Big Data que possibi-
litam a atribuição de indicadores de “sentimento”. Neste sentido, existem
já diversos softwares que classificam os comentários produzidos nas re-
des sociais de acordo com o teor das mensagens e a sua intensidade;
 Utilização dos dados de forma experimental, correlacio-
nando grandes volumes de dados quantitativos históricos com informação
recente, depois de passar pelo processo de estruturação (por exemplo,
comentários realizados em blusões) e antecipando assim as expectativas
do mercado;
 Segmentação exaustiva dos diversos perfis de consumo,
permitindo identificar clusters de clientes e adaptar as abordagens de
forma micro segmentadas, sempre que possível em real time (por exem-
plo, utilização de promoções por georreferencia);
 Aceleração do processo de inovação das empresas, com
reflexo na rapidez do desenvolvimento de ideias para novos produtos e
serviços e na sua performance esperada, permitindo endereçar não só o
desafio de criar ofertas inovadoras como também de gerir de forma proa-
tiva todo o customer life cycle – desde a captação à retenção, incluindo
mecanismos de aumento de valor e da satisfação dos clientes nas intera-
ções realizadas ao longo dos diversos pontos de contato.
O Big Data traz às empresas a grande oportunidade de obtenção da ex-

celência no conhecimento mais adequado e imediato do cliente e do mercado.
Essa eficiência está ligada a qualidade das informações integrada aos diversos
sistemas corporativos e que os ganhos serão obtidos por aqueles que percebe-
rem o sentido de ampliar a gama das fontes de dados e garantir veracidade e
velocidade, bem como a proximidade no relacionamento com seus clientes.
12
O caminho da obtenção de vantagens competitivas trazidas pelo Big Data
é o conhecimento profundo do negócio para perceber e chegar à combinação
ideal de dados e informações sobre o cliente e o mercado, que possam favorecer
a estratégia, eficácia, aceitação da proposta de valor, prever tendências de con-
sumo e, por fim, alcançar avanços na realização dos objetivos estratégicos da
empresa.
13
DESAFIOS DA UTILIZAÇÃO DO BIG DATA
Para alcançar a efetividade do Big Data é necessário que os benefícios

estejam claros e os incentivos alinhados, criando condições de aprofundar téc-
nicas e utilizá-las nas organizações. Alguns dos principais desafios do Big Data
são:
Políticas de privacidade, acesso, tratamento e utilização da informação:

se por um lado é imprescindível garantir a proteção da privacidade dos clientes,
por outro lado só será possível melhorar a qualidade dos dados analisados se
estiver garantida o recolhimento sistemático de informação. Mas como garantir
que os clientes disponibilizem, por exemplo, informação da sua localização
atual? Como conseguir relacionar um determinado cliente com o seu perfil nas
redes sociais? O envolvimento dos clientes é crítico porque só dessa forma o
ciclo de Big Data ficará completo;
Avanço tecnológico e multidisciplinaridade: à medida que o volume de da-

dos aumenta, maiores são os desafios que se colocam à capacidade de arma-
zenamento e análise. Os principais provedores de tecnologia têm apostado for-
temente em novas técnicas de storage, data mining e business intelligence. No
entanto, uma maior colaboração com as áreas de negócio e os principais influ-
enciadores em cada indústria será crítica para conseguir adaptar a tecnologia às
necessidades imediatas das empresas, sem ter de passar por processos moro-
sos e custosos de implementação;
Orientação para o cliente: apenas percebendo o fim para o qual se desti-

nam os dados é útil aprofundar as metodologias de Big Data. Exceder as expec-
tativas do cliente deverá ser a principal finalidade. Para isso, a organização de-
verá desenvolver estratégias globais que permitam integrar os modelos de dados
com os modelos de relação nos diversos pontos de contato de forma holística e
dinâmica, adaptando-se à expectativa de cada cliente a cada momento.
14
Outro desafio visível em relação ao Big Data é a falta de profissionais
qualificados. A EMC Brasil realizou uma pesquisa onde 73% das empresas en-
trevistadas apontaram a cultura como sendo a maior barreira de lidar com o Big
Data. O levantamento destaca que 88% das companhias acreditam que será um
desafio capacitar seus trabalhadores para a nova TI.
15
O QUE É UMA ARQUITETURA DE DADOS
A arquitetura de dados é um daqueles componentes invisíveis, mas que,

quando falham, podem comprometer seriamente a performance de uma em-
presa e seus profissionais.
É como em edifícios físicos que, sem um projeto arquitetônico à altura,

têm suas funções mal aproveitadas, ficando sujeitos a problemas.
Este é um mapa mental para visualizar os principais componentes de uma

Arquitetura de Big Data:
(Fonte: https://canaltech.com.br/big-data/Visao-geral-da-Arquitetura-de-Big-Data/)
16
ARQUITETURA PARA BIG DATA
Arquiteturas em Big Data podem fornecer soluções capazes de analisar

grande volume de dados em tempo real. Para esta análise utiliza-se banco de
dados não relacionais também conhecidos como NoSQL. As tecnologias da Big
Data são acessíveis para pequenas e medias empresas, trazendo muitos bene-
fícios.
Os resultados obtidos através destas tecnologias, nos apresentada dados

que podem melhor a maneira de relacionamento com os clientes. [Pensando
Grande, 2016].
As tecnologias para Big Data oferecem novas oportunidades em análise

e compreensão mais aprofundada dos dados. Mapeando os padrões dos dados,
sendo estruturados e não estruturados. Para este mapeamento utiliza-se ferra-
mentas com grande poder computacional, e modelo de computação paralela.
Big Data mudou a forma de entender e explorar os dados, pois a análise

dos dados é impulsionada a uma investigação não causal. Big Data tem o con-
ceito de ampliar o potencial das analises, mas Big Data não é somente o volume
de dados, está também ligada a variedade, ao acesso a outras fontes de dados,
esta fonte geralmente é externa, possibilitando assim uma ampliação da visão
do contexto.
Para Jill Dyché vice-presidente da SAS Best Pratices, Big Data é mais
que apenas um grande volume de dados não estruturados, ele também conclui
que as tecnologias que possibilita o processamento e análise, estas tecnologias
possibilitam analisar conteúdo de forma rápida. [Davenport 2014].
Para atender a demanda é necessário estabelecer uma arquitetura tec-

nológica compatível. O momento tecnológico que vivemos permitiu estabelecer
formas de armazenar dados não estruturados. Armazenar e recuperar dados não
17
estruturados exige uma forma diferenciada em relação ao que tem sido feito até
então. Um novo padrão de banco de dados foi criado para isto. Eles são chama-
dos de NoSQL (Not Only SQL). E os bons e velhos arquivos texto, imagens, voz,
etc. que são armazenados diretamente no sistema operacional voltam a fazer
parte do contexto da análise de dados.
Os bancos de dados padrão SQL são amplamente conhecidos no mundo

corporativo. Eles facilitaram muito o acesso e disponibilização dos dados nas
organizações. Porém, eles foram criados para lidar com dados estruturados.
Quando se fala em dados estruturados, o que se quer dizer é que o dado estará
formatado para trabalhar com um padrão baseado em linhas e colunas, com uma
sintaxe robusta e uma modelagem consistente. Como informado anteriormente,
para manipulação de dados não estruturados utiliza-se muitas vezes o próprio
sistema de arquivos (Linux e MS Windows, por exemplo).
Os principais componentes desta arquitetura são (mas não se limitam a):
1. Hadoop: plataforma para armazenamento e processamento

de um grande volume de dados utilizando hardware simples e que nor-
malmente utilizam clusters para agilizar o acesso e manipulação dos da-
dos;
2. MapReduce: modelo de programação paralela, escalável e
que permite a utilização de hardware simples para realizar trabalhos com-
plexos;
3. NoSQL: banco de dados que permite armazenar e recupe-
rar dados com menos restrições do que os bancos de dados relacionais.
Possui uma modelagem mais simples e permite aumentar a escalabili-
dade e disponibilidade do ambiente;
4. SQL: bancos de dados tradicionais que armazenam a maior
parte dos dados estruturados nas organizações. Os dados normalmente
têm origem em sistemas ERP, SCM (Supply Chain), CRM, etc.;
5. DW: O Data Warehouse é um banco de dados apartado do
banco de dados dos sistemas transacionais que são modelados para fa-
cilitar a análise de dados para a tomada de decisão.
18
A utilização de alguns destes componentes em conjunto indica o trabalho
em um ambiente de Big Data. Ao se utilizar um dos componentes isoladamente,
dificilmente se estará trabalhando com Big Data.
IMPLANTAÇÃO DE BIG DATA
A Visão de Implantação mostra o ambiente onde o sistema será instalado,

bem como o software sugerido para sua execução. Os sistemas de big data cri-
ados a partir desta arquitetura são implantados em um datacenter, uma nuvem
pública ou privada. Os servidores podem ser VMs ou máquinas físicas (bare me-
tal), pois não há significativa perda de performance. Para a criação de provas de
conceito é possível utilizar um único servidor desempenhando todas as funções.
Neste caso, a performance não pode ser avaliada, porque os recursos compu-
tacionais são limitados. Apesar disso, é possível validar se as funcionalidades
foram atendidas.
Existem quatro funcionalidades principais previstas na arquitetura, que

atendem às demandas dos sistemas de big data. As funcionalidades são: (i) Clu-
ster de Big Data, no qual residem os serviços de Armazenamento e Análise de
Dados. O (ii) Servidor de API engloba o serviço de Integração de Dados, en-
quanto o (iii) Servidor NoSQL engloba o Gerenciamento de Dados. Por fim, o (iv)
Storage oferta novamente o serviço de Armazenamento de Dados, com a dife-
rença de que nesta configuração não existe a necessidade do cluster de big data,
pois é utilizada a tecnologia de object storage e data lakes, que é uma tendência
no mundo do big data.
19
(Fonte: https://blog.marcoreis.net/arquitetura-de-referencia-para-solucoes-de-big-data/ )
20
VISÃO FUNCIONAL DO BIG DATA
A Visão Funcional descreve os usos, os componentes, as interfaces, as

entidades externas e as principais interações entre eles, como pode ser visto na
figura abaixo.
(Fonte: https://blog.marcoreis.net/arquitetura-de-referencia-para-solucoes-de-big-data/ )
O componente de Fonte de Dados é uma entidade externa que repre-

senta, como o nome sugere, qualquer mecanismo que forneça dados corporati-
vos, e inclui os SGBDRs, os sistemas de arquivos e os web services.
O ETL de Big Data realiza o processamento necessário para converter os

dados de seu formato de origem para os formatos suportados pelo mecanismo
de armazenamento de big data.
O sub-sistema de Administração de Dados é um componente lógico que

envolve dois componentes. O primeiro deles é o serviço de Armazenamento de
Dados, responsável por persistir os dados no sistema de arquivos distribuído. O
componente de Gerenciamento de Dados é constituído pelo banco de dados
NoSQL. Este sub-sistema dispõe de uma interface para que novos registros se-
jam inseridos sem a necessidade de passar pelo ETL de Big Data. A outra infer-
face permite que os demais componentes consumam diretamente os dados.
O Processamento de Dados é composto pelos mecanismos para proces-
samento batch e tempo real, além de oferecer suporte para a implantação de
21
programas de big data, como Hadoop e Spark, a partir de seus respectivos fra-
meworks.
O serviço de Integração de Dados é uma funcionalidade presente nas ar-

quiteturas de big data mais recentes. Ele oferece uma API para que entidades
externas consumam os dados do sistema. A API é construída a partir de um
banco NoSQL e disponibilizada por meio de web services, uma tendência na
área de big data e computação em nuvem.
O último serviço é o de Análise de Dados, que combina mecanismos de

consulta ad hoc, de estatística e de algoritmos de machine learning. Estas funci-
onalidades são usadas pelos cientistas de dados e fazem parte de uma área
conhecida como big data analytics.
22
O QUE É PRECISO PARA SE OBTER SUCESSO NA IMPLE-
MENTAÇÃO DO BIG DATA
O sucesso na construção de uma arquitetura Big Data depende principal-

mente da clareza do escopo, quais perguntas devem ser respondidas e por con-
sequência o valor a ser gerado, encontrado através dos conhecimentos dos 5Vs,
volume, velocidade, variedade, veracidade e valor. Com um crescimento cons-
tante no volume de dados da tabela calls, a proposta de uma arquitetura em Big
Data e de total coerência, uma vez que este modelo arquitetural consta de um
poder computacional muito amplo para tratar grande volume e variedade de da-
dos, além de poder oferecer insight sobre o valor destes dados que antes não
eram percebidos.
Oferecendo novas oportunidade de negócios através de analises de Bu-

siness Intelligence aliadas ao Big Data e outras tecnologias que fazem parte do
ecossistema. O ecossistema utilizando tecnologias com o Apache Hadoop, Ha-
doop MapReduce, Apache HDFS e o Elasticsearch agregam valor fundamental
para a arquitetura, a união e a sincronização delas proporciona recursos muito
amplos, recursos que atualmente não fazem parte do escopo inicial deste pro-
jeto, mais que podem em trabalhos futuros agregar esta arquitetura.
Uma desta tecnologias que vem ser consolidando cada vez mais neste
modelo de arquitetura, é o banco NoSQL, com um paradigma diferente do banco
de dados relacional, eles propõem maneiras diferentes de armazenamento dos
dados, seja no modelo de chavevalor, família de colunas, orientado a documen-
tos e baseado em grafos.
Cada modelo tem suas particularidades para resolver determinados ce-

nários, mas o modelo relacional também tem suas particularidades, não pode-
mos afirmar que um substitui o outro, mais sim que cada um tem seus benéficos,
assim cada um é melhor utilizado para atender determinados cenários.
23
Nesta apostila foi apresentado a arquitetura para sistemas de big data, na

qual as análises devem ser feitas preferencialmente em data lakes. Esta é uma
tendência que está sendo seguida pelos principais provedores de big data do
mercado.
Assim, verificamos que as arquiteturas e frameworks para big data estão

se desenvolvendo de acordo com as mudanças na tecnologia e nas demandas
de novas soluções para problemas que lidam com uma quantidade crescente de
dados. Para tanto, novas alternativas são propostas utilizando processamento
distribuído, paralelo e escalável.
Sem uma boa visão e definição de Negócio, é impossível ter uma solução
ou mesmo um projeto de Big Data. Saber a questão adequada para um problema
de Big Data e vincular esta questão com uma necessidade real do negócio da
empresa é fundamental para este tipo de projeto. Identificar oportunidades com-
petitivas envolve conhecer melhor o cliente, o produto, a cadeia de distribuição
ou produção, os fornecedores e os competidores. Big Data pode ser uma boa
ferramenta para atender este objetivo. Mas sem ter em mente com clareza e
precisão onde se quer chegar, fatalmente este tipo de projeto estará fadado ao
fracasso.
Outro elemento extremamente importante está no Armazenamento dos

Dados (o primeiro dos três Vs de Big Data). O Armazenamento envolve questões
que nascem em uma Plataforma Distribuída, passa pelos bancos específicos
(NoSQL) e terminam em um ambiente de Tomada de Decisão (representado
pelo SQL e Data Warehouse no mapa). Não considero um grande problema.
Atualmente há ferramentas que atendem com relativa facilidade esta questão.
24
A Escalabidade tem a ver com o Volume, mas também envolve a Varie-
dade das origens (o segundo dos Vs) encontrada neste tipo de projeto. E isso se
resolve com Processamento Paralelo, Bancos Não-Relacionais (NoSQL) e
Cloud Computing. É uma solução técnica. Certamente irá evoluir para facilitar o
processo, mas não é algo que deva atemorizar o condutor deste tipo de projeto.
A Coleta e Integração de Dados também é um problema que envolve os

dois primeiros Vs. Está relacionado com Cloud Computing, mas encontra seus
principais desafios na Ingestão e Limpeza / Tratamento de Dados. Permitam-me
a redução conceitual, mas a Ingestão para mim é um ETL de alta complexidade,
com inúmeras fontes e com técnicas de solução do problema muito semelhantes,
mas, naturalmente, adaptadas ao volume e variedade de dados do Big Data.
A Segurança não está apenas relacionada à questão da Governança e
seus acordos para acesso, controle e disseminação dos dados. Está intima-
mente relacionada à questão Ética. O que é ético fazer com dados que na grande
maioria das vezes são públicos? Como uma análise dos dados públicos pode
interferir na vida das pessoas? Estas questões precisam de calma e sensatez
para que se possa encontrar as respostas.
A Visualização dos Dados envolve o uso e a prática de técnicas estatísti-

cas adequadas para responder às questões de negócio que justificarão o desen-
volvimento do projeto. Com estes importantes recursos da matemática, será pos-
sível estabelecer Análises de Correlação que utilizam técnicas de Data Mining
(mineração de dados) aplicadas em um grande volume de dados.
Por fim, e não menos importante, o uso de técnicas de Análise avança-

das, Machine Learning (aprendizagem de máquina) com algoritmos especial-
mente testados, desenvolvidos e aplicados para modelos de previsão permitem
que o terceiro V (Velocidade) atenda às necessidades do negócio. Mostrar estas
análises de maneira adequada ao tomador de decisão ou estabelecer visualiza-
ção para modelos criados é o produto final de um projeto de Big Data.
25
REFERÊNCIAS
CUKIER, Kenneth. MAYER-SCHONBERGER, Viktor. “Big data: como

extrair volume, variedade e valor da avalanche de informação cotidiana;
tradução Paulo Polzonoff Junior”, Rio de Janeiro, Elsevier. 2013.
FILHO, Osilmar Mendonça Costa, CARDOSO, Marcelo de Castro. Arqui-

tetura em Big Data para organização de milhões de ligações em uma em-
presa de Telecom. Centro Universitário de Anápolis (UniEvangélica) – Anápolis,
GO – Brazil.
PODEROSO, Celso. Big Data – arquitetura do ambiente. 2014.
REIS, Marcos. Arquitetura de Referência para Soluções de Big Data.

2018.
TAURION, Cezar. “O caos conceitual e os 5 Vs do Big Data”. 2012.
26
ARQUITETURA DE SOFTWARE E DE DADOS SEGUROS
1
NOSSA HISTÓRIA



2
Sumário
INTRODUÇÃO ........................................................................................ 4
PORQUE SE PENSAR EM SEGURANÇA.............................................. 5
APRENDENDO SOBRE A IMPORTÂNCIA DE UM SOFTWARE

SEGURO ............................................................................................................ 6
O QUE É IMPORTANTE NO DESIGN DE UM SOFTWARE SEGURO? 7
SEGURANÇA É UM PROCESSO ......................................................... 12
QUAL É O PROCESSO DE DESENVOLVIMENTO DE UM SOFTWARE

SEGURO? ........................................................................................................ 14
BOAS PRÁTICAS DE SEGURANÇA DE SOFTWARE ......................... 15
A DIFERENÇA DE UM SOFTWARE SEGURO E INSEGURO ............. 17
ESTILO ARQUITETURAL ..................................................................... 18
A IMPORTÂNCIA DO REÚSO .............................................................. 20
REFERÊNCIAS ..................................................................................... 25
3
INTRODUÇÃO
Como o aprimoramento da modelagem de ameaças afeta o ciclo de vida

do desenvolvimento de software
A busca pela transformação digital tem guiado as estratégias de negócios

nos dias atuais e, neste contexto, vários pilares da área de TI se destacam, entre
eles: o desenvolvimento de software (olhe ao seu redor e pergunte a si mesmo:
a que distância você está de um aplicativo de software?), e a segurança da in-
formação, cujo valor reside na redução de riscos (um dos princípios da gover-
nança de TI).
Considerando a velocidade com que as práticas estão mudando, o de-

senvolvimento e o uso de software podem frequentemente parecer mais uma
arte do que uma ciência. Conforme as ferramentas e metodologias de software
se tornam cada vez mais disponíveis, há uma maior oportunidade de desenvol-
ver softwares, mas também de fraudar os sistemas existentes. Além disso, o
software agora é amplamente compartilhado e novas abordagens para reduzir o
custo de desenvolvimento, minimizar os riscos da segurança da informação e
aumentar a velocidade de entrega estão em constante crescimento e expansão.
À medida que as organizações confiam nas tecnologias em evolução, padrões
de falha operacional, uso indevido e abuso emergem com mais frequência desde
uma variedade de fontes, bem como de práticas internas fracas durante a aqui-
sição ou desenvolvimento de software.
4
PORQUE SE PENSAR EM SEGURANÇA
Competência tecnológica é fundamento para o sucesso nos negó-

cios. Cadeias produtivas estão cada vez mais integradas. No “chão de fábrica”,
as máquinas físicas já têm “gêmeas digitais”. No varejo, as vendas são apoiadas
por tecnologia e ocorrem em multicanalidade, com curadoria individual.
Fora das empresas, a tecnologia vem impactando, de maneira evidente,

cada vez mais, o dia-a-dia das pessoas. Bens de consumo têm cada vez mais
sensores, processadores e conexões com a internet. Produtos tecnológicos são
canais por onde consumimos serviços, muitos deles essenciais.
A onipresença de sistemas digitais, tanto na indústria quanto nas rotinas

individuais, além de aumentar o impacto percebido de falhas acidentais, os tor-
nam alvos naturais para ataques criminosos. Por isso, segurança é atributo de
qualidade cada vez mais importante em arquiteturas modernas. Sistemas inse-
guros ameaçam empresas, tanto sob aspectos diretamente financeiros e de ima-
gem, e, não raro, a vida das pessoas!
Infelizmente, sistemas dificilmente serão seguros acidentalmente, ou

seja, sem projeto apropriado. O acaso, quando se trata de segurança em siste-
mas, é desfavorável e não dá proteção aos distraídos.
5
APRENDENDO SOBRE A IMPORTÂNCIA DE UM SOF-
TWARE SEGURO
Se você quer construir um sistema seguro, você precisa entender de de-

sign seguro. Espero que você não comece lendo Secure Software Design, de
Richardson e Thies. Enquanto o livro descreve muitas das principais questões
em segurança de aplicações de segurança e TI em geral, e algumas ameaças e
vulnerabilidades comuns, ele (ironicamente, dado o título) não explica como fa-
zer design de software seguro.
E muito da “informação prática” no livro é no mínimo perigosa, mas não

totalmente correta: a seção sobre XSS, por exemplo, que menciona o escape da
saída, não explica como fazê-la corretamente, ou que é muito mais importante
que ficar limpando a entrada, removendo caracteres desnecessários ou alte-
rando caracteres necessários, mas possivelmente perigosos” (no entanto, você
iria fazer isso de forma segura). Ou o principalmente errado: a seção de design
de banco de dados seguro- não, “Uma das maneiras mais simples de proteger
uma aplicação web de um ataque de injeção de SQL é validar todos os parâme-
tros de entrada” não é correto, e “Você também deve evitar a dinâmica SQL e
usar procedimentos parametrizados armazenados” não está perto o suficiente
de ser correto para ser compreendido ou seguido corretamente.
O livro faz aumentar a conscientização sobre as questões de segurança

de aplicativos e, logo no início, os autores apontam os leitores para CERT ,
SANS e OWASP, então não há esperança de que os alunos vão encontrar e
utilizar esses recursos em vez de confiar nesse livro.
6
O QUE É IMPORTANTE NO DESIGN DE UM SOFTWARE SE-
GURO?
Há muitos erros arquitetônicos e de design básicos que podem compro-

meter a segurança de um sistema:
Falta algo importante em recursos de segurança, como requisitos de au-

ditoria, privacidade e conformidade de controle de acesso;
Erros técnicos na compreensão e implementação de defesa se segurança

contra as “artes do mal”, como criptografia, gerenciamento de segredos e geren-
ciamento de sessão (você não sabe o suficiente para fazer algo ou para fazê-lo
direito);
Incompreensão de responsabilidades arquitetônicas e zonas de confi-

ança, como contar com a validação do lado do cliente ou “Eu pensei que os
dados já tinham sido higienizados”;
Deixar a superfície de ataque maior do que tem que ser porque a maioria
dos desenvolvedores não entende o que é superfície de ataque de um sistema
ou sabe que precisa estar atenta quando mudá-la;
Permitir acesso por padrão, então quando acontece um erro ou alguém

se esquece de adicionar a verificação certa no lugar certo, as portas e as janelas
são deixadas abertas, e os bandidos podem entrar;
Escolher uma plataforma de desenvolvimento inseguro ou uma pilha de

tecnologia, ou um framework, ou uma API, e herdar o design e os erros de codi-
ficação de alguém;
7
Cometer erros estúpidos em fluxos de trabalho de negócios que permitem
que os atacantes ignorem as verificações e os limites, e roubem dinheiro ou in-
formações.
Todos esses fatores compreendem o projeto no nível arquitetural e estão
diretamente relacionados com a organização do sistema e, portanto, afetam os
atributos de qualidade (também chamados de requisitos não funcionais) como
desempenho, portabilidade, confiabilidade, disponibilidade, entre outros. Se fi-
zermos uma comparação entre arquitetura de software (caracterizada, por
exemplo, pelo estilo em camadas) e arquitetura ‘clássica’ (relativa à construção
de edificações), podemos observar que o projeto arquitetural é determinante
para o sucesso do sistema.
A Tabela 1 destaca aspectos da representação de projeto que captura

elementos característicos da arquitetura enquanto que as restrições estão asso-
ciadas a atributos de qualidade e, portanto, servem como determinantes nas de-
cisões do projeto arquitetural. Por exemplo, embora o uso de múltiplas camadas
facilite a manutenção de um sistema de software, também contribui para degra-
dar o desempenho do sistema. Uma tática tem sido reduzir o nível de acopla-
mento entre componentes para não comprometer o desempenho do sistema.
Dessa forma, se adotarmos uma redução no nível de acoplamento dos compo-
nentes, eles terão menor necessidade de comunicação entre si, o que resulta
num melhor desempenho.
Tabela 1. Comparação de aspectos arquiteturais.
Catego-
Representações
rias arquitetu- Restrições
de projeto
rais
8
Modelos, dese- Padrão de circulação,
Arquite-
nhos, planos, elevações acústica, iluminação e venti-
tura Clássica
e perspectivas lação
Modelos para dife- Desempenho, confia-

Arquite-
rentes papéis, múltiplas bilidade, escalonamento e
tura de Software
visões manutenibilidade
Hoje em dia, os processos de engenharia de software requerem o projeto

arquitetural de software. Por quê?
 É importante poder reconhecer as estruturas comuns exis-

tentes de modo que arquitetos de software (ou engenheiros de software
realizando o papel de arquiteto de softwares) possam entender as rela-
ções existentes nos sistemas em uso e utilizar esse conhecimento no
desenvolvimento de novos sistemas.
 O entendimento das arquiteturas permite aos engenheiros
tomarem decisões sobre alternativas de projeto.
 Uma especificação arquitetural é essencial para analisar e
descrever propriedades de um sistema complexo, permitindo o enge-
nheiro ter uma visão geral completa do sistema.
 O conhecimento de notações para descrever arquiteturas
permite engenheiros comunicarem novos projetos e decisões arquitetu-
rais tomadas a outros membros da equipe.
Cabe destacar que, para que haja o entendimento da arquitetura, faz-se

necessário ao engenheiro de software conhecer os estilos arquiteturais existen-
tes, conforme apresentado adiante. As propriedades de cada arquitetura, por-
tanto, são dependentes do estilo arquitetural adotado. Por exemplo, o uso de
uma notação padrão como a UML ajuda na representação de componentes e
compartilhamento de informações do projeto.
9
Esses aspectos servem como indicadores de uma maturidade inicial de
engenharia de software. Outros aspectos compreendem uso e reuso de soluções
existentes no desenvolvimento de novos sistemas. Para tanto, a prototipagem
tem sido usada em projetos de natureza inovadora (bem antes da implementa-
ção ou aceitação de um produto acontecer).
Além disso, o aumento da complexidade e quantidade de requisitos dos

sistemas dificulta cada vez mais atender às restrições de orçamento e crono-
grama. Atualmente, empresas têm procurado incorporar estratégia de reuso de
software, enfatizando o reuso centrado na arquitetura para obter melhores resul-
tados no desenvolvimento de sistemas. Note que a arquitetura de software serve
como uma estrutura através da qual se tem o entendimento dos componentes
de um sistema e de seus inter-relacionamentos. Em outras palavras, ela define
a estrutura do sistema, de modo consistente para implementações, já que está
diretamente relacionada aos atributos de qualidade como confiabilidade e de-
sempenho.
A organização dos componentes num sistema de software impacta sobre

a qualidade apresentada por ele. Por exemplo, a adoção de uma arquitetura em
camadas serve para modularizar o sistema bem como facilitar modificações. En-
tretanto, um número elevado de camadas (4 ou 5) podem degradar o desempe-
nho do sistema se houver um elevado grau de acoplamento entre os componen-
tes.
Diversos benefícios decorrem da incorporação da arquitetura de sof-

tware como ‘elemento norteador’ do processo de desenvolvimento de software.
Cabe destacar que a arquitetura pode:
 Prover suporte ao reuso – seus componentes definidos e

testados podem ser reaproveitados em novas aplicações.
10
 Servir de base à estimação de custos e gerência do projeto
– a existência de uma arquitetura bem definida permite ao gerente de
projeto adequadamente alocar tarefas de, por exemplo, implementação
de componentes e melhor estimar o tempo e tamanho de equipe neces-
sária para realização de um projeto.
 Servir de base para análise da consistência e dependência

– o arquiteto de software pode verificar se a arquitetura de software ado-
tada suporta os atributos de qualidade desejados de modo consistente e
avaliar o nível de dependência dos atributos de qualidade em relação à
arquitetura. Para tanto, ele faz a análise arquitetural que verifica o su-
porte oferecido pela arquitetura a um conjunto de atributos de qualidade
(como desempenho, portabilidade e confiabilidade).
 Ser utilizada para determinar atributos de qualidade do sis-

tema – o arquiteto de software faz a análise arquitetural a fim de deter-
minar os atributos de qualidade. Trata-se de um processo iterativo.
 Atuar como uma estrutura para atender os requisitos do

sistema – a arquitetura ajuda a definir os requisitos funcionais, que com-
preendem o conjunto de funcionalidades do sistema de software, e re-
quisitos não funcionais (ou atributos de qualidade) que determinam as
características visíveis ao usuário como desempenho e confiabilidade.
11
SEGURANÇA É UM PROCESSO
(Fonte: http://menezeseassociados.com.br/gerenciamento-de-seguranca-de-processo/ )
Problemas de segurança têm origem na maldade, inocência, estupidez ou

infortúnio humano. As medidas para tornar sistemas mais seguros incluem me-
canismos para coibição de ações maliciosas, prevenção de uso inadequado ou
descuidado e, finalmente, planos de contingência.
Segurança não “acontece”, tampouco é “ligada” em sistemas. Na prática,

ela é garantida por projeto cuidadoso, implantação precisa, manutenção discipli-
nada e operação monitorada.
Segurança é um processo. (Bruce Schneier)
Sistemas desenvolvidos e mantidos com processos que não dão ênfase

para a segurança têm alta probabilidade de serem “vitimados” direta ou indireta-
mente.
12
Segurança bem implementada desencoraja e coíbe condutas maliciosas,
previne enganos e protege contra infortúnios (afinal, acidentes acontecem). Por
isso, diminui desperdícios de tempo e dinheiro, protegendo a privacidade das
pessoas e a reputação das marcas.
Os custos relacionados com segurança têm relação com a prevenção de

perdas e não com a geração de ganhos. Por isso, embora necessários são sem-
pre questionados. Segurança é um atributo “invisível”, ou seja, só percebido
quando há problemas.
Importante destacar que o Brasil, hoje, é segundo colocado mundial na

relação de países com maior volume de ataques cibernéticos identificados. Logo,
os riscos associados a operações tecnológicas em nosso país são inerente-
mente mais altos.
Cabe aos arquitetos a responsabilidade de evidenciar os benefícios de

priorizar a segurança. Para isso, é útil estimar os custos possíveis na ocorrência
“eventos ruins”.
13
QUAL É O PROCESSO DE DESENVOLVIMENTO DE UM
SOFTWARE SEGURO?
Durante o desenvolvimento de um software, os gerentes de TI buscam

garantir a entrega de um produto com uma baixa quantidade de bugs no menor
tempo possível. No entanto, durante esse processo, não são raros os casos em
que gestores ignoram práticas de segurança que evitam, no futuro, vazamento
de dados sigilosos. Diante desse cenário, é fundamental que certas rotinas se-
jam tomadas, ainda que os modelos de criação de software mais tradicionais não
sejam focados no desenvolvimento de software seguro.
Peguemos como exemplo o Modelo em Cascata (ou Waterfall Mode, em

inglês). Por ser um dos primeiros modelos a serem criados, foi altamente ado-
tado, ainda que possuísse falhas. Suas etapas são:
 verificação dos requerimentos de software e sistema;
 analise e criação da estrutura do software
 desenvolvimento do código do programa;
 teste, depuração e busca por erros;
 instalação, suporte e manutenção de todos os sistemas in-

terligados ao software.
Ainda que algumas versões modificadas do modelo tenham sido criadas,

a original peca pela falta de uma etapa em que são implementadas políticas e
rotinas de segurança de software. Já modelos como o espiral são focados na
capacidade da equipe para desenvolver um programa com um bom aproveita-
mento do tempo e do esforço de todos os profissionais envolvidos. Dessa forma,
é possível eliminar rapidamente elementos que podem atrasar a criação do sis-
tema ou diminuir a produtividade do time de desenvolvedores.
14
BOAS PRÁTICAS DE SEGURANÇA DE SOFTWARE
A adoção de um modelo de desenvolvimento tradicional não deve ser

visto como um motivo para a não implementação de rotinas de segurança. Ao
buscar práticas que permitam o desenvolvimento de um software estável e com
poucas falhas, o gerente de TI faz com que o seu sistema seja lançado sem
falhas graves de segurança. Isso diminui a possibilidade dos dados de segu-
rança do usuário e da sua empresa ficarem vulneráveis.
Em um mundo onde pessoas mal-intencionadas trabalham buscando por

brechas que permitam a obtenção de dados pessoais e corporativos, o cuidado
com a segurança deve passar por todas as etapas de criação de um software e
ser incorporado no cotidiano dos profissionais de TI. Veja abaixo alguns exem-
plos de como tornar o seu sistema mais seguro:
 Na etapa de classificação de requisitos e formação da

equipe de desenvolvimento, é necessário identificar a necessidade de uti-
lização de métodos de criptografia, segurança de usuários, treinamento
e, em alguns casos, questões legais envolvendo licenciamento e manipu-
lação de dados;
 Quando a arquitetura do software for projetada, é necessá-

rio levar em conta o nível de segurança da arquitetura e da linguagem
escolhida, as possíveis vulnerabilidades que o sistema pode apresentar e
quando e como os métodos de autenticação e envio de dados seguro se-
rão utilizados;
 Procure oferecer uma documentação com todos os requeri-

mentos de segurança listados para a sua equipe. Além disso, garanta que
o seu time trabalhe de acordo com as definições de segurança do projeto,
usando as ferramentas da arquitetura e buscando vulnerabilidades da ma-
neira correta;
15
 Antes de lançar o seu sistema para o público geral, faça tes-
tes nos seus métodos de segurança e tente pensar como alguém que
deseja comprometer a segurança do sistema. Nessa etapa, é importante
garantir que todos os blocos de código que envolvem informações sensí-
veis não tenham brechas que possam comprometer a segurança do usu-
ário;
 Por fim, quando o produto for finalmente adotado pelo mer-

cado, continue fazendo monitoramento em busca de falhas de segurança.
Permita (e incentive) que o seu usuário envie logs com dados de uso e
falhas de software. E caso alguma brecha seja encontrada, trabalhe com
o seu time para que um patch de segurança seja lançado o mais rápido
possível.
16
A DIFERENÇA DE UM SOFTWARE SEGURO E INSEGURO
A diferença entre um software seguro e inseguro é sutil, onde na maioria

das vezes escutamos dos fornecedores que seus sistemas são "seguros".
Quase todos os sistemas controlados por software enfrentam ameaças, enge-
nheiros de software devem estar cientes dessas ameaças e projetar sistemas
com defesas confiáveis enquanto entregam valor aos clientes. Recentemente a
Open Web Application Security Project (OWASP) publicou uma lista indispensá-
vel dos Principais riscos de segurança de aplicação Top 10 2017/2018.
(Fonte: https://blog.convisoappsec.com/orientacao-sobre-a-compra-de-um-software-seguro/ )
17
ESTILO ARQUITETURAL
O estilo arquitetural serve para caracterizar a arquitetura de software de

um sistema, possibilitando a:
 Identificação de componentes – o arquiteto identifica quais

os principais elementos que tem funcionalidades bem definidas como, um
componente de cadastro de (informações de) usuários e um componente
de autenticação de usuário numa aplicação Web.
 Identificação de mecanismos de interação – a comunicação

entre objetos por meio da troca de mensagens constitui uma forma atra-
vés da qual os componentes de software interagem entre si.
 Identificação de propriedades – o arquiteto pode analisar as

propriedades oferecidas por cada estilo baseado na organização dos
componentes e nos mecanismos de interação, conforme discutido abaixo.
O estilo arquitetural considera o sistema por completo, permitindo o en-

genheiro ou arquiteto de software determinar como o sistema está organizado,
caracterizando os componentes e suas interações. Em outras palavras, ele de-
termina uma estrutura para todos os componentes do sistema. O estilo arquite-
tural compreende o vocabulário de componentes e conectores, além da topolo-
gia empregada. Mas, você pode estar se questionando: Por que saber o estilo
arquitetural é importante?
Os sistemas de grande porte exigem níveis de abstração mais elevados

(justamente onde se têm os estilos) que servem de apoio à compreensão do
projeto e comunicação entre os participantes do projeto. Ele é determinante no
entendimento da organização de um sistema de software.
18
Mas, o que se ganha em saber o estilo arquitetural? Ele oferece:
 Suporte a atributos de qualidade (ou requisitos não funcio-

nais);
 Diferenciação entre arquiteturas;
 Menos esforço para entender um projeto;
 Reuso de arquitetura e conhecimento em novos projetos.
Conhecer o estilo arquitetural permite ao engenheiro antecipar, por meio

da análise (arquitetural), o impacto que o estilo (isto é a classe de organização
do sistema) terá sobre atributos de qualidade. Adicionalmente, facilita a comuni-
cação do projeto, além do reuso da arquitetura (da solução).
A caracterização e existência de estilos arquiteturais constituem sinais de

amadurecimento da engenharia de software, uma vez que permite ao enge-
nheiro organizar e expressar o conhecimento de um projeto de modo sistemático
e útil.
Note que uma forma de codificar conhecimento é dispor de um vocabulá-

rio de um conjunto de conceitos (terminologia, propriedades, restrições), estru-
turas (componentes e conectores) e padrões de uso existentes. Conectores são
empregados na interação entre componentes como, tubo (pipe) no estilo tubos
e filtros, e mensagens no estilo de objetos.
19
A IMPORTÂNCIA DO REÚSO
É importante perceber de tudo o que foi apresentado e discutido que um

modelo arquitetural oferece suporte ao reuso de várias formas. Por exemplo,
pode se ter arquiteturas reusáveis que forneçam a organização e o modelo de
coordenação, permitindo seu uso em diversos sistemas. Além disso, podem-se
reutilizar componentes, já testados, em mais de um sistema. Disso tudo, o mais
importante é o reuso do conhecimento que tem impacto direto na definição da
arquitetura de software candidata à solução de um problema (ou sistema).
A ampla variedade de plataformas e utilitários, juntamente com a pressão

do mercado para reduzir o tempo de entrega de produtos de software e elevar a
produtividade, faz com que o reuso seja apontado como uma das chaves de
sucesso para empresas.
O reuso de artefatos (ou componentes) é possível quando o projeto arqui-

tetural está incorporado e orienta o processo de desenvolvimento de software.
Isto, como discutido, permite antever os atributos de qualidade que o sistema
suporta e também administrar o cronograma de execução do projeto. Portanto,
impactando positivamente o reuso e economia do sistema.
O quadro apresentado na Tabela 2 sumariza as principais características

da arquitetura de software e pontos importantes na capacitação e reciclagem de
engenheiros e arquitetos de software.
20
Tabela 2. Características e uso prático da arquitetura de software.
Características de arquitetura Uso prático da arquite-

de software tura de software
Como um arquiteto de sof-

Constitui um artefato reutilizável tware pode organizar o projeto e
código de um sistema
Como um arquiteto avalia

Dispõe de mecanismos de inter-
e implanta arquiteturas de sof-
conexão
tware em sistemas
Como um arquiteto de sof-

Oferece um vocabulário de pro-
tware atua no processo de desen-
jeto e separa funcionalidades
volvimento de software
Como um arquiteto avalia

Vincula o projeto a atributos de
a qualidade do código baseada
qualidade
em métricas de produto
21
Suporta o desenvolvimento ba- Como usar arquitetura
seado em componentes e linha de pro- como parâmetro para reduzir cus-
duto (quando os requisitos são consi- tos de manutenção e amortizar
derados para uma família de sistemas) custos de desenvolvimento
22
Com a dinamização dos modelos tecnológicos e de gestão, empresas de

desenvolvimento e consultoria de software passaram a ter um papel protagonista
na busca por falhas de sistema. Se antes isso era conquistado por hackers que
buscavam vulnerabilidades para obtenção de senhas e outros dados privados,
hoje as desenvolvedoras trabalham na busca por brechas diversas. Para que
essa nova postura ganhasse força, requisitos regulatórios foram criados bus-
cando responsabilizar os criadores e não os usuários pelos problemas causados
por um software não seguro. Não tenha medo de adaptar as rotinas e protocolos
existentes a sua necessidade.
Na era da internet das coisas, a tecnologia tornará a nossa vida melhor

dentro e fora do ambiente de trabalho. Nesse cenário em que softwares serão
responsáveis pela manipulação de um número cada vez maior de informações,
garantir que esses dados estejam seguros é fundamental para as empresas e
para os seus usuários. Ao adotar boas práticas que levam ao desenvolvimento
de software seguro, o gerente de TI foca os seus recursos na criação e manu-
tenção de um sistema benéfico para a sua empresa e para todos os que dela
dependem. Ainda que os desafios estejam cada vez maiores, um sistema que
deixe a organização menos vulnerável a ataques criminosos gera menos gastos
com contenção e resolução de problemas.
Embora arquitetura de software seja um tema relevante no contexto atual

para desenvolvimento de sistemas de software que têm seu foco no reuso e,
portanto, consideram tanto o aspecto econômico quanto a produtividade, sua
incorporação nos processos de desenvolvimento de software tem sido obser-
vada apenas em empresas de grande porte e em poucas de médio porte.
Entretanto, esse cenário começa a mudar dada a crescente necessidade

de integração de sistemas a qual tem a arquitetura de software como premissa.
Assim, o fator econômico tem sido e será o determinante da sobrevivência da
23
empresas de software. Novas estratégias de desenvolvimento de sistemas de-
vem ser para o reuso e com reuso (de componentes de software) e o pilar prin-
cipal dessas estratégias é a arquitetura de software. Há, portanto, uma necessi-
dade premente de formação de capital humano com tais qualificações.
Uma questão que você deve estar se fazendo é: Por que apenas recen-
temente houve o foco na arquitetura de software?
A resposta é simples: economia e reuso.
Anteriormente não havia forte ênfase na disciplina de engenharia de sof-

tware, fato este ocorreu com o amadurecimento desta nova área ao longo de
toda a década de 1990. Tudo motivou o surgimento de um novo profissional: o
arquiteto de software.
24
REFERÊNCIAS
APOLINÁRIO, Sérgio. Segurança da informação e a arquitetura de

software na era digital. 2018.
BIRD, Jim, O que é importante no design de software seguro? 2013.
FILHO, Antônio. Arquitetura de Software: Desenvolvimento orientado

para arquitetura M S. 2008.
GRID, Admin. Quais são os padrões de arquitetura de software? 2020.
JÚNIOR, Elemar. Fundamentos para a arquitetura de sistemas segu-

ros. Capítulo 10 v1. 2021.
25
ARQUITETURA DE SOFTWARE NA PLATAFORMA NODE.JS
1
NOSSA HISTÓRIA



2
Sumário
INTRODUÇÃO ........................................................................................ 4
O QUE É O NODE.JS ............................................................................. 5
O SURGIMENTO DO NODE.JS .............................................................. 7
CARACTERÍSTICAS DO NODE.JS ........................................................ 8
VANTAGENS DO USO DO NODE.JS................................................... 12
PRINCÍPIOS .......................................................................................... 14
ESTRUTURA E PERFORMANCE......................................................... 16
ESCALABILIDADE ................................................................................ 17
ESTENSIBILIDADE E PACOTES ......................................................... 18
ARQUITETURA LIMPA ......................................................................... 19
EXPRESS.............................................................................................. 21
A IMENSIDÃO DO NODE.JS ................................................................ 22
CASOS DE USO MAIS COMUNS ......................................................... 23
REFERÊNCIAS ..................................................................................... 26
3
INTRODUÇÃO
É natural que o ambiente mais propício para o desenvolvimento de siste-

mas nesse novo paradigma, por sua natureza distribuída, seja a Internet. Dado
que a linguagem mais utilizada hoje na Web é o JavaScript, implementado na
maioria dos navegadores atuais, se deu a escolha dessa linguagem para o pro-
jeto.
Estando o JavaScript em franca expansão também no server side, com a

implementação do Node.js , usado hoje por grandes organizações em suas so-
luções Web, essa também foi a linguagem utilizada no lado servidor do projeto.
Com o uso da mesma linguagem em todo o projeto, o mesmo ganhou

coesão e houve redução na tradicional lacuna que separa os desenvolvimentos
front end e back end. A importância da integração de sistemas em rede trouxe à
tona a necessidade de uma arquitetura que defina como esses sistemas devem
interagir entre si e como devem definir suas interfaces. Um dos estilos arquitetu-
rais que se propõe a resolver essa questão é o REST (Transferência de Estado
Representacional).
4
O QUE É O NODE.JS
O Node.JS é uma plataforma leve para você construir aplicações servido-

ras em linguagem Javascript e pode ser comparado, em um primeiro momento
de análise, a tecnologias como o Java EE Web ou ASP.NET. Ao mesmo
tempo, Node.JS é uma tecnologia minimalista. Ele é muito leve e não traz con-
sigo servidores Web ou servidores de aplicação pesados, como o Java EE Web
ou o ASP.NET. No Node.JS, você começa leve e coloca novos módulos apenas
quando necessário.
O JavaScript no lado do servidor pode ser um conceito novo para todos

que trabalharam exclusivamente com o JavaScript no lado do cliente, mas a ideia
em sí não é tão absurda porque não usar a mesma linguagem de programação
no cliente que você usa no servidor?
Em nível detalhado, o Node.js é uma plataforma construída sobre o motor

JavaScript do Google Chrome para construir aplicações de Internet rápidas e
com excelente escalabilidade. O motor JavaScript V8 é o motor que a Google
usa com seu navegador Chrome. A engine JavaScript do Chrome realmente
interpreta o código JavaScript e o executa. Com o V8 a Google criou um inter-
pretador ultrarrápido escrito em C++.
O Node.js usa um modelo de I/O direcionada a eventos assíncronos que

o torna leve e eficiente, ideal para aplicações em tempo quase real com troca
intensa de dados através de dispositivos distribuídos. Em termos arquiteturais, o
Node é um servidor de programas e roda sobre um pequeno motor JavaScript.
Mas javascript não é só no Browser? Não mais. Node é feito sobre e en-
gine da Google chamada V8 que roda no Chrome, o V8 interpreta o código ja-
vascript e dessa forma é processado no lado do servidor.
5
Não podemos dizer que node é um Framework nem um Middleware nem
uma Linguagem, na verdade trata-se de um runtime Javascript. Com o cresci-
mento exponencial de bibliotecas, recursos e da comunidade, podemos dizer
que node tornou-se uma plataforma.
As aplicações Node.js são projetadas visando maximizar o troughput e a

eficiência, usando operações de entrada e saída não bloqueantes, e eventos
assíncronos. As aplicações Node.js rodam, cada uma, em apenas uma thread.
O Node.js usa, internamente, a engine Google V8 JavaScript para executar o
código e uma grande parte de seus módulos é escrito em JavaScript. Node.js
contém, nativamente, uma biblioteca HTTP de lado servidor, tornando possível
rodar um servidor web sem outra ferramenta, como por exempo o Apache ou
Nginx.
Devido às características citadas acima, o Node.js se adapta perfeita-

mente para o uso em aplicações de tempo real como uso intensivo de dados e
que rodem em dispositivos distribuídos. Com um vasto ecossistema de bibliote-
cas, larga comunidade open-source, alta performance e facilidade de deploy,
Node.js é uma excelente alternativa para a criação de servidores para aplicativos
Web, trazendo, ainda, a vantagem de se poder utilizar a mesma linguagem no
server side e no front end.
6
O SURGIMENTO DO NODE.JS
Apesar do Javascript ter mais de 20 anos, o seu uso server-side é bem

recente.
A linguagem Javascript foi criada em 1995, e se tornou a linguagem pa-
drão dos browsers e consequentemente da Web para o desenvolvimento client-
side.
Desde então, houveram diversas tentativas de implementar sua execu-
ção server-side. Todas elas fracassaram, devido à sua performance ser extre-
mamente baixa comparado com as linguagens existentes no mercado, como o
PHP ou Java.
Porém, com a rápida evolução da Web nos últimos anos, a linguagem Ja-
vascript e seus motores de execução passaram por diversas melhorias, tornando
viável sua execução com outros propósitos além da manipulação de páginas
HTML.
Com essa nova fase no uso do Javascript, aplicações server-side passa-
ram a ser implementadas, e em 2009 foi criado o primeiro ambiente de execução
Javascript com este propósito: O Node.js.
7
CARACTERÍSTICAS DO NODE.JS
A principal característica que diferencia o Node.JS de outras tecnologias,

como PHP, Java, C#, é o fato de sua execução ser single-thread. Ou seja, ape-
nas uma thread é responsável por executar o código Javascript da aplicação,
enquanto que nas outras linguagens a execução é multi-thread.
Mas o que isso significa na prática?

Em um servidor web utilizando linguagens tradicionais, para cada requisi-
ção recebida é criada uma nova thread para tratá-la. A cada requisição, serão
demandados recursos computacionais (memória RAM, por exemplo) para a cri-
ação dessa nova thread. Uma vez que esses recursos são limitados, as thre-
ads não serão criadas infinitamente, e quando esse limite for atingido, as novas
requisições terão que esperar a liberação desses recursos alocados para serem
tratadas.
A figura abaixo representa esse cenário em um servidor tradicional:
(Fonte: https://www.opus-software.com.br/node-js/ )
8
No modelo Node.js, apenas uma thread é responsável por tratar as requi-
sições.
Essa thread é chamada de Event Loop, e leva esse nome pois cada re-
quisição é tratada como um evento. O Event Loop fica em execução esperando
novos eventos para tratar, e para cada requisição, um novo evento é criado.
Apesar de ser single-threaded, é possível tratar requisições concorrentes

em um servidor Node.js. Enquanto o servidor tradicional utiliza o sistema multi-
thread para tratar requisições concorrentes, o Node.js consegue o mesmo efeito
através de chamadas de E/S (entrada e saída) não-bloqueantes.
Isso significa que as operações de entrada e saída (ex: acesso a banco

de dados e leitura de arquivos do sistema) são assíncronas e não bloqueiam
a thread. Diferentemente dos servidores tradicionais, a thread não fica espe-
rando que essas operações sejam concluídas para continuar sua execução.
9
A figura abaixo representa a diferença de funcionamento de um servidor
web tradicional e um Node.JS:
(Fonte: https://www.opus-software.com.br/node-js/ )
10
No servidor Node.js, o Event Loop é a única thread que trata as requisi-
ções, enquanto que no modelo tradicional uma nova thread é criada para cada
requisição. Enquanto o Event Loop delega uma operação de E/S para
uma thread do sistema de forma assíncrona e continua tratando as outras requi-
sições que aparecerem em sua pilha de eventos, as threads do modelo tradicio-
nal esperam a conclusão das operações de E/S, consumindo recursos compu-
tacionais durante todo esse período de espera.
Apesar do Node.js ser single-threaded, sua arquitetura possibilita um nú-

mero maior de requisições concorrentes sejam tratadas em comparação com o
modelo tradicional, que é limitado devido ao alto consumo computacional pela
criação e manutenção de threads a cada requisição.
11
VANTAGENS DO USO DO NODE.JS
Flexibilidade
O NPM (Node Package Manager) é o gerenciador de pacotes do Node.js

e também é o maior repositório de softwares do mundo. Isso faz do Node.js uma
plataforma com potencial para ser utilizada em qualquer situação. O pacote mais
conhecido se chama Express.js e é um framework completo para desenvolvi-
mento de aplicações Web.
Leveza
Criar um ambiente Node.js e subir uma aplicação é uma tarefa que não
exige muitos recursos computacionais em comparação com outras tecnologias
mais tradicionais. Se utilizado em conjunto com ferramentas como o Docker, o
ganho na velocidade de deploy e replicação de máquinas pode ser muito signi-
ficativo e em ambientes escaláveis isso significa menos custo e mais eficiência.
Tanto sua leveza quanto flexibilidade fazem do Node.JS uma tecnologia

indicada para a implementação de serviços e componentes de arquiteturas como
a de microsserviços e serverless. Além disso, conta com suporte das principais
empresas de produtos e serviços Cloud do mercado, como a AWS, Google Cloud
e Microsoft Azure que oferecem na maioria de seus produtos suporte nativo ao
Node.JS.
Produtividade da equipe
Maior repositório do mundo: O NPM fornece pacotes de código reusáveis

e provavelmente aquela integração que você precisa fazer com outro sistema ou
banco de dados já está implementado e disponível gratuitamente para instalar
via NPM.
12
Mesma linguagem no frontend e backend: Javascript é a linguagem
padrão para desenvolvimento web client-side. Empresas de desenvolvimento
Web contam como esse know-how como um ponto de partida importante para
iniciar o uso do Node.js. Além disso, esse fator pode representar ganhos de reu-
tilização de código e criação de equipes multidisciplinares, com melhor aprovei-
tamento de recursos.
Ambiente de inovação: Possibilidade de deploys e iterações mais rápi-

das, e resolução de problemas On the Fly. Isso também permite a criação de
soluções próprias e inovadoras, como fez o Uber criando produtos em Node.js
para resolver alguns de seus problemas.
13
PRINCÍPIOS
Acima de qualquer estrutura que eu possa propor aqui, vale ressaltar al-
guns princípios e motivações que devem estar acima de quaisquer convenções
em seu código:
Ajude seu cérebro a entender o projeto: Conseguimos lidar com ape-

nas pequenas quantidades de informação de cada vez. Por isso que usamos
pastas. Por isso que criamos funções. Elas nos ajudam a lidar com a complexi-
dade do sistema nos permitindo mexer em pequenas porções dele de cada vez.
Crie apenas os diretórios que precisa: Não saia criando dezenas de

diretórios que acabarão vazios ou com apenas um arquivo dentro. Comece com
o básico de pastas que você precisa e vá adicionando conforme a complexidade
for aumentando. Afinal, você não compra um ônibus como primeiro veículo pen-
sando no dia em que pode querer dar carona para muita gente, certo?
Torne fácil localizar arquivos de código: Os nomes de pasta devem

ser significativos, óbvios e fáceis de entender. Código que não é mais usado,
bem como arquivos antigos, devem ser removidos do projeto, e não apenas co-
mentados ou renomeados. Além disso, todos os códigos ficam dentro de um
diretório app na raiz e seus subdiretórios, para facilitar buscas posteriores, es-
pecialmente via linha de comando. Ah, e o padrão do npm é usar nomes sempre
em minúsculo para as pastas, sem acentos, e com os espaços substituídos por
hífens (-). Então é melhor seguir esta regra, por mais que não goste dela.
Agrupe por feature, não por responsabilidade: Esta é uma sugestão

que vai contra o que a maioria de nós está acostumado, de separar os arquivos
por responsabilidade (controller, model, etc). Cada feature da sua aplicação
node possui uma série de arquivos que, se estiverem juntos (em uma pasta por
feature), fica mais fácil de dar manutenção depois. Ex: preciso adicionar um novo
campo em um model, na mesma pasta eu já posso mexer no controller que usa
aquele model.
14
Guarde seus testes perto do seu código: Essa ideia vai de encontro à
anterior. Coloque o arquivo JS de testes de cada feature na mesma pasta da
feature, para facilitar os testes e correção dos bugs encontrados. Também ajuda
a lembrar das features que ainda não possuem testes codificados.
Para não se perder com os nomes de arquivos a sugestão é usar uma

convenção de nome baseada em sufixo, por exemplo:
o arquivo JS original é foo.js

o arquivo de teste do original é foo.test.js
Diminua o acoplamento e aumente o reuso de software: A ideia com

essas duas últimas dicas é tornar sua aplicação mais modular, com cada feature
sendo um módulo mais independente. Aqui a ideia permanece. Uma vez que
você tenha módulos independentes, sua aplicação fica menos acoplada e a ma-
nutenção mais simples. Uma dica para aumentar o reuso de software mantendo
o acoplamento baixo é não colocar código “especializado” nas suas chamadas
de model e controller. Ex: após salvar um cliente no banco você precisa enviar
um e-mail pra ele. Não coloque o código que envia e-mail logo após o salva-
mento no banco. Ao invés disso, dispare uma função de um módulo de e-mail.
Priorize configuration over convention: Não faça coisas mágicas como

assumir que o nome de um arquivo é x ou que os uploads vão parar sempre em
uma pasta y. Isso é frágil e facilmente quebra sua aplicação quando alguma
coisa muda e você não lembra de todas as convenções que criou para sua ar-
quitetura. Programe de maneira que o código em si possa fazer com que o pro-
gramador entenda todo o projeto.
Convencione nomes de arquivos no formato ‘lower-kebab-

case’: Use apenas minúsculas e ‘-‘como separador entre palavras. Isso evita
problemas de sistemas de arquivos em SOs diferentes que sua aplicação Node
possa rodar. Ex: cadastro-cliente.js
15
ESTRUTURA E PERFORMANCE
Mais popular a cada dia no mundo do software, sua arquitetura single

thread (Thread Única) com um sistema não bloqueante permite atingir um nú-
mero absurdo de requisições por segundo com pouco recurso computacional.
De forma simples, isso se dá porque Node.js usa um loop de eventos de

i/o (input/output) para processar requisições de forma intermitente, assim que
um evento é finalizado o mesmo dispara um callback (função de retorno), assim
o evento é posto novamente na fila e praticamente elimina-se a ociosidade no
processamento.
Em plataformas mais convencionais usa-se threads, porém enquanto

elas aguardam uma resposta do evento poderiam estar fazendo outras tarefas,
mas ela fica lá “matando tempo” e bloqueando outros eventos que estão na fila,
além de exigir um controle por parte do Sistema Operacional para que todas
as threads sejam gerenciadas. Isso requer mais recurso computacional e resulta
em perda de performance.
16
ESCALABILIDADE
Node.js foi pensado para ser altamente escalável horizontalmente, por

exemplo: Ao invés de investir em discos SSD, Memória ROM, RAM, você pode
simplesmente virtualizar a sua máquina e/ou adicionar mais máquinas no mesmo
ponto físico ou não, tornando assim sua escalabilidade muito mais simples e
barata e eficaz.
(Fonte: https://www.linkedin.com/pulse/uma-arquitetura-para-web-com-nodejs-graphql-
postgres-matheus )
Repare na imagem acima, na escala vertical os recursos aumentam de

tamanho, ou seja, aumenta-se espaço em disco, memória, etc. Na escala hori-
zontal você multiplica os recursos.
17
ESTENSIBILIDADE E PACOTES
Se você for se aventurar e programar de forma nativa no Node.js, vai ver

que as coisas não são assim tão simples como você provavelmente viu em al-
gum código na internet, porém, quando instalamos o Node.js temos a disposição
o “npm” (Node Package Manager / Gerenciador de Pacotes do Node), com ele
você tem acesso a milhares de packages que podem ser adicionados a sua apli-
cação. Todos os pacotes estão disponíveis em que é o repositório oficial de pa-
cotes Node. Isso abstrai muito da complexidade do desenvolvimento em Node.
É preciso ter um pouco de cuidado ao utilizar esses pacotes, é importante

conferir quantas pessoas já o utilizam, número de comentários e as informações
disponíveis sobre o pacote no Github como commits, pull requests, contribuintes,
etc. Isso porque qualquer um pode desenvolver e publicar um pacote Node.
18
ARQUITETURA LIMPA
Arquitetura Limpa, do termo inglês Clean Architecture, é um padrão ar-

quitetural usado na engenharia de software. Esse padrão foi conceituado por
Robert Martin, mais conhecido como Uncle Bob, um engenheiro de software fa-
moso e um dos autores do Manifesto Ágil (link), além de diversos livros na área.
O conceito foi apresentado no artigo em seu blog em 2012 (link) e foi baseado
em uma arquitetura já conhecida, a Arquitetura Hexagonal (link), conceituada
em 2005. Mais tarde, em 2017, ele aprofundou-se no tema em seu livro: Arqui-
tetura Limpa: O guia do artesão para estrutura e design de software (link).
A ideia dessa arquitetura é criar componentes fracamente acoplados que

possam ser conectados através de portas e adaptadores, o que permite o isola-
mento das regras de negócio da aplicação (ex: entidades, casos de uso) de pre-
ocupações externas (ex: frameworks, banco de dados). A lógica de negócios não
deve depender de GraphQL ou REST por exemplo, ou se os dados estão sendo
obtidos por um banco de dados ou um arquivo CSV simples. Essa separação
tem, dentre outros benefícios, auxiliar na mudança de componentes e facilitar
testes automatizados.
A Arquitetura Limpa casa muito bem com o DDD (Domain-Driven De-

sign) (link). Irei utilizar a notação usada pelo DDD para definir as camadas da
aplicação, que são: Domínio, Aplicação, Interfaces e Infraestrutura. Cada uma
dessas camadas é definidas da seguinte maneira:
Domínio: A camada de domínio é o coração do software, reunindo as

regras cruciais de negócios da empresa inteira. É o local onde as entidades e
objetos de valor viverão. De acordo com Uncle Bob: “Uma entidade pode ser um
objeto com métodos ou um conjunto de estruturas de dados e funções. Isso não
importa, contanto que as entidades possam ser usadas por muitas aplicações
diferentes na empresa.”.
Aplicação: Essa camada contém as regras de negócio específicas da
aplicação. Na Arquitetura Limpa, Uncle Bob descreve os casos de uso como
19
sendo as principais funcionalidades da aplicação. Esses casos de uso utilizam
as entidades a fim de atingir seus objetivos, criando assim uma dependência
nelas.
Interfaces: Aqui estão os adaptadores. Adaptadores são criados para

isolar as entidades e casos de uso das ferramentas utilizadas na aplicação (fra-
meworks e drivers), convertendo os dados para o formato que mais convém às
camadas mais externas. Esses adaptadores, de acordo com Uncle Bob, devem
funcionar pelo conceito de Interfaces de programação orientada a objetos nos
casos de uso, como apresentado no diagrama do canto inferior da imagem
acima. Como em Javascript não existem interfaces, isso pode ser feito através
de injeção de dependência, que será explicado melhor nas seções seguintes.
Infraestrutura: A infraestrutura consiste em tudo o que existe indepen-

dentemente da aplicação: bibliotecas externas, mecanismo de banco de dados,
servidor de aplicação, filas de mensagens e assim por diante.
20
EXPRESS
Express é um framework para desenvolvimento de aplicações Web, mini-

malista e flexível, que roda sobre a plataforma Node.js (Express - web application
framework for node, 2014).
Provendo um conjunto robusto de funcionalidades para a construção de

aplicações Web, sejam elas Spa (Single-page Applications), aplicações com
múltiplas páginas, ou aplicações híbridas. Com diversos métodos utilitários
HTTP e de middleware disponíveis, o Express torna fácil a criação de Web APIs
amigáveis de forma rápida e robusta.
O Express provê uma pequena camada de funcionalidades fundamentais

para aplicações Web, porém, sem obscurecer as funcionalidades já disponíveis
no Node.js.
Quando trabalhamos com uma plataforma nova como o Node.js, é muito

comum ficarmos em dúvida de como proceder com a escala de nossas aplica-
ções e principalmente com a arquitetura da mesma, conforme vão crescendo.
Além disso, considerando os fundamentos do Node.js, o fato de trabalhar

com Javascript e sua inerente dinamicidade e pouco apreço por tipagem, orien-
tação à objetos e muito mais, torna a transição de programadores mais tradicio-
nais (Java, C#, etc) para esta plataforma um tanto confusa.
21
A IMENSIDÃO DO NODE.JS
Aplicações web não são sempre a mesma coisa e, da mesma forma, não
há uma única arquitetura e/ou estrutura de código que possa ser aplicada à todas
aplicações express.js.
Sim, é possível criar grandes aplicações em Node.js uma vez que gran-
des empresas estão fazendo exatamente isso nos últimos anos, como Walmart,
Netflix e Uber, só para citar algumas. A questão aqui é: sua aplicação realmente
é grande e precisa de uma arquitetura como a deles?
Se sua aplicação é pequena, você não precisa de uma estrutura complexa

de diretórios. Mantenha sua aplicação simples, garanta que os arquivos mais
importantes estarão na raiz do diretório e está feito.
Agora, se sua aplicação é gigantesca, em algum ponto você pode precisar
quebrá-la em pacotes NPM separados (semelhante ao que fazemos com as
class libraries em Java e C#).
Em geral, o que se recomenda a fazer com Node.js é sempre trabalhar

com pacotes pequenos, especialmente para bibliotecas, uma vez que o fato de
usar a linguagem Javascript não ajuda muito em manter o controle e previsibili-
dade de funcionamento em uma aplicação conforme ela fica muito grande.
Sendo assim, conforme sua aplicação for crescendo e partes do seu código co-
mecem a se tornar reutilizáveis, mova-os para um pacote como se fosse um
subsistema ou biblioteca, tornando-o independente no NPM.
22
CASOS DE USO MAIS COMUNS
Aplicações em Tempo Real
Um exemplo comum é uma aplicação de conversa (chat). Tal aplicação

exige muito pouco processamento e basicamente consiste em transferir as men-
sagens de um lado para outro.
Ambientes Escaláveis
O Node.js é bastante indicado para ambientes escaláveis (com grande

número de conexões concorrentes), já que tem potencial para suportar um nú-
mero maior de conexões simultâneas do que servidores tradicionais.
Camada de Entrada do Servidor
O Node.js faz pouco processamento de dados e apenas passa a requisi-

ção para frente, se comunicando com serviços de backend.
Mocks e Protótipos
Por utilizar uma linguagem bastante conhecida no mundo Web, o Node.js

possibilita criar mocks e protótipos de APIs e serviços de backend com grande
rapidez, podendo assim simular a comunicação com um serviço externo, por
exemplo.
23
API com NoSQL por trás
As base de dados NoSQL são baseadas em JSON (JavaScript Object

Notation), portanto, sua comunicação com Node.js é bastante intuitiva. Com isso,
não é necessário converter modelos de dados, por exemplo, pois os mesmos
objetos JavaScript armazenados na base de dados podem ser enviados para o
front-end sem a necessidade de nenhum tipo de tratamento ou conversão.
24
Node.js está em uma incrível ascensão, é uma ferramenta extremamente

poderosa e que está mudando muita coisa no mundo do software.
Suas grandes vantagens são extensibilidade, escalabilidade e perfor-

mance, porém é necessária uma boa pré-avaliação antes de tomar a decisão de
fazer algo em Node, pois não é a solução ideal para todos os casos.
Com o passar dos anos, a tecnologia Node.js já rivaliza com tecnologias

tradicionais com como o ASP.NET, JSF, Ruby, PHP e Python em ambientes
dinâmicos como startups e empresas de produtos Web. Mesmo empresas tradi-
cionais no Brasil já têm começado a experimentar essa tecnologia bastante pro-
missora.
Ao mesmo tempo, algumas pessoas ainda perguntam: “É possível fazer

em Node.JS uma aplicação com acesso a banco de dados com controle transa-
cional, suporte a APIs REST, micro-serviços, com segurança forte, tolerância a
falhas e operação em cluster, entre outras preocupações técnicas corporati-
vas?”.
A resposta, retumbante, é sim.
Para isso basta você acrescentar novos módulos ao node com o co-
mando npm install -g <NomeModulo>. Isso é porque o Node.js vem pelado de
fábrica e você deve incluir módulos conforme necessário. Essa abordagem mi-
nimalista, que permite criar ambientes Web muito leves, é um dos fatores de
sucesso do Node.JS
25
REFERÊNCIAS
CARVALHO. Afonso A P. Arquitetura e desenvolvimento de uma apli-

cação web distribuída baseada em javascript. Rio de Janeiro, RJ – Brasil.
2014.
DUARTE, Leo. Boas práticas de arquitetura com NodeJS + Express.

2017.
LENON. Node.js – O que é, como funciona e quais as vantagens.

2018.
MENDES, Marco. Arquitetura de Software: Não Alimente Seus Paqui-

dermes. 2017.
SCHUMACHER, Matheus Schafer. Node.js - Uma descrição do ponto

de vista da Arquitetura de Software. 2019.
YODER, Joseph, apud FOOTE, Brian. Uma Breve Introdução à Arqui-

tetura Limpa com Node.js. 2021.
26
DEVOPS E GESTÃO DO CICLO DE VIDA DE APLICAÇÕES
1
NOSSA HISTÓRIA



2
Sumário
INTRODUÇÃO ........................................................................................ 4
O QUE É DEVOPS? ................................................................................ 6
AÇÕES RECOMENDADAS NA PRÁTICA DEVOPS .............................. 9
OS BENEFÍCIOS DE IMPLEMENTAR DEVOPS .................................. 11
DEVOPS NAS TRINCHEIRAS .............................................................. 15
O QUE É GERENCIAMENTO DO CICLO DE VIDA DE APLICAÇÕES 17
ETAPAS DO ALM .................................................................................. 19
OS PILARES DO ALM........................................................................... 22
OS MODELOS DE CICLO DE VIDA DO SOFTWARE .......................... 23
REFERÊNCIAS ..................................................................................... 28
3
INTRODUÇÃO
Apesar do mercado de desenvolvimento de software passar por um mo-

mento extraordinário, com uma demanda crescente, algumas empresas tem en-
contrado sérias dificuldades para adaptar-se a esse novo cenário.
Softwares cada vez mais funcionais e sofisticados, público extremamente

exigente, aliado a necessidade de entregas rápidas e constantes. Tal realidade
tem obrigado os profissionais de TI a repensarem conceitos arraigados e conso-
lidados, obrigando-os a adotarem novos modelos que possibilitem estarem ali-
nhados à nova demanda de entrega ágil.
A inevitável necessidade de inovação na gestão e no Ciclo de Vida das

Aplicações motivou o surgimento de uma nova metodologia denominada De-
vOps que é a fusão do termo “development” (dev) e o termo “operations” (infra-
estrutura). Seu conceito basicamente propõe que os processos de desenvolvi-
mento e operação da aplicação atuem integradamente, de modo a criar um fluxo
contínuo de novas experiências mais eficientes, frequentes e mais confiáveis aos
usuários.
Seu ciclo de vida é regido por 5 princípios básicos que podem ser lembra-
dos pelo acrônimo CALMS (em inglês), são eles: Culture (Cultura), Automation
(Automação), Lean (Enxuto), Measurement (Medição) e Sharing (Compartilha-
mento).
Das muitas mudanças sugeridas por este novo ciclo de vida, as mais re-
levantes e que merecem destaque são as culturais e tecnológicas. A cultura De-
vOps incentiva o desenvolvimento contínuo e colaborativo com entregas de alta
qualidade, não existindo barreiras para o compartilhar de informações, onde an-
teriormente havia nós (dev) e eles (ops), agora existe um TIME.
Já o processo tecnológico exigirá um alto nível de automação para geren-

ciar de forma única todo o ciclo, uma vez que a própria arquitetura das aplicações
4
deverá ser redesenhada para um modelo de serviços, com pontos de contato
com o mundo exterior através de um ecossistema de APIs.
5
O QUE É DEVOPS?
A palavra "DevOps" é a combinação dos termos "desenvolvimento" e

"operações". No entanto, ela representa um conjunto de ideias e práticas que
ultrapassam o significado desses dois termos. O DevOps inclui segurança, ma-
neiras colaborativas de trabalhar, análise de dados e muitas outras práticas e
conceitos. Mas do que se trata exatamente?
A metodologia DevOps descreve abordagens que ajudam a acelerar os

processos necessários para levar uma ideia do desenvolvimento à implantação
em um ambiente de produção no qual ela seja capaz de gerar valor para o usu-
ário. Essas ideias podem ser um novo recurso de software, uma solicitação de
aprimoramento ou uma correção de bug, entre outros.
Essas abordagens exigem comunicação frequente entre as equipes de

desenvolvimento e operações, trabalho colaborativo e empatia com os demais
membros das equipes. Escalabilidade e provisionamento flexível também são
necessários. Com o DevOps, aqueles que mais precisam de recursos conse-
guem obtê-los por meio do autosserviço e da automação.
Os desenvolvedores, que normalmente criam códigos em um ambiente

de desenvolvimento padrão, trabalham em estreita colaboração com a equipe
de operações de TI para acelerar a compilação de programas de software, a
realização de testes e o lançamento de soluções, sem sacrificar a confiabilidade.
Obviamente, isso significa alterações mais frequentes no código e utiliza-

ção mais dinâmica da infraestrutura. As estratégias de gerenciamento tradicio-
nais não dão conta desse tipo de demanda. Serão necessárias mudanças se
você quiser uma vantagem competitiva.
6
A metodologia DevOps tem se mostrado extremamente eficiente e im-
pacta em três importantes pilares do ciclo de vida de aplicações: Aumento de
Produtividade, Maior Qualidade na Entrega e Redução de Custo no Desenvolvi-
mento.
Na DATA SYSTEM não foi diferente, com uma cultura voltada para a qua-
lidade, produtividade e agilidade, resultados significativos foram alcançados. A
clara definição dos processos e objetivos, a integração colaborativa entre os de-
partamentos aliado a implementação de metodologias ágeis no processo de de-
senvolvimento concedeu para o DevOps méritos de uma moderna e importante
mudança de conceito e para a empresa a satisfação de poder entregar soluções
de maior performance aos seus clientes e singular notoriedade no mercado.
Apesar dos conceitos serem relativamente novos, DevOps já é uma rea-

lidade no mercado de TI. A adoção da nova metodologia requer quebra de para-
digmas tanto das empresas quanto dos profissionais, além de exigir uma comu-
nicação muito mais efetiva entre as áreas. A inflexibilidade diante dessa tendên-
cia poderá ter um alto custo e tornar profissionais e empresas pouco competiti-
vas e sustentáveis em um futuro bem próximo.
Devops é um termo criado para descrever um conjunto de práticas para

integração entre as equipes de desenvolvimento de softwares, operações (infra-
estrutura 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. O conceito propõe novos pensamentos sobre o trabalho para a
valorização da diversidade de atividades e profissionais envolvidos e atitudes
colaborativas. É um processo que torna possível o desenvolvimento ágil de apli-
cações em um modelo de gestão de infraestrutura definido sob regras rígidas e
burocráticas.
Tradicionalmente Desenvolvimento e Operações são setores diferentes

nas empresas e com motivações distintas. O setor de Desenvolvimento já evo-
luiu com adoção de metodologias ágeis e estão mais alinhadas ao negócio. O
setor já consegue entregas rápidas e constantes para atender a expectativa dos
7
clientes por novos recursos e assim valorizar o produto da empresa. A área de
Operações, por sua vez, deseja o mínimo de alterações possíveis no ambiente
de produção, pois podem gerar um novo ponto de instabilidade o que desvalori-
zará o produto da empresa. Assim há interesses contraditórios. Um setor quer
evoluir e o outro garantir.
8
AÇÕES RECOMENDADAS NA PRÁTICA DEVOPS
Pessoas integradas: Apoiar e prover pensamentos que integrem as pes-

soas, que façam com que partilhem suas histórias e se desenvolva a empatia
entre elas para um trabalho conjunto eficaz e duradouro.
Foco no projeto: Crie uma atmosfera livre de culpa, com o objetivo em

comum: o projeto. Profissionais devem defender o projeto e não suas áreas de
atuação. É preciso romper tradições e fazer com que as equipes tenham um
comportamento colaborativo, construtivo e de respeito mútuo.
Reuniões conjuntas: em vez de promover discussões isoladas com a

equipe de desenvolvimento, operações ou apoio, sempre integre pelo menos um
profissional de cada área nas discussões dos setores para que tenham entendi-
mento dos objetivos a serem alcançados, recursos e demanda previstos, requi-
sitos necessários, problemas já enfrentados e riscos envolvidos sob uma mesma
ótica.
Negócio Just-in-Time: Fornecimento de aplicações e serviços que pro-

movam um desenvolvimento do negócio com qualidade e otimização do uso de
recursos humano, tempo, tecnológicos e/ou financeiros.
Infraestrutura para negócio: garantir continuamente a infraestrutura

com foco no negócio. Implantar mecanismos que permitam a área de operações
atenderem as expectativas do negócio e ainda sim manter sua confiabilidade.
Desenvolvimento Ágil: o desenvolvimento do software deve seguir uma

das metodologias ágeis para entregas rápidas e contínuas. ( SCRUM, XP, …)
Ambientes de Desenvolvimento, Homologação e Produção: que haja

pelo menos esses três ambientes e que sejam idênticos para evitar que uma
9
versão de software seja testada em um ambiente e executada em produção em
outro e assim surjam problemas não previstos.
Padronização nas configurações: para garantia de que os ambientes

sejam idênticos e contenham apenas mudanças homologadas, é preciso imple-
mentar um gerenciamento de configuração para que qualquer mudança inserida
manualmente nos servidores e não através de uma gerência de configurações
seja automaticamente desfeita.
Provisionamento dinâmico dos ambientes: os ambientes devem ser

criados sempre que necessários em processos automatizados para garantia de
que estejam sempre disponíveis. A equipe de desenvolvimento deve receber a
infraestrutura necessária para seu trabalho sem necessidade de intervenção da
equipe de operações. Ferramentas de automação deverão criar servidores, ins-
talar serviços, configurá-los e testá-los. Novos servidores poderão ser criados
temporariamente para ações específicas ou para escalonamento da solução.
Infraestrutura como um código: as configurações e scripts de execução

para instalação de serviços devem ser versionados no mesmo repositório e da
mesma forma que o código da aplicação para que possam ser disponibilizados,
auditados e evoluídos juntos.
Liberdade para Deploy: a equipe de desenvolvimento deve ser autô-

noma para realização de deploy nos ambientes, até produção sem necessidade
de processos burocráticos e interferência da área de operações.
Integração contínua: Ferramentas devem orquestrar todo o processo

envolvido na entrega de nova versão da aplicação que inclui a criação dos am-
bientes caso necessário, deploys dos códigos juntamente as configurações da
infra, testes automatizados, possibilidade de reversão e auditoria.
Gestão de incidentes: Para que a infraestrutura seja ágil é determinante

que haja estratégias para gestão de incidentes bem definidas, políticas de roll
back, backups e ferramentas de monitoração proativas.
10
OS BENEFÍCIOS DE IMPLEMENTAR DEVOPS
Segurança
Trabalhar com DevOps faz com que a empresa utilize a infraestrutura e

tenha diretrizes específicas. Isso torna viável aos gestores a definição e o ras-
treamento de conformidade. Além de garantir a segurança das operações, tudo
fica mais claro.
A possibilidade de monitorar os registros em tempo real e analisar o fun-

cionamento do software contribui para que os erros sejam diagnosticados. Isso
aumenta a rapidez na solução de problemas e permite a entrega contínua, via-
bilizando mais testes feitos pela equipe responsável.
As ferramentas adotadas com a metodologia DevOps fazem com que se-

jam definidas as ações a serem concluídas para que a produção aconteça ime-
diatamente. Logo após a construção do software e dos testes realizados, é pos-
sível garantir a segurança operacional e a satisfação do seu público.
Facilidade em intervenção proativa
Com as equipes integradas e multidisciplinares, todo o quadro de funcio-

nários de TI se envolve no mesmo projeto de software. O gestor tem a possibili-
dade de ouvir os problemas e o time pode chegar, de forma harmoniosa, à solu-
ção de cada falha observada.
Essa intervenção proativa diminui os gastos e economiza o tempo de pro-

dução ou entrega. É viável, portanto, identificar erros e resolvê-los o mais rápido
possível. Isso ocorre porque os projetos não são entregues prontos, mas sim por
etapas.
11
As pequenas entregas, ao contrário daquelas únicas e mais amplas, fa-
zem com que o produto criado seja otimizado e atenda mais às necessidades do
seu cliente.
Maior capacitação
Não existe escapatória: para utilizar a metodologia, é preciso entender o

que é DevOps e formar equipes muito bem treinadas. Será necessário capacitar
seus funcionários e promover treinamentos com profissionais especializados,
qualificando ainda mais os times.
Ao aumentar o preparo dos colaboradores, automaticamente você eleva

a qualidade do seu produto. Além disso, a empresa diminuirá a rotatividade, eco-
nomizará com contratações e será referência no setor em que atua.
Os funcionários trabalharão com mais comprometimento e uma maior pro-

dutividade, refletindo no resultado do software e em sua relação com o cliente.
Isso também deixa os times mais abertos a mudanças e a ouvirem o que os
gestores têm a dizer, já que eles se sentem valorizados e parte importante do
processo de criação e viabilização.
Colaboração entre as equipes
Quando uma organização opta por trabalhar com automação em DevOps,

tudo flui mais facilmente. Podemos citar como vantagem a criação de equipes
mais entrosadas e multidisciplinares.
Com esse novo quadro, a empresa trabalha com colaboradores aptos a

solucionarem problemas amplos e que não se limitam a um único setor. A comu-
nicação acaba por ser mais clara, objetiva e harmoniosa. Essa vantagem faz
com que os colaboradores conheçam todas as etapas de criação e estejam pre-
sentes nas decisões e operações.
12
Equipes integradas
A metodologia não só promove a união de dois times específicos como

também aproxima as áreas dos gestores e donos do produto (PO), viabilizando
uma comunicação mais aberta e eficiente.
Com as equipes trabalhando em parceria, é possível identificar os proble-
mas mais rapidamente e, por meio da troca de experiências, propor, debater
ou implementar soluções com maior velocidade. Assim, o trabalho se torna mais
estável e fluido.
Além da redução de custos que a agilidade na solução de problemas pro-

porciona, muitas empresas veem nesse modelo a possibilidade de diminuírem
gastos também com mão de obra. Por isso, em organizações de pequeno porte,
é comum observarmos as duas áreas dando lugar a uma equipe única, mais
enxuta e multidisciplinar.
Processos mais simples e automatizados
Uma característica da solução DevOps é utilizar práticas e recursos para

deixar os processos mais simples e menos burocráticos. Um exemplo é o uso
da ferramenta Kanban, que dá transparência, permitindo que todos vejam as
etapas do projeto e quem está realizando cada atividade o que facilita a interação
entre os profissionais.
Não é diferente no desenvolvimento: qualquer atividade rotineira de codi-
ficação, implementação ou testes deve ser automatizada sempre que possível.
Uma tendência em ambientes DevOps é a utilização de Cloud Computing, visto
que agrega tecnologia de ponta e reduz a operação de infraestrutura.
Com tudo isso, os profissionais ganham tempo para que:
 se dediquem à melhoria contínua;
 aprimorem features;
 monitorem aplicações;
 documentem;
13
 pesquisem;
 compreendam falhas.
Entregas com mais qualidade e velocidade
As melhorias significativas no ambiente de produção propiciam a coope-

ração entre equipes e simplificação de processos. Isso garante a confiabilidade
de seus sistemas, além dos aumentos de qualidade e velocidade nas entregas.
A capacidade de lançar recursos frequentemente e corrigir problemas
com agilidade, mantendo uma experiência de uso positiva para o cliente, agrega
uma importante vantagem competitiva ao negócio.
14
DEVOPS NAS TRINCHEIRAS
A maioria dos técnicos querem saber sobre os detalhes da entrega contí-

nua, já que é impossível alcançar ganhos de produtividade DevOps sem auto-
mação e workflows aprimorados. Armon Dadgar, co-fundador da Hashicorp, fa-
mosa por criar ambientes de desenvolvimento portátil com o Vagrant, desmem-
bra o DevOps em 7 elementos essenciais: construir, testar, empacotar, provisio-
nar, cuidar da segurança, fazer o deploy e monitorar.
( Fonte: https://blog.mandic.com.br/artigos/o-real-significado-do-termo-devops/ )
Alguém pode notar que o método waterfall inclui esses mesmos elemen-
tos. Então, como chamar isso de DevOps? Defende Dadgar: “O objetivo do De-
vOps é paralelizar o máximo possível. Esses 7 passos são necessários e sufici-
entes, mas não precisam ser feitos sequencialmente “.
De forma desacoplada, a equipe de operações processa o provisiona-

mento e a implementação; os profissionais de segurança bloqueiam o(s) ambi-
ente(s) em que os aplicativos serão executados; e os desenvolvedores cons-
troem, testam e empacotam os aplicativos. Dadgar também diz que os desen-
volvedores devem ser responsáveis pelo monitoramento de aplicativos para
15
cumprir um princípio-chave do DevOps – ou seja, os desenvolvedores devem
manter a responsabilidade pelos aplicativos em produção, ao invés de deixar a
tarefa para a equipe de operações.
De acordo com Dadgar, um ponto crítico é o provisionamento, cujo ciclo

de vida complexo tem ajudado a orientar a adoção DevOps:
“Como provisionar e gerenciar essa complexidade, especialmente quando as coisas in-

teragem umas com as outras? Não que o servidor web seja totalmente dissociado do cache, do
banco de dados e do balanceador de carga frontend. Eles são todos fortemente relacionados de
uma forma complexa. À medida que as coisas vão sendo terceirizadas, vou executar o meu
servidor web e eu vou usar um banco de dados da Amazon, e DynDNS e CloudFlare na frente.
Agora estou gerenciando o ciclo de vida através de recursos de fornecedores totalmente diferen-
tes”, explica o executivo.
Para ele, o DevOps é mais processo do que ferramentas. “Acho que é

isso que se perde no modo como está representado. Há uma fixação em ferra-
mentas porque as ferramentas são fáceis. O difícil é mudar o processo organi-
zacional”.
16
O QUE É GERENCIAMENTO DO CICLO DE VIDA DE APLI-
CAÇÕES
O gerenciamento do ciclo de vida de aplicações (ALM) abrange as pes-

soas, as ferramentas e os processos que gerenciam o ciclo de vida de uma apli-
cação, desde o conceito até o fim do ciclo.
O ALM é composto por várias disciplinas que já foram separadas em pro-

cessos de desenvolvimento legados, como o método de desenvolvimento em
cascata. Elas incluem gerenciamento de projetos, gerenciamento de requisitos,
desenvolvimento de aplicações, teste e controle de qualidade, implantação e
manutenção.
Ao integrar essas disciplinas e permitir que as equipes colaborem de ma-

neira mais eficiente na sua organização, o gerenciamento do ciclo de vida de
aplicações possibilita as abordagens de desenvolvimento ágil e DevOps.
Além disso, a adoção do ALM promove a entrega contínua de aplicações

e atualizações frequentes, como várias por dia, em vez de novas versões apenas
a cada poucos meses ou uma vez por ano.
O gerenciamento do ciclo de vida de aplicações oferece um framework

para desenvolvimento de aplicações e também ajuda você a gerenciar suas apli-
cações ao longo do tempo. As práticas de ALM seguem um plano pré-estabele-
cido simples e os requisitos para transformar uma ideia em uma aplicação.
Ao adotar uma abordagem de desenvolvimento de aplicações com ALM,

é preciso considerar todo o ciclo de vida da aplicação. É necessário levar em
conta a manutenção e as atualizações futuras, incluindo quando a aplicação será
descontinuada e substituída.
17
Juntando essas informações, o ALM é capaz de oferecer implantações
mais rápidas, maior visibilidade do fluxo de trabalho, produtos de melhor quali-
dade e maior satisfação do desenvolvedor.
“Gerenciamento do ciclo de vida da aplicação é um método de gerenciar o desenvolvi-

mento de software e as iniciativas da TI utilizando um processo automatizado do inicio ao fim e
integrando a informação em cada estagio do projeto. O ALM ajuda a sincronizar os objetivos do
negocio com as prioridades de investimentos da TI e pode transformar a TI de um centro de
custos para um valioso ativo do negócio.”
A Governança engloba todas as decisões tomadas e o gerenciamento do

projeto da aplicação, ela se estende por todo o tempo do ciclo de vida.
O Desenvolvimento, é o processo de realmente criar a aplicação e acon-

tece entre a ideia e a entrega da aplicação, e para a maioria das aplicações volta
a aparecer de tempos em tempos devido a melhorias e correções de erros.
A Operação é a utilização e gestão da aplicação, geralmente inicia logo

após a entrega da mesma e acontece até que a aplicação deixe de ser utilizada.
Essas três áreas do ALM – governança, desenvolvimento e operações –

estão extremamente conectada uma a outra. Realizar as três de maneira correta
é o requisito de qualquer organização que aspira maximizar o valor do seu sof-
tware ao negócio. Mas não é um objetivo fácil de ser alcançado, cada uma das
três tem seus desafios para que sejam feitas da maneira correta e combinar as
três da maneira certa é ainda mais desafiador.
18
ETAPAS DO ALM
O ALM ajuda a dar visibilidade ao processo de desenvolvimento. Como o

processo é integrado, é possível acompanhar o progresso, ver as etapas que
ainda precisam ser concluídas, o tempo que cada passo leva, quais testes já
foram feitos e etc.
Governança da aplicação
A governança descreve as decisões tomadas sobre uma aplicação. Ao
começar o processo de criação de uma nova aplicação, geralmente há uma ideia
inicial, mas é importante levar em consideração como ela dialogará com os ob-
jetivos e necessidades da sua empresa.
Isso contribui para o estabelecimento dos requisitos da nova aplicação,

que precisam ser definidos e acordados na etapa de governança.
Gerenciamento de recursos, dados e segurança e acesso dos usuários

são outros componentes da governança da aplicação.
A padronização desses processos resulta na capacidade de automação

da governança. E a automação agiliza a entrega de aplicações.
Desenvolvimento das aplicações
Depois que os requisitos da aplicação ou atualização forem definidos e

acordados, é possível começar o desenvolvimento. As equipes que seguem
a metodologia ágil talvez desenvolvam e implantem uma ou várias vezes por
dia.
As etapas de design, criação, teste e implantação da aplicação podem ser

consideradas parte da fase de desenvolvimento.
19
Teste das aplicações
Depois de desenvolvida, a nova aplicação precisará ser testada e será

necessário corrigir bugs antes de passar para a etapa de produção.
Para as equipes ágil e de DevOps, os testes devem ocorrer simultanea-
mente com o desenvolvimento. O feedback precisa ser transmitido para a equipe
de desenvolvimento de forma contínua.
A integração contínua precisa fazer parte do processo de desenvolvi-

mento para evitar que essas atualizações frequentes entrem em conflito.
O objetivo da etapa de testes é assegurar que os requisitos definidos pela
governança foram atendidos e que a aplicação funciona corretamente antes de
ser liberada para os usuários.
Operações e manutenção
Depois que os testes forem concluídos e os bugs corrigidos, a aplicação

poderá ser implantada para os usuários.
É na etapa de operações e manutenção que o ALM se concentra no ciclo

de vida completo de uma aplicação. As operações não terminam depois que uma
aplicação é implantada. É preciso levar em conta a manutenção regular e as
atualizações.
Também é preciso considerar a descontinuidade da aplicação ou do ser-

viço como parte da manutenção. As equipes devem definir em que momento a
aplicação não terá mais suporte ou uma nova versão será disponibilizada.
20
( Fonte: https://leonardo-matsumota.com/2018/01/14/alm-application-lifecycle-manage-
ment-ciclo-de-vida-da-aplicacao/ )
21
OS PILARES DO ALM
Os pilares que estruturam o ALM e trabalham de forma complementar

para prover o gerenciamento do ciclo de vida aplicação:
(Fonte: https://leonardo-matsumota.com/2018/01/14/alm-application-lifecycle-manage-
ment-ciclo-de-vida-da-aplicacao/ )
Pessoas – o time envolvido na gestão do ciclo de vida da aplicação inclui

atribuições desde o alinhamento estratégico até a execução do desenvolvimento
de sistemas. As empresas comumente concentram estas responsabilidades em:
Executivo, PMO, Gerente de Projetos e Gerente de Operações; Analista de ne-
gócios, Arquiteto, Desenvolvedor, Tester e DBA
Processos – conjunto de boas práticas, artefatos, guias e manuais que

orientam o desenvolvimento e manutenção de uma aplicação
Ferramentas – engloba meios/equipamentos/tecnologias que automati-

zam e facilitam a condução dos processos pelas pessoas
22
OS MODELOS DE CICLO DE VIDA DO SOFTWARE
Conforme o mercado de desenvolvimento de sistemas evoluiu, diferentes

modelos de ciclo de desenvolvimento foram criados. Cada um buscava atender
a diferentes necessidades, o que exige do gestor um cuidado maior na hora de
escolher o seu. Confira, a seguir, os principais modos de manter uma aplicação
funcional!
Cascata
Esse é um dos modelos mais antigos do mercado. Ele surgiu na década

de 1970 e é utilizado até hoje por várias empresas. As suas etapas principais
são:
 a análise e a definição de requisitos;
 o planejamento do projeto de desenvolvimento;
 a implementação das funcionalidades no código-fonte;
 a execução dos testes de segurança e rastreamento de
bugs;
 a integração da aplicação no ambiente de trabalho do usu-
ário.

O modelo de cascata é mais rígido do que outras opções modernas. Ele
exige que os gestores iniciem uma etapa apenas após a atual ser completa. Além
disso, o término de cada etapa envolve a criação de um documento que lista
resultados e deve ser aprovado pelos líderes do projeto.
Em outras palavras, o modelo de cascata tem maior foco no planejamento

de etapas e exige uma rigidez maior na hora de executar cada rotina. Assim, os
times terão objetivos claros, imutáveis e transparentes. Isso evita retrabalhos e
mudanças inesperadas, que possam comprometer os prazos atuais.
23
Incremental
Esse modelo foi criado na década de 1980. Ele tem um contato contínuo
entre os responsáveis pelo projeto e o cliente. Desse modo, é possível maximizar
a satisfação e evitar riscos.
No modelo de ciclo de vida incremental a empresa divide os requisitos e

funcionalidades em módulos. Cada um deles é, então, avaliado e classificado
com um nível de prioridades. Sendo assim, o time pode planejar etapas com foco
nos módulos prioritários.
Ao término de cada etapa, o cliente recebe uma amostra do software com

as funcionalidades já criadas. Isso permite que os recursos mais importantes
sejam testados rapidamente no ambiente de produção. Ou seja, a empresa terá
mais meios para coletar dados sobre o uso da aplicação e o que pode ser feito
pra otimizá-la.
As chances de o cliente ter elevado satisfação também são maiores. Afi-

nal, ele poderá entregar um feedback contínuo sobre os recursos e as suas ex-
pectativas. Portanto, a empresa pode criar maior alinhamento com o usuário e
as suas demandas.
Modelo evolutivo
No modelo evolutivo os requisitos são levantados de modo paralelo à evo-

lução da aplicação. Ele é útil especialmente nos cenários em que as funcionali-
dades necessárias para a solução não estão definidas corretamente. Assim
como no modelo incremental, há uma comunicação direta com o cliente, permi-
tindo que ele aplique feedbacks e auxilie na melhoria dos recursos de modo con-
tínuo.
24
Sempre que um feedback é entregue, um novo projeto de desenvolvi-
mento se iniciará. Em outras palavras, as mudanças no sistema e as suas atua-
lizações são feitas como a evolução de uma espécie: a cada nova versão do
software, melhorias são aplicadas para garantir maior satisfação do usuário.
O maior benefício desse modelo de ciclo de vida é a possibilidade de ter

alta satisfação do cliente. Como ele realiza feedbacks contínuos, as chances de
um requisito ser entregue de modo inadequado são menores. Assim, o usuário
terá em suas mãos uma aplicação que se adapta mais às suas demandas.
Modelo espiral
No modelo espiral, criado em 1988, as fases são tratadas de modo cíclico.

A cada iteração (ou “volta” do ciclo), o usuário tem acesso a versões evolucio-
nárias do software. Nele, há menos flexibilidade para lidar com possíveis falhas
e bugs.
Por isso, cada etapa demanda maior planejamento. A empresa deve estar
atenta para possíveis problemas, testando funcionalidades e avaliando eventu-
ais incompatibilidades. Além disso, é necessário manter o cliente vinculado a
cada etapa aplicando feedbacks e orientando mudanças futuras.
A “espiral do ciclo de vida” é dividida em alguns setores, que são:

 a definição de objetivos, desempenho mínimo e funcionali-
dades, assim como o escopo da etapa e as suas restrições;
 a análise de riscos e a prototipagem de funcionalidades;
 o desenvolvimento e a validação de um modelo de desen-
volvimento alinhado com as demandas;
 a execução de cada demanda;
 a avaliação dos resultados;
 o planejamento da próxima etapa.
Como vimos, existem diferentes modelos de ciclo de vida de desenvolvi-

mento de um sistema. Eles são formulados para atender às várias demandas do
25
mercado e, com isso, garantir a satisfação de múltiplos perfis de usuário. Por
isso, devem ser tratados como uma ferramenta estratégica.
Ou seja, a empresa deve avaliar continuamente o que envolve o seu pro-

jeto de desenvolvimento e, então, escolher um modelo de ciclo de vida do sof-
tware adequado. Desse modo, ela conseguirá orientar as suas decisões com
mais qualidade e maximizar o retorno sobre o investimento realizado.
26
O processo de desenvolvimento de software é uma atividade bastante

complexa e tem aumentado muito com as necessidades cada vez maior por sis-
temas computacionais. Essa demanda crescente traz consigo a preocupação
em maximizar os resultados através de um controle eficaz das aplicações de
software, controle que permita a escalabilidade dos sistemas e o acompanha-
mento de todo o seu ciclo de vida. Para um acompanhamento eficaz processos
e metodologias existem como forma de oferecer auxílio, utilizando para isso mui-
tas ferramentas.
Concluindo percebe-se que a adoção do conjunto de ferramentas pro-

posto serve para solucionar muitos dos problemas encontrados no processo de
desenvolvimento de software, observa-se também que essa implementação de
ferramentas e práticas pode ser feita de forma gradual.
27
REFERÊNCIAS
CADAVEZ, Carlos dos Santos. Gerenciamento do ciclo de vida de apli-

cações, utilizando ferramentas open source. 2014.
FALOURD, Guillaume. Tudo sobre Devops: o que é, como funciona e

boas práticas. 2019
FREITAS, Rodrigo. DevOps – Um Novo Ciclo de Vida para Aplicações.

2019.
VERTIGO, Marketing. O que é DevOps? 2018.
ZANETTI, David. Saiba o que é DevOps e como essa metodologia

ajuda a inovar em TI: 2018.
28
ANÁLISE, PROJETO E AVALIAÇÃO DE ARQUITETURA DE
SOFTWARE
1
NOSSA HISTÓRIA



2
Sumário
INTRODUÇÃO ................................................................................................... 4
PARA QUE SERVE A ARQUITETURA DE SOFTWARE E COMO ELA AJUDA

OS NEGÓCIOS? ................................................................................................ 6
DESENVOLVIMENTO DE SISTEMA DE SOFTWARE ...................................... 7
APLICANDO A ARQUITETURA DE SOFTWARE NOS NEGÓCIOS ................ 8
ANÁLISE DE ARQUITETURA DE SOFTWARE .............................................. 10
PROPRIEDADES DA ARQUITETURA DE SOFTWARE ................................. 12
MÉTODO DE ANÁLISE DE ARQUITETURA DE SOFTWARE ........................ 14
USO DE ATRIBUTOS DE QUALIDADE NA ANÁLISE ARQUITETURIAL ....... 16
A ESCOLHA DO MODELO ARQUITETURIAL PARA UM SOFTWARE .......... 19
AVALIAÇÃO DA ARQUITETURA DE SOFTWARE ......................................... 21
O FUTURO DA ARQUITETURA DE SOFTWARE ........................................... 23
CONSIDERAÇÕES FINAIS ............................................................................. 25
REFERÊNCIAS ................................................................................................ 26
3
INTRODUÇÃO
Todos os dias usamos diferentes aplicativos, ferramentas e sistemas online, seja

no desktop ou celular. Isso não é segredo para ninguém. O que muitos desco-
nhecem é que por trás de um aplicativo há uma grande estrutura organizacional
desenvolvida pela arquitetura de software .
Esta área da TI é responsável pela análise estratégica dos componentes opera-

cionais antes de criar soluções viáveis para uma tecnologia , considerando o
desempenho, escalabilidade, interoperabilidade, compatibilidade e performance.
A qualidade do software, assunto estudado pela área de Engenharia de software,

está cada vez mais sendo procurada por essas empresas com o intuito de valo-
rizar os seus produtos e serviços no mercado de software [GRUNSKE et all
2002]. A qualidade é uma característica importante, pois ela ajuda a garantir a
satisfação do cliente fazendo com que este procure a empresa mais vezes. Além
disso, a produção de produtos com qualidade reduz o custo da empresa no mo-
mento da manutenção do software.
Existem grandes estudos sendo executados nesta área, porém muitos pontos
ainda não foram esclarecidos ou avaliados. Uma das grandes dificuldades para
a avaliação da qualidade do produto de software é que grande parte dos testes
só pode ser executada após a finalização do software. Isto significa um alto custo
e um grande esforço de mudança caso a qualidade desejada não seja atingida.
Para evitar estas situações, cada vez mais estão surgindo metodologias e técni-
cas que auxiliam tanto no processo de desenvolvimento do software como tam-
bém para a avaliação dos artefatos gerados. Baseando-se nesta idéia, foram
criados vários trabalhos para avaliar a qualidade do produto de software através
do estudo de sua arquitetura.
4
Através da arquitetura do sistema, é possível prever alguns dos possíveis com-
portamentos do software antes de sua conclusão, além de poderem ser obser-
vadas características importantes como coesão, que influencia na manutenção
do produto.
A arquitetura é basicamente definida por requisitos não funcionais [BACHMANN

et all 2005]. Por isso, ela é capaz de responder sobre o comportamento final do
software relacionado às características como escalabilidade, segurança, manu-
tenibilidade e desempenho [BENGTSSON 1998] [BENGTSSON et all 2001]
[MENDES 2002], sendo inclusive considerada a chave para atingir as exigências
desses requisitos [BARBACCI et all 2003] [BARBACCI et all 2005]. Utilizando-se
deste fato uma avaliação qualitativa da arquitetura pode prever problemas no
software antes dele ser finalizado. Isto diminuiria o custo para adequar o sistema
aos padrões de qualidade.
5
PARA QUE SERVE A ARQUITETURA DE SOFTWARE E COMO
ELA AJUDA OS NEGÓCIOS?
A arquitetura de software de um sistema serve para definir a organização das

funcionalidades desse sistema e propriedades ou requisitos não funcionais su-
portados pelo mesmo. Características peculiares da arquitetura determinarão
quais propriedades serão preponderantes. A necessidade da arquitetura de sof-
tware prover suporte a um conjunto de requisitos, geralmente conflitantes, requer
que uma análise arquitetural seja realizada, tema tratado neste artigo.
Com a arquitetura de software, é possível entender as diferenças entre as lin-

guagens, sistemas operacionais e ambientes da computação. Ou seja, qualquer
componente tecnológico pode ser usado para integrar uma solução arquitetural.
Essa parte é essencial porque otimiza o trabalho dos designers e desenvolvedo-
res, permitindo que uma aplicação esteja dentro dos padrões básicos necessá-
rios para funcionar de forma assertiva.
O professor de Arquitetura de Software do IGTI Rafael Lobato explica que a área

é importante para automatizar novos processos ou melhorar os já existentes.
Assim, os projetos desenvolvidos pelo arquiteto de software acabam diminuindo
os riscos associados ao sistema. “Em poucas palavras, as tecnologias concreti-
zam um software de modo funcional e adequado para resolver a solução de um
negócio”, completa.
Além da escolha dos algoritmos e estruturas de dados, a arquitetura envolve:

decisões sobre as estruturas que formarão o sistema, controle, protocolos de
comunicação, sincronização e acesso a dados, atribuição de funcionalidade a
elementos do sistema, distribuição física dos elementos escalabilidade e desem-
penho e outros atributos de qualidade.
6
DESENVOLVIMENTO DE SISTEMA DE SOFTWARE
O processo de desenvolvimento de sistemas de software, similarmente a outros

sistemas, compreende três fases genéricas – definição, desenvolvimento e ma-
nutenção – conforme ilustrado na abaixo.
Fases genéricas no processo de desenvolvimento de software.
(Fonte: https://www.devmedia.com.br/artigo-engenharia-de-software-14-analise-da-arquitetura-
de-software/13254 )
A fase de definição engloba a identificação de informações que deveriam ser

processadas, funções e desempenho desejados, tipo de interface a ser utilizada,
tarefas que o sistema deveria prover suporte, perfil de usuários do sistema, den-
tre outras.
A fase de desenvolvimento concentra-se no projeto de estruturas de dados e ar-

quitetura de software do sistema, conversão do projeto para alguma linguagem
de programação, realização de testes e avaliação. Finalmente, a manuten-
ção considera modificações e/ou correções necessárias no sistema a fim de que
este atenda aos requisitos do usuário. Perceba que o processo de desenvolvi-
mento de um sistema de software tem duas grandes atividades de interesse: o
desenvolvimento da porção de software que implementa as funcionalidades do
sistema, e a atividade que a antecede e norteia o desenvolvimento, que é o pro-
jeto da arquitetura de software. Essa última atividade é resultado da análise ar-
quitetural que provê informações para decisões arquiteturais,
7
APLICANDO A ARQUITETURA DE SOFTWARE NOS NEGÓCIOS
Para as empresas, a arquitetura de software tem o objetivo de atender uma visão

orientada aos negócios. Pensando nisso, os profissionais são encarregados pela
estrutura de um sistema, planejamento estratégico, padrões de projetos arquite-
turais, otimização e escalabilidade do negócio e construção de soluções para
aplicações.
“O arquiteto deve ter sempre o senso crítico de avaliar novas formas de aplicar
estas tecnologias ou até de sugerir algo que nunca antes tenha sido utilizado”,
diz Lobato. O que na prática é a criação ou seleção dos componentes e intera-
ções fundamentais para que a tecnologia seja implantada. Assim, por trás de
toda a tecnologia, há uma representação de informação adequada às necessi-
dades dos consumidores ou colaboradores.
Com isso, destacamos os principais benefícios que a arquitetura de software traz

ao mundo corporativo:
 Redução de riscos ao negócio

 Alinhamento de expectativas entre os diferentes setores da empresa
 Construção de aplicações flexíveis e de qualidade
 Integração com diferentes linguagens e sistemas
 Segurança das aplicações
Diferentemente de algumas áreas, a arquitetura de software é indispensável nas

empresas, principalmente àquelas que têm a tecnologia como premissa no mo-
delo de negócio. Exemplo disso são marcas como o NuBank, Facebook, Uber,
Slack e até os Correios, que criam diversas soluções com base no desenvolvi-
mento ágil, transformação digital e arquiteturas escaláveis.
8
Normalmente, essas companhias buscam por uma modelagem específica, com-
binando componentes com base em uma visão arquitetural que mais se adeque
ao software. Para isso acontecer, os arquitetos avaliam todas as opções de im-
plementação de um sistema.
Para os profissionais do ramo, essa parte é conhecida como visões da arquite-

tura, porque permitem uma análise geral do sistema e, a partir daí, selecionam
as estruturas dos conjuntos que farão parte do processo para o melhor funcio-
namento da aplicação.
9
ANÁLISE DE ARQUITETURA DE SOFTWARE
O projeto da arquitetura de software é uma etapa essencial no desenvolvimento

de sistemas de software de grande porte. Dentro deste contexto, a arquitetura
de software é fundamental para o desenvolvimento de software onde se tem
funcionalidades distintas, sendo concebidas a partir da mesma arquitetura base.
Entretanto, antecedendo a etapa de projeto da arquitetura de software, há a ne-
cessidade de fazer o levantamento dos requisitos do sistema.
De um modo geral, a análise e projeto de um sistema geralmente engloba as

atividades de:
 Desenvolvimento de modelo arquitetural – Os dados são coletados du-

rante a elicitação de requisitos a fim de serem analisados e incorporados
ao modelo arquitetural (isto é, o produto resultante). Neste caso, o modelo
passa a ser o elemento central da análise.
 Melhoria e síntese de uma solução – Incrementam-se as informações

descritas no modelo arquitetural (inicial)
 Análise da solução – A análise da solução é realizada em termos do mo-

delo arquitetural que se tem em mãos, podendo identificar a necessidade
de refinar o modelo.
Perceba que o modelo arquitetural pode ser considerado como um ‘esboço’ ini-
cial da arquitetura de software do sistema em desenvolvimento. É importante
ainda observar que a análise de uma arquitetura de software é um processo
iterativo no qual são feitos refinamento de um modelo arquitetural inicial, deri-
vado a partir de um conjunto de requisitos arquiteturais. Em cada iteração, uma
mini análise ocorre, refinando a arquitetura proposta inicialmente. Esse processo
é ilustrado na figura abaixo.
10
(Fonte: http://www.garcia.pro.br/EngenhariadeSW/artigos%20engsw/art%205%20-%20Re-
vista%20Engenharia%20de%20Software%20-%20edicao%2014%20-%20Ana-
lise%20da%20Arquitetura%20de%20Software.pdf )
Entretanto, note que não é tarefa fácil validar uma arquitetura de software quanto
ao suporte que oferece a um conjunto de requisitos. É muitas vezes difícil asso-
ciar novas arquiteturas a atributos de qualidade. Observa-se, geralmente, que
os desenvolvedores concentram-se nos aspectos funcionais das arquiteturas.
Assim, o principal propósito da análise arquitetural é verificar se os requisitos
arquiteturais têm sido levados em conta durante o desenvolvimento de um sis-
tema de software.
11
PROPRIEDADES DA ARQUITETURA DE SOFTWARE
A arquitetura de software é uma parte essencial de um sistema de software com-

plexo. Com a crescente complexidade de sistemas de software, a especificação
global do sistema, ou seja, sua arquitetura passa a ser um aspecto de maior
significado quando comparado à escolha de algoritmos ou estruturas de dados.
Um sistema possui um conjunto de requisitos arquiteturais, envolvendo atributos

de qualidade (ou requisitos não funcionais) e atributos de projeto. Esses requisi-
tos constituem propriedades desejadas ou apresentadas por uma arquitetura de
software. Dentre esses requisitos, uma arquitetura de software apresenta propri-
edades importantes que podem ser vistas como intrínsecas a ela. Tais proprie-
dades são: eficiência, integridade e flexibilidade
A eficiência pode ser descrita como a quantidade de recursos computacionais

necessários para que um programa realize suas funções. Esses recursos com-
putacionais podem ser vistos em termos da capacidade de armazenamento e
processamento. Um dos principais requisitos associados à eficiência é o desem-
penho. O desempenho é um requisito não funcional essencial para um sistema
de software e constitui num enorme desafio.
Lidar com tal requisito durante o desenvolvimento de um sistema. Por exemplo,

seria possível ter os seguintes requisitos de desempenho quando do desenvol-
vimento de um sistema de software para administração de cartões de crédito:
 Obter um bom tempo de resposta para autorização de vendas com cartão
de crédito. O termo bom poderia ser traduzido em 7 segundos.
 Obter um bom uso de memória para armazenar as informações de um
cliente. Poderia ser especificado o máximo de 10 Kb para armazenar as
informações de cada cliente. A eficiência é uma propriedade de suma im-
portância nas decisões de projeto e tem forte influência na análise arqui-
tetural de um sistema. Perceba que a forma na qual os componentes de
uma arquitetura encontram-se distribuídos, bem como os mecanismos de
12
comunicação entre eles, são determinantes do desempenho e, portanto,
da eficiência do sistema.
Essa propriedade, às vezes, atua em conflito com outros requisitos do sistema,

exigindo que compromissos sejam assumidos em termos de custo e desempe-
nho de um sistema de software. Outra importante propriedade é a integridade.
Aqui, a noção de integridade refere-se à integridade em termos da unificação do
projeto em níveis distintos. A arquitetura de software descreve a organização de
um sistema de software num nível mais elevado, objetivando a unificação do
projeto, ou seja, serve de referência para o projeto, conforme ilustrado na figura
abaixo.
lise%20da%20Arquitetura%20de%20Software.pdf)
Note que a arquitetura de software é central e essencial à qualidade de um sis-

tema, associados um conjunto de atributos de qualidade. Similarmente, a inte-
gridade (arquitetural) funciona como elemento coordenador que unifica o projeto
do sistema de software em diferentes níveis.
Complementando, outra importante propriedade é a flexibilidade, que diz res-

peito ao esforço exigido para modificar um sistema de software. Em outras pala-
vras, é a facilidade com a qual um sistema de software pode ser estendido a fim
de dar suporte a uma ou mais funcionalidade(s) adicionada(s).
Por exemplo, a criação de interfaces adicionais aumenta flexibilidade, incremen-

tando a facilidade de fazer modificações, uma vez que as interfaces separam
partes distintas de funcionalidade em componentes de software diferentes.
13
MÉTODO DE ANÁLISE DE ARQUITETURA DE SOFTWARE
Um exemplo de método de análise de arquitetura de software, denominado

SAAM (Software Architecture Analysis Method), foi inicialmente concebido com
o objetivo de auxiliar arquitetos de software a compararem soluções arquitetu-
rais, tendo sido o precursor de outros métodos de análise arquitetural. O método
SAAM compreende os seguintes objetivos:
 Definir um conjunto de cenários que representem usos importantes do

sistema no domínio, envolvendo os pontos de vista de todos aqueles que
possuem papéis influenciadores no sistema.
 Utilizar cenários para gerar uma partição funcional do domínio, uma orde-
nação parcial das funções e um acoplamento dos cenários às várias fun-
ções existentes na partição.
 Usar a partição funcional e ordenação parcial, juntamente com cenários

de uso, a fim de realizar a análise das arquiteturas propostas.
Assim, para cada cenário, a análise fornece uma pontuação das arquiteturas que
estão sendo avaliadas, denominadas de arquiteturas candidatas. Recai, por-
tanto, sobre o avaliador a responsabilidade de determinar os pesos dos cenários
considerados, bem como a pontuação global das arquiteturas candidatas.
O método de análise arquitetural SAAM é baseado no uso de cenários. Fazendo

uso de cenários, um analista pode usar uma descrição de arquitetura de software
para avaliar o potencial do sistema de software prover suporte a atributos de
qualidade ou requisitos não funcionais. Entretanto, é importante observar que
avaliar uma arquitetura de software para determinar se ela oferece suporte a
requisitos não funcionais não é tarefa fácil. Tais requisitos tendem a serem um
tanto vagos.
14
Objetivando realizar a análise, portanto, torna-se necessário considerar o con-
texto no qual o sistema de software encontra-se inserido, bem como considerar
as circunstâncias específicas àquele contexto. Uma forma de atingir esse obje-
tivo é fazendo uso de cenários a fim de entender e avaliar se uma arquitetura
oferece suporte ou não a um específico requisito não funcional, e sob quais cir-
cunstâncias.
SAAM compreende um conjunto de cinco passos que possuem interdependên-

cias entre si, conforme ilustra a figura abaixo.
15
USO DE ATRIBUTOS DE QUALIDADE NA ANÁLISE ARQUITE-
TURIAL
Uma das razões de concentrar atenção sobre a arquitetura é para identificar e

analisar as decisões iniciais de projeto. Transformar estas decisões de projeto
em uma estrutura que ofereça suporte a um raciocínio que permita antecipar
tendências a nível arquitetural é essencial para obter os benefícios do foco na
arquitetura.
Embora possamos apontar indicativos de qualidade, seria praticamente impos-

sível fazer previsão de qualidade num estágio inicial de projeto. Note que, por
exemplo, o método de análise arquitetural SAAM não objetiva precisamente pre-
ver o comportamento de atributos de qualidade. A meta desse método de análise
dá-se em entender o papel e as conseqüências de decisões arquiteturais em
relação aos atributos de qualidade de algum sistema que esteja sendo analisado.
Dessa forma, o método SAAM apresentado serve de ferramenta ao arquiteto ou

engenheiro de software para prever suporte a atributos de qualidade. Note que
isto é baseado em decisões de projeto que ocorrem no nível arquitetural.
Sabemos que a arquitetura é um elemento essencial para a obtenção de su-

cesso, em termos tecnológicos e de mercado de qualquer empresa. Geralmente,
as metas de qualidade e conjunto de funcionalidades constituem os principais
motivadores de um sistema.
Considere, por exemplo, um fabricante de centrais telefônicas que esteja desen-

volvendo um projeto de uma nova central. Assim, pode ser especificado que a
central deve ser capaz de rotear ligações telefônicas, prover suporte a diversos
tipos de tons, redirecionar ligações, gerar contas telefônicas de usuários com
discriminação de ligações efetuadas, dentre outras funcionalidades. Entretanto,
para que o sistema alcance sucesso na prestação de serviços para seus assi-
nantes, ele deve também operar com elevado nível de desempenho, facilitar
16
quaisquer modificações (em termos de adição ou alteração de características),
possuir bom nível de disponibilidade e ter baixo custo.
Como essas metas de qualidade podem ser alcançadas?
A arquitetura do sistema é um meio pelo qual podemos determinar se essas

metas de qualidade podem ser realizáveis ou não. SAAM e outros métodos cons-
tituem respostas a essa questão. Perceba que essa necessidade de prever o
comportamento de atributos de qualidade num sistema requer conhecimento de
estilos arquiteturais prováveis de serem empregados no sistema. Um estilo ar-
quitetural inclui:
 Descrição de tipos de componentes e sua topologia;

 Descrição de padrão de interação (no nível de dados e controle) entre os
componentes;
 Descrição informal das vantagens e desvantagens na adoção do estilo.
Estilos arquiteturais permitem ao arquiteto de software distinguir classes de pro-

jeto através de evidências existentes de como cada classe tem sido utilizada
juntamente com o raciocínio qualitativo para explicar porque certas classes têm
determinadas propriedades. Assim, por exemplo, pode-se adotar o estilo arqui-
tetural de pipes e filtros quando se deseja obter reuso e não há restrição quanto
ao desempenho.
Agora, pode ser feito um mapeamento de um estilo arquitetural em um conjunto

de modelos de atributos de qualidade. Estes modelos de atributos de qualidade
ajudam a prever o comportamento desses atributos. Esta noção de mapeamento
de decisões e propriedades arquiteturais em modelos de atributos de qualidade
é ilustrada na figura abaixo
17
18
A ESCOLHA DO MODELO ARQUITETURIAL PARA UM SOF-
TWARE
Depois de aplicar a visão da arquitetura, podemos avançar mais na rotina do

arquiteto de software. Considerando o melhor caminho para estruturar um sis-
tema, será fundamental pensar na próxima fase do projeto que é a definição do
padrão arquitetural – lembre-se que há uma infinidade deles. “Não existe um
funcionamento básico de tecnologia. Há formas infinitas de aplicar e atender os
diversos problemas existentes”, ressalta Rafael Lobato, professor do IGTI.
Mas, atualmente, há alguns padrões que são mais usados para a criação da
solução do software, que também são conhecidos como estilo de arquitetura.
Veja mais:
Arquitetura em camadas (Layered pattern)

Organiza um sistema de conjunto em camadas que podem ser desconstruídas
em diferentes serviços, trazendo um modelo incremental de desenvolvimento.
Os casos mais comuns para o uso desse padrão são em software de e-com-
merce e desktop.
Arquitetura cliente-servidor (Client-server pattern)

Estilo organizado em serviços combinando dados do cliente e do servidor. Para
isso, é primordial que o cliente disponibilize uma rede de acesso às informações.
Este cenário é um dos mais conhecidos na rotina das pessoas, já que podem
ser aplicativos bancários e e-mail.
Arquitetura MVC (Model-view-controller pattern)

Distribuído em três camadas (Modelo, Visão e Controle), este padrão é um dos
mais comuns para o online, porque traz um modelo interativo de sistema.
19
Arquitetura de microsserviços (Microservices pattern)
Este padrão utiliza múltiplos serviços e componentes para desenvolver uma es-
trutura modular favorecida. Hoje, é um dos modelos preferidos dos desenvolve-
dores e arquitetos de software por possibilitar a escalabilidade e independência
dos módulos – que até podem utilizar diferentes linguagens e programações.
Além de ser um dos modelos favoritos do momento, o microsserviços também

fica entre os destaques das tendências para a evolução da arquitetura de sof-
tware.
20
AVALIAÇÃO DA ARQUITETURA DE SOFTWARE
No decorrer dos últimos anos, as funcionalidades críticas dos sistemas vão len-
tamente se transferindo do hardware para o software. Juntamente com esta
transformação a complexidade dos sistemas vai aumentando [GRUNSKE et all
2002]. O desafio não é mais prover os atributos funcionais, mas sim garantir os
atributos de qualidade, pois estes requerem uma atenção explícita, para que, no
final, seja atingido um nível satisfatório.
A arquitetura deve especificar um mapeamento com os requisitos não funcionais

e atributos de qualidade, pois o sistema será fundamentalmente afetado pelas
decisões tomadas no desenvolvimento da arquitetura do software. Os requisitos
de qualidade direcionam a arquitetura do software da mesma forma que as ati-
vidades centradas na arquitetura definem o ciclo de vida do software.
Apesar de serem propostos alguns métodos de avaliação da qualidade da arqui-

tetura [BARBACCI et all 2003] [BENGTSSON 1998], eles possuem quase sem-
pre os mesmos objetivos: analisar o impacto futuro de decisões atuais nos requi-
sitos de qualidade, encontrar pontos sensíveis na arquitetura cuja mudança po-
deria causar problemas de qualidade do software e, por último, mas não menos
importante, elaborar tradeoffs nas decisões de projeto de arquitetura que influ-
enciem mais de um atributo de qualidade.
Outro fator importante na avaliação da arquitetura é que os atributos de quali-

dade, por si só, não contêm informações o bastante para influenciar o sistema.
Por exemplo, “o sistema deve ser modificável”, não agrega informações ao sis-
tema, pois todo o sistema é modificável com respeito a um conjunto de mudan-
ças e não com respeito a outros conjuntos.
21
Uma solução para este problema de descrição dos atributos de qualidade é a
utilização de cenários, como meio de caracterizar melhor esses requisitos. Os
cenários também são uma poderosa maneira para representar as visões e con-
ceitos que os stakeholders possuem desses atributos. Vários processos de ava-
liação utilizam à idéia de cenários, entre eles podem ser citados SAAM e QAW
[MENDES 2002] [BARBACCI et all 2005]. O processo proposto também é base-
ado em cenários, permitindo simular as necessidades e as mudanças que po-
dem ocorrer no software.
22
O FUTURO DA ARQUITETURA DE SOFTWARE
Definitivamente, no futuro do desenvolvimento dos sistemas estarão os modelos

de microsserviços, computação em nuvem e inteligência artificial. “Com os últi-
mos avanços ficou claro que ainda estamos longe de atingir um limite para o uso
da tecnologia. Estamos apenas no início de uma revolução e com as possibili-
dades totalmente em aberto”, completa Rafael Lobato, professor de arquitetura
de software do IGTI.
Essas três tendências têm caminhado bem próximas umas das outras, porque
são uma evolução natural da arquitetura de software, e também parte da revolu-
ção digital. Separamos as principais razões para ficar de olho em:
Computação em nuvem (cloud computing)

Em sua explicação mais simples, a computação em nuvem é uma solução tec-
nológica com acesso remoto a diferentes conteúdos online. Isso significa que
não é necessário mais um computador pessoal ou um servidor local para aces-
sar informações. Em nosso dia a dia já usamos a computação em nuvem para
editar documentos no Google Drive ou para escutar uma playlist no Spotify.
Só é preciso se atentar se o serviço que você desenvolverá precisará de uma

nuvem pública (o cliente é responsável por subir as informações ao provedor),
privada (modelo mais apropriado às empresas que oferecem domínio interno aos
colaboradores) ou híbrida (combinação dos serviços citados anteriormente), por-
que cada uma tem um impacto diferente em uma organização, inclusive no custo
e desempenho do serviço.
Inteligência artificial
Desenvolver software com base em inteligência artificial já é uma prática reali-
zada no mercado de TI, mas logo essa evolução tecnológica ficará mais fácil e
acessível para a produção de softwares e aplicativos. Graças a facilidade na
hora de programar e uma interface mais intuitiva que atende mais rapidamente
às necessidades dos negócios.
23
Microsserviços
A praticidade dos microsserviços criará um movimento de migração de sistemas
para as empresas que têm uma área de TI mais fortalecida e com maior produ-
tividade.
“O futuro da arquitetura, por mais que seja muito difícil prever, tem grandes chan-
ces de sempre procurar por novas tecnologias que otimizam o que já existe no
mercado”, ressalta Lobato.
24
Nesta apostila, um conjunto de propriedades de arquitetura de software consi-

deradas intrínsecas à estrutura do sistema foi apresentado. Estas propriedades,
juntamente com os requisitos arquiteturais, envolvendo requisitos não funcionais
e atributos de projeto, servem de base para a análise arquitetural.
O método de análise arquitetural SAAM foi apresentado, ilustrando-se os passos

de como fazer a análise. Adicionalmente, foi discutido o papel dos requisitos não
funcionais, ou atributos de qualidade, como mecanismo para auxiliar nas deci-
sões arquiteturais. Cabe destacar que a análise arquitetural é realizada sob a
óptica de minimizar custos e agregar benefícios, isto é, prover suporte aos requi-
sitos não funcionais.
A qualidade não está apenas nas funcionalidades. Ela também deve ser levada
em consideração no esforço gasto para manter o software sempre atualizado
com as mudanças requisitadas. Devido a isso existe a necessidade de averiguar
a facilidade de manutenção do software durante todo o seu ciclo de vida.
A escolha da arquitetura como base do processo foi devido ao fato de estudos e

pesquisas provarem que grande parte dos problemas de qualidade de um sof-
tware são conseqüências de problemas originados na fase de projeto do sof-
tware.
Apesar de existirem vários estudos sobre o relacionamento entre atributos de

qualidade e a arquitetura de software, ainda existem espaços a serem preenchi-
dos nessa relação. Atualmente, não existem mapeamentos perfeitos entre as
características presentes na arquitetura para atributos qualitativos do produto de
software final.
25
REFERÊNCIAS
VASCONCELOS, Alexandre M L, apud RIBEIRO, Diego de Azevedo. Avaliação

da Manutenibilidade da Arquitetura de Software. Recife – PE. Brasil
SANTOS, Régis. Arquitetura de Software: Avaliando a arquitetura de seus

sistemas. Brasília – DF.
SOMERVILLE, I., Engenharia de Software. Tradução de Maurício de An-

drade. Revisão técnica Prof. Dr. Kechi Hirama. 6. ed. São Paulo: Editora Afiliada,
2003.
FILHO, Antônio M S. Análise da Arquitetura de Software: Essencial para Ar-

quitetura de Software. Revista: Engenharia de Software Magazine página 50 a
56.
MENDES, A. Arquitetura de Software, Desenvolvimento orientado para ar-

quitetura, 1. ed.: Editora Campus, 2002.
NAKAGAWA, Elisa Y, apud GARCÈS, Lina. Avaliação Arquitetural. 2019.
SHAW, D. Garlan. Por trás de um aplicativo ou sistema há uma estrutura

desenvolvida pelo arquiteto de software. 2019.
26
PROCESSO ÁGIL DE DESENVOLVIMENTO DE SOFTWARE
(SCRUM)
1
NOSSA HISTÓRIA



2
Sumário
INTRODUÇÃO ................................................................................................... 4
O QUE É O DESENVOLVIMENTO ÁGIL ........................................................... 7
CONTEXTO HISTÓRICO................................................................................... 9
PREMISSAS DO DESENVOLVIMENTO ÁGIL ................................................ 11
COMO O DESENVOLVIMENTO ÁGIL FUNCIONA ......................................... 12
BENEFÍCIOS DO DESENVOLVIMENTO ÁGIL ............................................... 13
OS VALORES DO DESENVOLVIMENTO ÁGIL .............................................. 15
SCRUM ............................................................................................................ 17
PROPOSTAS DO SCRUM............................................................................... 20
PAPEIS DE ATUAÇÃO DA METODOLOGIA SCRUM .................................... 21
EVENTOS POSSÍVEIS EM SCRUM................................................................ 23
ARTEFATOS DO SCRUM ............................................................................... 25
CONSIDERAÇÕES FINAIS ............................................................................. 27
REFERÊNCIAS ................................................................................................ 28
3
INTRODUÇÃO
Desenvolver software é uma atividade difícil e arriscada. Segundo as estatísti-

cas, entre os maiores riscos estão: gastos que superam o orçamento, consumo
de tempo que supera o cronograma, funcionalidades que não resolvem os pro-
blemas dos usuários, baixa qualidade dos sistemas desenvolvidos e cancela-
mento do projeto por inviabilidade.
Nas últimas décadas temos visto o surgimento de diversos modelos de proces-

sos ágeis. Alguns modelos tem certas características que os diferenciam dos
demais. Essas características serão vistas neste artigo. Cada modelo de proces-
sos possui suas características, mas é importante saber que todos os modelos
estão em conformidade com o Manifesto Ágil.
Esses modelos de processos são mundialmente utilizados e podem dar boas

dicas ao leitor sobre quais modelos podem ser mais adequados ao seu contexto.
É sempre importante ressalvar que muitas vezes o melhor processo para o nosso
ambiente empresarial é uma mescla de vários modelos de processo ou então
um processo específico. Devemos sempre analisar as nossas necessidades e
verificar quais modelos melhor se adequam ao nosso contexto.
No desenvolvimento ágil os envolvidos no desenvolvimento são tratados como

trabalhadores do conhecimento e conseqüentemente são estimulados a apren-
der durante o desenrolar do próprio trabalho e tomar decisões melhores com
base neste aprendizado. Não existe um processo rígido que impõe o que pode
ou não ser feito e desestimula a criatividade.
No desenvolvimento tradicional, os especialistas do negócio conversam com os

analistas, que digerem, abstraem e passam as informações mastigadas aos pro-
gramadores, que não pensam nada além do necessário para escrever o código
do software.
4
O desenvolvimento ágil sabe que trabalhadores do conhecimento rendem mais
e melhor em ambientes que estimulam o uso intensivo da criatividade e do co-
nhecimento.
Escrever softwares é um trabalho tão ou mais criativo que escrever um livro, um

artigo ou uma monografia. É uma atividade tipicamente intelectual, onde é muito
comum ocorrerem idas e vindas, já que o aprendizado adquirido com o seu de-
senrolar torna possível aos envolvidos perceberem maneiras cada vez melhores
de fazerem as coisas. Este tipo de trabalho – não linear – funciona muito melhor
de forma iterativa e incremental (em espiral).
Considerando o cotidiano da maioria das organizações na atualidade, é inegável

a importância desempenhada por sistemas computacionais dos mais variados
tipos na condução de operações rotineiras. Esse suporte não apenas contribui
para uma maior eficácia na execução de atividades do dia a dia, como também
foi um fator determinante para um incremento substancial na produtividade de
diversos processos de negócio.
A evolução da área de sistemas foi acompanhada pelo surgimento de diversas

metodologias, com estas últimas normalmente englobando um conjunto de dire-
trizes e conceitos criados com o intuito de nortear o processo de construção de
um software. Como de praxe, não há uma fórmula mágica para se chegar ao
resultado final, ou seja, uma aplicação que atenda às expectativas dos usuários
e seja capaz de funcionar dentro de uma série de parâmetros considerados
como aceitáveis. Partindo de um conjunto de técnicas e diretrizes com eficácia
já comprovada, os profissionais envolvidos empreendem esforços no sentido de
adaptar um modelo para a realidade na qual se encontram inseridos.
É importante frisar sempre que desenvolver softwares não é uma tarefa das mais
simples. Uma ampla gama de variáveis influencia no modo como uma aplicação
será construída, somando-se ainda a isto influências como a pressão pela en-
trega do produto em um prazo muito curto, mudanças motivadas por alterações
na legislação vigente, dificuldades dos usuários que solicitam um sistema em
5
descrever de forma clara e concisa aquilo que realmente necessitam (com pro-
váveis pedidos de modificações ao longo do projeto), dentre outros aspectos.
A noção de mudança também representa um elemento central na elaboração de
aplicações. Por mais que todo um esforço procurando contemplar um número
extenso de situações seja levado a cabo, é praticamente impossível construir um
software que em determinado momento não precise passar por alterações. Aliás,
é bastante comum que exista a necessidade de modificações durante a constru-
ção da aplicação, comprometendo assim uma parcela do tempo e de recursos
que já haviam sido alocados para a implementação daquela solução.
Em um cenário de transformações constantes, a escolha pelo paradigma de de-

senvolvimento mais adequado a um determinado contexto é, sem sombra de
dúvidas, um fator crucial para o sucesso do projeto. As primeiras técnicas for-
mais voltadas à construção de sistemas possuíam um enfoque direcionado à
elaboração de soluções com uma estrutura mais rígida e, portanto, eram menos
suscetíveis a mudanças. A necessidade de uma rápida adaptação diante de si-
tuações imprevistas é um dos aspectos que caracteriza o mundo corporativo
atual; procurando atender a este tipo de demanda, surgiriam práticas mais flexí-
veis para a criação de aplicações, com diversas destas sendo conhecidas como
“metodologias ágeis”.
A imagem abaixo ilustra um diagrama de gerenciamento de projetos:
(Fonte: https://br.freepik.com/vetores-premium/infografico-de-processo-agil-scrum-diagrama-
de-gerenciamento-de-projetos-metodologia-de-projetos-e-ilustracao-do-fluxo-de-trabalho-da-
equipe-de-desenvolvimento_8637055.htm )
6
O QUE É O DESENVOLVIMENTO ÁGIL
O desenvolvimento ágil é um fruto da constatação feita, de forma independente,

por diversos profissionais renomados na área de engenharia de software, de
que, apesar de terem aprendido segundo a cartilha tradicional, só conseguiam
minimizar os riscos associados ao desenvolvimento de software, pensando e
agindo de forma muito diferente do que tradicionalmente está nos livros. Estes
profissionais, a maioria veteranos consultores para projetos de softwares, deci-
diram reunir-se no início de 2001 durante um workshop realizado em Snowbird,
Utah, EUA.
Embora cada envolvido tivesse suas próprias práticas e teorias preferidas, todos
concordavam que, em suas experiências prévias, os projetos de sucesso tinham
em comum um pequeno conjunto de princípios. Com base nisso eles criaram
o Manifesto para o Desenvolvimento Ágil de Software, frequentemente chamado
apenas de Manifesto Ágil. O termo Desenvolvimento Ágil identifica metodologias
de desenvolvimento que adotam os princípios do manifesto ágil. Estes princípios
são os seguintes:
 Indivíduos e interação entre eles mais que processos e ferramentas;

 Software em funcionamento mais que documentação abrangente;
 Colaboração com o cliente mais que negociação de contratos;
 Responder a mudanças mais que seguir um plano.
O manifesto reconhece o valor dos itens à direita, mas diz que devemos valorizar
bem mais os itens à esquerda.
No desenvolvimento ágil, os projetos adotam o modelo iterativo e em espiral

momo mostra a figura abaixo. Neste processo, todas as fases descritas no mo-
delo em cascata são executadas diversas vezes ao longo do projeto, produzindo
ciclos curtos que se repetem ao longo de todo o desenvolvimento, sendo que,
7
ao final de cada ciclo, sempre se tem um software funcional, testado e aprovado.
Os ciclos são chamados de iterações e crescem em número de funcionalidades
a cada repetição, sendo que, no último ciclo, todas as funcionalidades desejadas
estarão implementadas, testadas e aprovadas.
(Fonte: https://www.devmedia.com.br/introducao-ao-desenvolvimento-agil/5916 )
8
CONTEXTO HISTÓRICO
O desenvolvimento ágil é, acima de tudo, uma mentalidade, um conjunto de con-

ceitos que são colocados em prática graças a certas metodologias de gestão de
processos.
Várias dessas metodologias, porém, já existiam antes de o termo desenvolvi-

mento ágil se tornar popular.
Alguns exemplos são DSDM, Scrum, Crystal Clear, XP, UP e FDD, todas desen-
volvidas ao longo dos anos 1990.
Apesar da existência desses métodos, que levavam a resultados bastante satis-

fatórios, havia uma cartilha de práticas tradicionais que muitas empresas de tec-
nologia ainda seguiam.
Foi quando um grupo de desenvolvedores que já haviam experimentado os be-

nefícios do modelo ágil de gerir os processos debateram o assunto em um
workshop realizado na cidade de Snowbird, no estado americano de Utah.
Dessa ocasião nasceu o Manifesto para o Desenvolvimento Ágil de Software,

também conhecido apenas como Manifesto Ágil.
A metodologia ágil não surgiu como um movimento espontâneo. Na verdade,

sua criação foi pensada de maneira meticulosa, em uma resposta às necessida-
des dos desenvolvedores de software.
Na década de 1990, quando aconteceu o primeiro boom da Internet, o desen-

volvimento de softwares era baseado no modelo “waterfall” ou cascata. Ou seja,
de maneira linear, com a conclusão de uma etapa do projeto levando à próxima.
9
A metodologia funcionava com uma cadeia de eventos normalmente inflexível e
resistente à mudanças. E se você conhece o meio de desenvolvimento de sof-
twares, sabe que mudanças e otimizações são parte do ciclo de criação do pro-
duto.
Essa é uma das diretrizes de um movimento relacionado, inclusive, o Business

Agility – um conceito evoluído da metodologia ágil, voltada para o core business
da empresa.
Tudo isso culminou em um ambiente de trabalho sufocante e extremamente exi-

gente. Porém, esse cenário mudou no novo milênio.
No começo de 2001, um grupo de 17 desenvolvedores reconhecidos se juntou

em Utah, nos EUA, para discutir maneiras de desenvolvimento mais leves com
base em suas experiências. Eles assinaram um documento chamado “Manifesto
para o Desenvolvimento Ágil de Software”.
10
PREMISSAS DO DESENVOLVIMENTO ÁGIL
O cliente aprende ao longo do desenvolvimento, à medida que é capaz de ma-

nipular o sistema.
Um dos problemas mais complexos que afetam o desenvolvimento de software

é a enorme quantidade de detalhes que precisam ser considerados. Normal-
mente, ao especificar um sistema, o cliente tem o conhecimento de alguns as-
pectos do software que deseja.
Entretanto, muitos outros só ficam claros quando ele tem a oportunidade de uti-
lizar o sistema. Portanto, o cliente não especifica estes detalhes no início do
projeto por uma razão muito simples: ele não os conhece. Além do mais, mesmo
que tais detalhes fossem conhecidos previamente, seria muito difícil especificá-
los através de documentos, devido à grande quantidade de elementos que pre-
cisariam ser descritos.
Perceber que o cliente aprende ao longo do desenvolvimento é a chave para se

compreender o grande desafio existente no desenvolvimento de software. O cli-
ente aprende à medida que tem acesso ao sistema e se envolve em discussões
sobre ele. Este aprendizado pode ser utilizado para realimentar o processo de
desenvolvimento ou pode ser ignorado. Esta última alternativa é o caminho ado-
tado normalmente no desenvolvimento tradicional, pois ele parte da premissa
que o cliente já sabe o que quer no início do projeto e a ele cabe apenas descre-
ver os requisitos. Depois, ao final, ele receberá o sistema e não haverá ciclos de
realimentação entre a especificação e a entrega do sistema.
11
COMO O DESENVOLVIMENTO ÁGIL FUNCIONA
E na prática, como transcorre o trabalho dos profissionais que seguem o desen-

volvimento ágil de softwares?
Não existe uma fórmula, um modelo de trabalho fechado, uma sequência de

processos que o profissional deve seguir.
O Manifesto Ágil traz apenas valores e princípios, portanto, é muito mais concei-
tual. O que acontece é que existem várias metodologias que ajudam a executar
esses conceitos – muitas delas surgidas antes do manifesto, conforme explica-
mos antes.
Também são criados frameworks para tornar mais ágil o desenvolvimento,

unindo sistemas, componentes, ferramentas e guias que podem ser utilizados
em diversos projetos. As especificidades do modelo de gestão de projetos esco-
lhidos podem variar bastante.
O importante é não deixar de seguir os valores e princípios do Manifesto Ágil,

criando equipes multidisciplinares, ciclos em espiral e dando autonomia aos ti-
mes de trabalho.
12
BENEFÍCIOS DO DESENVOLVIMENTO ÁGIL
Pelo que acabamos de falar, os erros constatados no desenvolvimento ágil são

corrigidos organicamente, dentro do andamento natural do projeto.
Por isso, a palavra “ágil”.
Já nas metodologias tradicionais, o retrabalho gera uma nova cascata de etapas,

tornando o projeto muito mais longo e custoso do que poderia ser.
Portanto, o primeiro benefício do desenvolvimento ágil de softwares é que ele

demora menos tempo para ser realizado e consome menos recursos.Afinal, é
uma abordagem mais flexível, outro ponto positivo desse modelo.
A flexibilidade torna mais fácil a mudança de rumos de um projeto, que pode ser
motivada por inúmeros outros motivos além de erros.
Na etapa de testes de determinado ciclo, por exemplo, é possível obter insights

e informações novas, algo que não se tinha antes. Também podem acontecer
eventos externos inesperados, relacionados ao público consumidor, à concor-
rência, ao lançamento de uma tecnologia disruptiva, etc.
Se há flexibilidade no desenvolvimento, é possível adequar o trabalho em anda-

mento à nova realidade que se apresenta.
O desenvolvimento ágil tem ainda a grande vantagem de melhorar o relaciona-

mento e a comunicação entre os profissionais. Afinal, são quebrados os silos
organizacionais (rivalidade e falta de colaboração entre os setores) graças à for-
mação de equipes multidisciplinares. Além disso, essas equipes têm maior au-
tonomia, o que aumenta sua satisfação, motivação, engajamento e produtivi-
dade.
13
Por fim, o cliente fica mais satisfeito com o atendimento, já que o desenvolvi-
mento ágil foca o tempo todo em atender suas necessidades.
14
OS VALORES DO DESENVOLVIMENTO ÁGIL
Antes de compreender os princípios da metodologia ágil de desenvolvimento de

software, é indispensável conhecer os 4 valores que norteiam as suas ações.
Os conceitos fazem parte do Manifesto Ágil, que consiste na declaração dos

fundamentos que constituem todo o conceito de desenvolvimento ágil de sof-
tware.
Para que o método realmente seja eficiente, ele precisa priorizar:
Indivíduos e interações mais que processos e ferramentas
No desenvolvimento ágil, o engajamento e a integração entre os envolvidos e

interessados na criação do software é o foco principal, independentemente de
suas ferramentas de comunicação ou processos de operacionalização.
Software em funcionamento mais que documentação abrangente
Por mais que a documentação de um sistema seja importante e não deva ser
ignorada, ela não deve ser mais relevante do que as atividades voltadas para a
garantia de seu funcionamento. Afinal, esse é o principal valor esperado pelos
clientes.
Colaboração com o cliente mais que negociação de contratos
No desenvolvimento ágil de software, clientes e desenvolvedores devem estar

engajados nos mesmos objetivos. Isso significa que as negociações precisam
ser pautadas em uma relação de parceria e colaboração, não simplesmente em
um conjunto de interesses contratuais.
15
Responder a mudanças mais que seguir um plano
A metodologia ágil é uma tendência de desenvolvimento de software que surgiu

justamente como resposta às constantes transformações das tecnologias e das
incertezas que elas geram.
Por conta disso, ao invés de um planejamento extenso, detalhado e inflexível, a

ideia é que os profissionais estejam sempre prontos e dispostos a adaptar os
detalhes do projeto de maneira imediata, sempre que necessário.
Agora que você conhece os valores que guiam o desenvolvimento ágil de sof-
tware, no próximo item, veja as principais características dos seus 12 princípios
fundamentais.
16
SCRUM
O Scrum tem este nome devido a uma atividade que ocorre durante uma partida
de rugby, esporte muito popular nos Estados Unidos e evoluindo bastante no
Brasil com times profissionais surgindo a cada dia. Scrum é um método de de-
senvolvimento ágil de software criado por Jeff Sutherland e a sua equipe de de-
senvolvimento de software.
O método foi criado no início dos anos 90 e recentemente ganhou incrementos

nos métodos gráficos através de Schwaber e Beedle. Assim como os demais
modelos de desenvolvimento ágil o Scrum possui princípios consistentes com o
manifesto ágil.
O Scrum é indicado para projetos com prazos apertados, requisitos que estão
sempre sendo modificados e que são críticos para o negócio. Este método define
um conjunto de ações de desenvolvimento, são eles: o Backlog que é onde re-
gistra-se todo o trabalho pendente (requisitos ou funcionalidades) organizando-
os por prioridades.
Ressalta-se que novas funcionalidades podem ser adicionadas a esse Backlog

a qualquer momento introduzindo as alterações do usuário. Porém, o gerente do
produto deve avaliar esta funcionalidade e atualizar as prioridades.
Temos também como uma ação do Scrum as Sprints que são algumas funcio-
nalidades do Backlog que podem ser atendidas num prazo curto, de no máximo
30 dias. É nas Sprints que o trabalho de desenvolvimento realmente será reali-
zado para entregar o mais rápido possível um incremento de software operacio-
nal ao cliente.
Quando as Sprints já estão ocorrendo não devemos fazer alterações e possíveis

modificações devem ser realizadas nas próximas Sprints.
17
Outra ação do Scrum são as Reuniões que tipicamente são curtas (15 minutos)
e realizadas diariamente pela equipe Scrum. Nesta reunião diária são feitas três
perguntas bastante pontuais para todos os membros da equipe: "O que você
realizou desde a última reunião da equipe?", "Quais obstáculos estão encon-
trando?" e "O que planeja realizar até a próxima reunião da equipe?".
Estas perguntas ajudam todos a entenderem o que cada um fez no dia anterior,
se tem alguma dificuldade para realizar o trabalho atual e o que se pretende
fazer hoje. Esta reunião é considerada muito importante porque ajuda a equipe
a revelar problemas o mais cedo possível, também ajuda a disseminar o conhe-
cimento.
Uma dica importante é que nem todas as equipes acham a reunião diária apro-
priada para ser feita na parte da manhã, isto porque alguns membros começam
a trabalhar no turno da tarde ou porque as pessoas não possuem um humor
muito bom pela manhã, tente avaliar essas questões e decida o melhor mo-
mento.
No Scrum também temos um líder de equipe que é chamado de Scrum Master.

Ele é responsável por conduzir a reunião diária e avaliar as respostas dos inte-
grantes. O objetivo do Scrum Master também é remover obstáculos.
Por fim, o SCRUM também trabalha com a ideia de entrega de incrementos de

software ao cliente, ou Demos. Essa funcionalidade permite ao cliente avaliar e
dar feedbacks para a equipe.
Como as Demos são realizadas durante os incrementos, pode ser que não te-
nhamos toda a funcionalidade completa, mas teremos funções que possam ser
entregues dentro do prazo acertado com o cliente.
Muito popular no Brasil, este método de desenvolvimento ágil se concentra prin-

cipalmente no gerenciamento de tarefas dentro de um ambiente de desenvolvi-
mento baseado em time.
18
Ele é relativamente simples de implementar e aborda muitos dos aspectos com-
plexos de gestão que costumam representar dor de cabeça para os times de
desenvolvimento.
Em suma, podemos dizer que o uso de Scrum impõe uma certa disciplina, que
permite um acompanhamento mais próximo do andamento do projeto. Suas en-
tregas podem ser até semanais, entregando valor mais rápido.
19
PROPOSTAS DO SCRUM
Assim como outros métodos com um enfoque similar, a proposta do Scrum é

fornecer subsídios para o gerenciamento de atividades muitas vezes complexas,
porém de uma forma flexível e que facilite a adaptação do projeto diante das
inevitáveis mudanças. São três as ideias principais em que a metodologia Scrum
se ampara:
 Transparência;
 Inspeção;
 Adaptação.
A noção de transparência deve ser compreendida como a existência de um con-

senso mútuo entre todos os participantes de um projeto, considerando para isto
termos específicos de negócio, regras que caracterizam processos e outros as-
pectos. Inclusive o significado de "pronto", algo tão controverso em projetos de
software que apresentam deficiências, está contemplado dentro do conceito de
transparência.
Outro ponto importante da metodologia Scrum é a atividade de inspeção. A ve-

rificação contínua do que é produzido é fator determinante para que se tenha a
certeza de que o projeto caminha dentro do estipulado, bem como para diagnos-
ticar desvios indesejáveis e atuar de forma corretiva sobre estes últimos.
Já o conceito de adaptação vai de encontro a um dos principais objetivos dos

métodos ágeis: a flexibilidade diante de mudanças. Não serão raras as ocasiões
em que alterações em demandas de clientes ou ainda, regulamentações gover-
namentais e de ordem setorial, acarretarão desvios de rotas preestabelecidas.
Diante disto, ajustes se fazem necessários, atenuando desse modo outros efei-
tos indesejáveis em momentos posteriores.
20
PAPEIS DE ATUAÇÃO DA METODOLOGIA SCRUM
Um conjunto de papéis bem definidos determina, através de atribuições, como

será a atuação dos diversos profissionais que participarão de um projeto base-
ado na metodologia Scrum:
 Product Owner: representante da área cliente/solicitante;
 Scrum Master: o líder que gerenciará o projeto;

 Equipe de Desenvolvimento/Time: os profissionais responsáveis pela cri-
ação do produto esperado.
O Product Owner é o ponto que centraliza a interação com a área/grupo de usu-

ários que solicitou a execução de um projeto. A partir do mesmo são definidas
prioridades, o que deverá ou não ser implementado e a validação dos diferentes
resultados ao longo do processo de desenvolvimento.
Já o Scrum Master corresponde ao papel do Gerente de Projetos tradicional.

Além de ser um facilitador removendo impedimentos e um mediador em prová-
veis conflitos, este profissional garante que a equipe sob sua supervisão siga de
maneira adequada as práticas de Scrum.
Por fim a Equipe de Desenvolvimento (ou Time) elabora estimativas, estipula

tarefas, implementa o produto dentro de níveis de qualidade preestipulados e
cuida da apresentação do mesmo ao cliente/solicitante. Conforme já mencio-
nado anteriormente, espera-se que tal equipe conte com um caráter auto geren-
ciável, com o comprometimento e uma postura multifuncional dos membros re-
presentando um fator crucial para o sucesso do projeto.
21
Além dos três papéis já descritos, certamente também existirão envolvidos com
o projeto, mas que não desempenham um papel direto na sua execução. Estes
elementos podem englobar usuários, gerentes, diretores ou departamentos que
possuem interesses (neste caso são conhecidos dentro da Gerência de Projetos
como “stakeholders”) ou ainda, são afetados pelos resultados do produto final.
Considerando tudo isto, criou-se uma forma lúdica de representar o grau de com-
prometimento de uma pessoa em um projeto que segue as práticas do Scrum;
para isto, foi utilizada uma sequência de histórias em que interagem um porco e
um frango. Porcos representariam profissionais realmente engajados/compro-
metidos com o sucesso do projeto (Product Owner, Scrum Master, Time), ao
passo que frangos seriam pessoas relacionadas indiretamente e sem uma maior
disposição para com o mesmo (usuários comuns, gerentes ou áreas afetadas).
22
EVENTOS POSSÍVEIS EM SCRUM
Como outros métodos ágeis, Scrum é uma metodologia que prima pelo desen-
volvimento iterativo e incremental de software. Em termos práticos, isto significa
que ciclos contendo um conjunto de específico de atividades são repetidos con-
tinuamente ao longo de um projeto; por incremental, deve-se ter em mente a
ideia de sucessivas entregas de funcionalidade, acrescentando aquilo que se
espera do software em intervalos constantes de tempo.
Antes de prosseguir com a descrição dos diferentes eventos de Scrum, faz-se

necessário conceituar as idéias de Time-Box e Sprint. Uma Time-Box nada mais
é do que a quantidade de tempo estipulado para a realização de uma iteração.
Esta última recebe o nome de Sprint, sendo que essa estimativa de tempo não
pode ser alterada, a fim de com isto garantir a entrega sem atrasos e facilitar o
planejamento.
Diante da possibilidade de erros na estimativa, deve-se proceder com uma re-

dução do escopo, sem contudo afetar substancialmente as metas da Sprint ou
obrigar a um aumento na quantidade de horas ou dias planejados. O comum é
que uma Sprint dure de duas a quatro semanas.
A partir destas explanações, são possíveis dentro de Scrum os seguintes even-

tos:
1. Reunião de Planejamento da Sprint;

2. Reunião Diária;
3. Revisão da Sprint;
4. Retrospectiva da Sprint.
23
A Reunião de Planejamento da Sprint é uma atividade com duração de 8 horas
e da qual participam todos os profissionais comprometidos com o projeto (Pro-
duct Owner, Scrum Master, Equipe de Desenvolvimento). Esta reunião é for-
mada por duas etapas: num primeiro momento o Product Owner define a priori-
dade de funcionalidades a serem implementadas (a partir do Backlog); posteri-
ormente, a Equipe montará sua própria lista de trabalho (Sprint Backlog) com
base no que foi exposto pelo Product Owner.
Já a Reunião Diária é uma curta sessão de 15 minutos, em que membros da

Equipe e o Scrum Master comentam a situação atual (muitas vezes em pé dentro
de um recinto). Isto normalmente envolve uma rápida explanação do que foi feito
no dia anterior, o que será realizado na data atual e uma discussão de prováveis
impedimentos que foram encontrados.
A Revisão da Sprint é uma reunião de normalmente 4 horas, em que estão pre-

sentes o Product Owner, o Scrum Master e a Equipe (pode acontecer ainda de
outras pessoas serem convidadas para participar). As atividades desempenha-
das durante a Sprint são apresentadas, procedendo-se com a entrega do sof-
tware funcionando (conforme pregado pela metodologia).
Por fim, há ainda a Retrospectiva da Sprint. Trata-se de uma reunião de geral-

mente 3 horas entre Equipe e Scrum Master. Nesta discussão aborda-se o que
deu certo e aquilo que falhou, além de se estudarem formas para se melhorar
num próximo ciclo (Sprint).
24
ARTEFATOS DO SCRUM
Por mais que como uma metodologia ágil Scrum priorize a entrega do software
em detrimento de uma extensa e trabalhosa documentação, a elaboração e a
consequente manipulação de alguns artefatos neste modelo é de fundamental
importância para o controle das atividades rotineiras. A seguir estão listados tais
documentos:
 Backlog do Produto (ou em inglês “Product Backlog”);

 User Story;
 Sprint Backlog;
 Gráfico de Burn Down.
O Product Backlog é uma listagem que contempla todas as funcionalidades de-

sejadas para o software que se está implementando. Além disso, as informações
contidas neste tipo de controle podem conter ainda uma ordem de prioridade,
sendo incumbência do Product Owner criar e controlar o status dos diferentes
elementos do Backlog.
Uma User History é uma pequena história que descreve as características espe-
radas para uma funcionalidade constante no Backlog do Produto. Constam no
documento que representa tal história um título, uma descrição clara do que se
necessita, bem como é possível se indicar ainda uma prioridade para execução
da tarefa.
A Sprint Backlog é uma relação de tarefas elaborada pelo Time de Desenvolvi-

mento durante a segunda etapa da Reunião de Planejamento da Sprint. Trata-
se de algo que está em conformidade com o conceito de equipes autogerenciá-
veis, uma vez que os profissionais responsáveis por isto planejam como será o
dia a dia de desenvolvimento a partir das prioridades apontadas pelo Product
Owner.
25
O Gráfico de Burn Down é uma ferramenta de gerenciamento. Este artefato cos-
tuma ser atualizado diariamente, servindo de base para a comparação entre o
que foi planejado e aquilo que realmente se realizou. Pode ser considerado um
instrumento para tomada de decisão, uma vez que fornece embasamento para
ações em prol de uma maior produtividade ou ainda, a fim de atenuar riscos
iminentes.
26
O desenvolvimento ágil é amplamente conhecido em empresas e departamentos

de TI, mas muitas metodologias podem ser aplicadas em várias outras áreas.
É necessário, porém, fazer uma distinção: o desenvolvimento de softwares é

uma atividade do conhecimento, intelectual, e não um trabalho manual e opera-
cional. Isso faz toda a diferença, pois estamos falando de trabalhos em que há
muita subjetividade – muitas vezes, não há certo ou errado, apenas suposições.
Claro que os códigos em si podem ser bastante objetivos, mas estamos falando
aqui do desejo do cliente e da interpretação que os desenvolvedores têm disso.
Por isso, ao considerar implementar as práticas de desenvolvimento ágil, pense
no quão criativo e suscetível a erros será o trabalho da sua equipe.
As metodologias ágeis tornam os projetos mais flexíveis, diminuindo os riscos

por haver testes e homologações o tempo todo.
Mudanças são algo praticamente certo durante a construção de uma aplicação

de software. O grande dinamismo do mundo atual força as organizações a se
adequarem de maneira rápida a transformações repentinas, a fim de com isto
assegurar a continuidade da operação das mesmas dentro do mercado em que
estão inseridas. A possibilidade de alterações nas “regras do jogo” a qualquer
instante foram os grandes motivadores para o surgimento das metodologias
ágeis.
Scrum é mais um método ágil, representando uma alternativa flexível para ori-
entar equipes na entrega de sistemas com qualidade. Diversas ferramentas de
software (gratuitas ou proprietárias) já foram desenvolvidas, auxiliando assim o
dia a dia de profissionais envolvidos em projetos que adotaram esta metodologia.
27
REFERÊNCIAS
GROFFE, Renato. Desenvolvimento ágil com Scrum: uma visão geral. 2012.
ALVES, Bruno P. Proposta de Processo Ágil de Desenvolvimento de Sof-

tware em uma Instituição de Educação Pública. São Paulo, SP – Brasil. 2016.
CASTRO, Vinicius. Introdução ao Desenvolvimento Ágil. 2017
MEDEIROS, Higor. Modelos de Processos Ágeis: conceitos e princípios.

2016.
DUARTE, Luiz. O que é Scrum? 2021.
PATELL, Nel. Metodologia Ágil: Entenda O Que É e Quais São As 8 Mais

Utilizadas.
28
ARQUITETURA ORIENTADA E SERVIÇOS E MICROSSERVIÇOS,
COMPUTAÇÃO EM NUVEM E MOBILE
1
NOSSA HISTÓRIA



2
Sumário
INTRODUÇÃO ................................................................................................... 4
O QUE É SOA? .................................................................................................. 6
ARQUITETURA ORIENTADA A SERVIÇOS (SOA) PARA AUTOMAÇÃO

INDUSTRIAL ...................................................................................................... 8
O QUE É ARQUITETURA DE MICROS SERVIÇOS? ..................................... 11
PRINCÍPIOS DOS MICROS SERVIÇOS ......................................................... 13
BENEFICIOS DE MICROSSERVIÇOS ............................................................ 15
TECNOLOGIA POLIGLOTA............................................................................. 16
MONITORAMENTO DE SERVIÇOS ................................................................ 17
COMPUTAÇÃO EM NUVEM E MOBILE ......................................................... 19
CONCLUSÃO................................................................................................... 24
REFERÊNCIAS ................................................................................................ 25
3
INTRODUÇÃO
Quando estamos lidando com aplicações a nível empresarial, é muito comum

ouvirmos sobre uns tais de Serviços SOA. É comum até mesmo ouvirmos os
termos “barramento SOA” ou “fachada SOA”.
E tudo isso dentro do que geralmente chamam de “arquitetura SOA”. Mas, o que
é tudo isso? Será que estamos falando simplesmente de web services?
Conforme as tecnologias e práticas de negócios em torno de BPM, SOA e Web

2.0 vão amadurecendo, cada vez mais organizações as adotam, tanto individual
quanto coletivamente.
Como resultado, mudanças fundamentais surgiram na maneira como as partes

envolvidas de TI e negócios trabalham juntas.
Embora as oportunidades que isso apresenta sejam enormes, os riscos são

equivalentes: segurança, ineficiência, interrupções e um possível desalinha-
mento organizacional.
Para ajudá-lo em sua avaliação dessas tecnologias e dos benefícios que elas
oferecem (inclusive para iniciativas executivas como Lean-Six Sigma, gerência
de portfólio e transformação da aquisição, bem como soluções com foco em mis-
sões em áreas como inteligência, defesa e logística), este white paper avalia os
benefícios e os riscos dessas soluções e apresenta perspectivas e estudos de
caso do mundo real como elementos de base para sua análise.
Os desafios enfrentados pelas empresas e órgãos governamentais da atualidade

são muitos e variados.
Para se mantiver atualizadas, essas organizações precisam não só promover

uma mudança de dentro, mas também ser suficientemente ágeis para se adap-
4
tarem rapidamente à evolução dos mercados, políticas, regulamentações e mo-
delos de negócios. Felizmente para elas, a convergência de um trio de tecnolo-
gias e práticas de negócios – gestão de processos de negócios (BPM), arquite-
tura orientada a serviços (SOA) e Web 2.0 – está fornecendo uma solução.
5
O QUE É SOA?
Arquitetura Orientada a Serviços é uma solução fundamentada onde geralmente

possui uma arquitetura baseada em padrões para a criação de uma infraestru-
tura de TI, visando simplificar as relações entre sistemas distintos, aperfeiçoando
seu funcionamento e facilitando a incorporação de novos elementos.
Sendo assim, caso haja mudanças nas necessidades do negócio, estes fatores
permitem que a empresa responda a isso de forma rápida.
Essa exposição de regras de negócio é realizada basicamente através dos fa-

mosos web services, pois são eles que determinam os padrões e acabam espe-
cificando essa infraestrutura de TI que foi citada.
A vantagem de termos essa estrutura em uma organização é justamente a flexi-

bilidade que os web services trazem.
Esse é exatamente o cenário perfeito para a utilização da arquitetura SOA, pois

temos ativos de negócio envolvidos em um ambiente completamente heterogê-
neo. E todo mundo precisa conversar entre si.
Pensando em uma arquitetura voltada a serviços, nós poderíamos resolver isso

de maneira muito fácil. Poderíamos criar uma web service chamado “IncluirCli-
ente”.
Esta web service será responsável por fazer todas as validações do cliente antes
de o inserir na base de dados. Assim, caberia aos demais softwares simples-
mente consumir esse serviço da maneira adequada.
6
Abaixo segue uma imagem de um esquema de regras de negocio
Fonte: https://www.treinaweb.com.br/blog/voce-sabe-o-que-e-arquitetura-orientada-a-servicos-soa
7
ARQUITETURA ORIENTADA A SERVIÇOS (SOA) PARA AUTO-
MAÇÃO INDUSTRIAL
Soluções baseadas em Ethernet Industrial permitem ao usuário a integração dos

equipamentos industriais a serviços de TI fornecidos por servidores (DECO-
TIGNIE, 2005). Dessa forma, tornou-se possível disponibilizar informações pro-
venientes dos sistemas de automação através de protocolos com suporte ao
Ethernet TCP/IP em aplicações Web.
Essa interconexão de dados e infraestruturas de rede de TI e de automação de

forma segura e confiável representa uma tendência para o desenvolvimento de
soluções inovadoras e integradoras na área industrial com a IIoT e a Indústria
4.0 (LU, 2017).
Processos industriais, bem como muitas outras infraestruturas críticas depen-

dem de sistemas SCADA e SDCD para executar suas funcionalidades comple-
xas. A IIoT é complementar a esses sistemas, utilizando as informações prove-
nientes dos sistemas SCADA e SDCD como fontes de dados. Sistemas SCADA
tem foco em monitoramento e controle, enquanto a IIoT busca analisar os dados
para aumentar a produtividade e eficiência (KULKARNI, 2016).
Colombo et al. (2014) discutem o conceito de uma arquitetura de automação

baseada no uso da Computação em Nuvem e de serviços (Web Services) para
comunicação e realização das tarefas entre os diferentes componentes e equi-
pamentos de um sistema industrial. Os autores atestam que arquiteturas orien-
tadas a serviço (SOA) são consideradas um caminho promissor para concepção
do modelo de fábrica do futuro.
8
No entanto, existe a necessidade e potencial para melhorar as funcionalidades
e minimizar problemas de integração através de abordagens colaborativas de
sistemas e serviços (COLOMBO et al., 2014). Nesse sentido é importante con-
siderar os próximos passos para a evolução dos sistemas industriais através da
IIoT e Industria 4.0, de forma que consigam atender os desafios recentes como
grau de descentralização e independência dos sistemas.
Nesse sentido, a proposta de arquiteturas SOA possui grande potencial, a partir

da disponibilização de serviços em nuvem alocados em diferentes dispositivos,
gateways ou sistemas, os quais facilitam e padronizam as interações entre eles.
Leitão et al. (2016) apresentam um estudo sobre novas arquiteturas SOA para
aplicações industriais.
Agora as coisas ficaram muito mais simples. Conseguimos centralizar o nosso

ativo de negócio (no caso, o cliente e a sua inserção), garantindo que o fluxo de
negócio dele sempre ocorra da maneira correta (temos certeza que o cliente
sempre vai ser validado da maneira correta).
Por fim, garantimos extensibilidade pois, se quisermos um dia alterar a regra de

negócio de validação do cliente ou mesmo acrescentar novas etapas do negócio,
basta modificarmos o web service.
Todos os softwares que consomem este web service serão automaticamente

“atualizados”. Esta é a arquitetura SOA!
9
A Imagem abaixo é uma pirâmide de negócios
Fonte: (https://www.google.com/url?sa=i&url=https%3A%2F%2Fwww.profissio-
naisti.com.br%2Fbeneficios-de-uma-arquitetura-orientada-a-servico-soa-para-o-negocio-parte-
1%2F&psig=AOvVaw2E_AyXpsFCEdTroVjb_kLD&ust=1626437167803000&source=ima-
ges&cd=vfe&ved=0CAcQjRxqFwoTCMjDodSD5fECFQAAAAAdAAAAABAD)
10
O QUE É ARQUITETURA DE MICROS SERVIÇOS?
Os micros serviços são uma arquitetura e uma abordagem para escrever pro-
gramas de software. Com eles, as aplicações são desmembradas em compo-
nentes mínimos e independentes.
Diferentemente da abordagem tradicional monolítica em que toda a aplicação é

criada como um único bloco, os micros serviços são componentes separados
que trabalham juntos para realizar as mesmas tarefas.
Cada um dos componentes ou processos é um microsserviço. Essa abordagem

de desenvolvimento de software valoriza a granularidade, a leveza e a capaci-
dade de compartilhar processos semelhantes entre várias aplicações.
Trata-se de um componente indispensável para a otimização do desenvolvi-

mento de aplicações para um modelo nativo em nuvem.
Micros serviços são uma abordagem de arquitetura para a criação de aplicações.

O que diferencia a arquitetura de micros serviços das abordagens monolíticas
tradicionais é como ela decompõe a aplicação por funções básicas.
Cada função é denominada um serviço e pode ser criada e implantada de ma-

neira independente. Isso significa que cada serviço individual pode funcionar ou
falhar sem comprometer os demais.
Portanto, um microsserviço é uma função essencial de uma aplicação e é exe-

cutado independentemente dos outros serviços.
No entanto, a arquitetura de micros serviços é mais complexa do que o mero

acoplamento flexível das funções essenciais de uma aplicação.
11
Trata-se da restruturação das equipes de desenvolvimento e da comunicação
entre serviços de modo a preparar a aplicação para falhas inevitáveis, escalabi-
lidade futura e integração de funcionalidades novas.
Micros serviços lidam com linguagens, plataformas e sistemas operacionais de

forma agnóstica.
Eles podem ser usados para quebrar uma grande aplicação monolítica em ser-
viços menores e mais simples.
Cada micro serviço faz uma coisa, e faz bem, então o “Micro” em micros serviços
refere-se ao escopo dos serviços funcionalidades, não o número de linhas de
código e nem do tamanho em megabytes do monólito.
Em resumo o conceito básico: ele é uma pequena aplicação que executa uma
única tarefa e o faz com eficiência.
Um micro serviço è um pequeno componente que pode ser facilmente substitu-

ído e é desenvolvido e implantado de forma independente.
Cada micros serviço é geralmente construído por uma equipe completa, que re-
duz possíveis dificuldades de comunicação entre equipes diferentes.
Os micros serviços podem não ser adequados para aplicações mais simples e
são mais adequados para aplicações complexas que crescem ao longo de um
período de tempo, com grandes bases de código e equipes.
São ideais para realizar múltiplas funções de negócios, com cada micros serviço
focado em realizar uma única função ou sub-função de negócios.
12
PRINCÍPIOS DOS MICROS SERVIÇOS
O comportamento e os padrões de uma arquitetura microservice e seis princí-

pios abaixo, também defendidos por Rag Dhiman
.
1. Alta Coesão
Um dos princípios da arquitetura de micros serviços é a alta coesão, o serviço

deve ter um único foco. Ou seja, ter uma única responsabilidade do domínio da
aplicação. Este princípio é útil para controlar o tamanho e impedir que o micros-
serviço se torne um serviço monolítico.
2. Autônomos
Um microserviço deve ser autônomo, ou seja, não deve depender de outros ser-
viços que interajam com ele. Isto implica na mudança de um microserviço dentro
de uma aplicação. Ele não deve forçar que outros microsserviços necessitem
mudar. O ponto importante desse princípio reflete que cada microserviço deve
ter seu próprio banco de dados ou outro serviço de armazenamento.
3. Resiliência
Não importa a velocidade e os custos das soluções, é importante construir siste-

mas que reajam a falhas inesperadas. Ser capaz de validar os dados recebidos
(mesmo que estes estejam corrompidos) e tratar a perda ou falha na comunica-
ção com outro serviço da cadeia, sem quebrar o fluxo da aplicação.
13
4. Observável
Poder acompanhar o status do sistema e conseguir observar o que está aconte-

cendo em tempo real. Esse tipo de monitoramento precisa ser centralizado para
facilitar a busca de informações sobre o status atual do sistema. Como micros-
serviços é uma arquitetura distribuída, a ideia de centralizar o monitoramento,
principalmente os logs, facilita verificação do ciclo completo de toda mensageria
trocada. Desde a primeira iteração do usuário até a solução entregue pela apli-
cação.
5. Automatização
Com a divisão de uma aplicação entre diversos mini blocos há uma necessidade
maior de automatizar algumas tarefas para manter este tipo de arquitetura.
Como integração contínua e entrega contínua. Esse é um dos aspectos que fa-
zem esse modelo ser abraçado por defensores da cultura DevOps. Pois esta é
a ideia principal que move essa cultura.
6. Centrado no domínio do negócio
Um microserviço deve estar focado no domínio do negócio. Assim sendo, deve

ser uma função do negócio. Quem conhece o padrão de desenvolvimento DDD
sabe que o domínio é o coração de uma aplicação. O conceito base que alicerça
este pensamento é o que no DDD chamamos de Bounded Context (ou contextos
delimitados).
Os contextos delimitados servem para refatorar um grande domínio em peque-

nos conjuntos de domínios que unidos representam o modelo de negócio de uma
aplicação. E é exatamente essa característica um dos pontos fundamentais no
modelo de micros serviços.
14
BENEFICIOS DE MICROSSERVIÇOS
Escala Independente
Cada microsserviço pode escalar independentemente via eixo X escalonamento

(clonagem com mais CPU ou memória) e eixo Z dimensionamento (fragmenta-
ção), com base no que é necessário. Isto é muito diferente das aplicações mo-
nolíticas, que podem ter requisitos muito diversos, mas ainda devem ser implan-
tados juntos como uma única unidade.
Atualizações Independentes
Cada serviço pode ser implantado independentemente de outros serviços. Qual-

quer alteração local em um serviço pode ser feita facilmente por um desenvolve-
dor sem exigir coordenação com outras equipes. Por exemplo, para atender ne-
gócios em constante mudança requisitos, um serviço pode ser melhorado subs-
tituindo a implementação anterior. Como resultado, isso melhora a agilidade do
microserviço. Este também é um ótimo facilitador de Integração Continua / En-
trega Continua.
Manutenção Fácil
O código em um microsserviço é restrito a um recurso e com isso mais fácil de

entender. IDEs podem carregar menores quantidades de código e com menos
código, aumenta a facilidade do desenvolvedor da manutenção.
15
TECNOLOGIA POLIGLOTA
Os desenvolvedores são livres para escolher a linguagem e a pilha tecnológica

mais adequada para construção do serviço. Eles são livres para inovar dentro
dos limites de seu serviço. Isso permite reescrever o serviço usando novas tec-
nologias, em vez de ter que manter decisões passadas, dando assim a liberdade
de escolha de tecnologias, ferramentas ou estruturas.
isolamento de falhas e recursos
Um serviço mal comportado como um “memory leak” ou uma falta de gerencia-

mento do pool de conexões de banco de dados pode afetar o serviço por com-
pleto, caso a aplicação tiver arquitetura monolítica. Com micros serviços bem
projetados, as falhas podem ser isoladas em um único serviço e não se propa-
gam para o resto do sistema, permitindo um isolamento de falhas que compro-
metem a aplicação por completo.
Melhor comunicação entre equipes
Um microsserviço é normalmente construído por uma equipe que domina a pilha

tecnológica por completo. Todos membros relacionados a um domínio trabalham
juntos em uma única equipe, o que melhora significativamente a comunicação
entre os membros da equipe, como eles compartilham os mesmos objetivos fi-
nais, entregam o serviço no ambiente de produção.
16
MONITORAMENTO DE SERVIÇOS
Um dos aspectos mais importantes de um sistema distribuído é o monitoramento

e registro de serviços. Isso permite que você tome ação proativa se, por exem-
plo, um serviço estiver consumindo recursos inesperados. Agregar logs de dife-
rentes micros serviços e fornecer uma visualização consistente. Fazer com que
os dados disponíveis para usuários corporativos.
Resiliência
Falha de software irá ocorrer, não importa o quanto se testa. Isto tão importante
quanto múltiplos micros serviços são distribuídos por toda a Internet. A questão
é “como evitar a falha”, mas “como lidar com falha”. “É importante que os serviços
tomem ação corretiva para garantir que a experiência do usuário não seja afe-
tada”
O padrão “Circuit Breaker” permite construir resiliência em software — o Hystrix

da Netflix é uma boa biblioteca que implementa esse padrão.
Devops
Integração Contínua e Implantação Contínua (IC / EC) são muito importantes

para que os micros serviços possam ter sucesso. Essas práticas são necessá-
rias para que os erros possam ser identificados, cedo por meio de testes auto-
matizados e pipelines de implantação.
17
A imagem abaixo mostra um tipo de micro serviço
18
COMPUTAÇÃO EM NUVEM E MOBILE
A computação em nuvem móvel, em sua forma mais básica, se refere a uma

infraestrutura em que tanto o armazenamento quanto o processamento de dados
acontecem fora do dispositivo móvel.
Os aplicativos levam o poder de computação e armazenagem de informa-

ções dos aparelhos para a nuvem.
O mobile cloud computing (MCC) traz um novo paradigma aos aplicativos mó-
veis, em que o processamento e o armazenamento de dados são movidos para
plataformas de computação poderosas e centralizadas.
Elas, por sua vez, são acessadas pela conexão sem fio, com base em um app
nativo ou navegador da Web.
Em suma, podemos dizer que o serviço oferece aos usuários, os serviços de

processamento e armazenamento de dados em nuvem.
Os dispositivos móveis não precisam de uma configuração alta — velocidade de

processamento e capacidade de memória — porque todos os complicados mó-
dulos de computação podem ser processados na cloud.
A computação em nuvem chegou para ficar. Vista no primeiro momento com

desconfiança pelos mais céticos, essa tecnologia mostrou-se capaz de agregar
diversos benefícios para as empresas, tais como redução de custos, escalabili-
dade e maior segurança.
Agora, um termo relativamente novo, que é Mobile Cloud Computing, está em

ascensão e despertando o interesse do mundo corporativo.
Quais os benefícios do mobile cloud?
19
Conheça agora algumas vantagens da utilização da computação em nuvem
móvel.
Melhor facilidade na criação de testes unitários, de aceitação, etc., uma vez que
os serviços são coesos;
Maior frequência de deploy, uma vez que os serviços podem ser implantados de
forma independente;
Liberdade de escolha de linguagem, frameworks e banco de dados que resolvem

de forma mais fácil a necessidade de cada microserviço.
Resiliência
O conceito de padrões de arquitetura escalável, flexível e de alta disponibilidade

concebida através de micro serviços é realidade e foi bem recebida pela indústria
e comunidade de desenvolvimento de Software. Impulsionada por suas caracte-
rísticas e paradigmas que resolvem através de seu âmbito conceitual problemas
complexos e/ou custosos que soluções monolíticas apresentam.
Literaturas tratam o padrão Microservicos como uma derivação do modelo de

Arquitetura Orientada a Serviço (SOA). É baseado em coleção de pequenos ser-
viços desacoplados que se comunicam através de protocolo leve.
Mesmo sendo amplamente utilizado devido a evolução dos sistemas atuais, a

filosofia por trás do conceito dos micros serviços e da arquitetura escalável não
é nova. Um artigo de 1978 focado no sistema UNIX expõe alguns dos pontos
principais que posteriormente foram utilizados para embasar este novo tipo de
desenvolvimento de sistemas.
Com a aplicação implementada através de vários microserviços e não um único

processo monolítico, o risco de indisponibilidade dessa aplicação é muito menor.
Cada instância de Microserviço é um processo distinto no sistema operacional
do Host deployado, isso porque, ou encontra-se em máquinas distintas, ou o que
20
comumente encontramos, são encapsulados em containers Docker, que por na-
tureza abrem processos distintos no sistema operacional.
Uma terceira possibilidade, é, sendo o ambiente Cloud, utilizar recursos serves

que também possuem isolamento entre as implementações.
Dentre vários padrões de implementação, um comumente utilizado é o circuit

breaker, que como um disjuntor de quadro de energia que desarma quando algo
está errado e previne maiores problemas, sua responsabilidade é transferir para
outra instância de serviço as requisições quando detecta algo de errado com um
Microserviço, prevenindo a parada de atendimento das requisições.
Aumento da produtividade
Devido as características de alta coesão já discutidas nesse artigo, aplicações

implementadas com os padrões de arquitetura em Microserviços permite a seg-
mentação do time em unidades de negócio específico, o que naturalmente eleva
a senioridade dos profissionais no segmento de negócio e consequentemente, o
aumento significativo na produtividade da correção de bugs e criação de novas
funcionalidades.
1. Flexibilidade
Com a mobile cloud é possível armazenar e recuperar dados de qualquer lugar

do mundo através de qualquer dispositivo, desde que conectado à internet. Isso
permite o acesso rápido e fácil de dados sempre que houver necessidade de
obter informações ou realizar alguma operação em aplicações que estejam hos-
pedadas na nuvem.
Como a maioria das empresas estão migrando suas aplicações de missão crí-
tica, como o SAP, por exemplo, como o uso da mobile cloud, qualquer colabora-
dor que possua acesso pode executar suas tarefas como se estivesse no escri-
tório a partir de qualquer lugar.
21
Nesse sentido, a mobile cloud ajuda na implementação da estratégia BYOD,
cada vez mais presente nas empresas modernas.
2. Suporte às múltiplas plataformas
Você pode usar a mobile cloud independentemente do sistema operacional de

seu dispositivo, porque a computação em nuvem suporta vários tipos diferentes
de plataformas para executar seus aplicativos.
3. Alta disponibilidade
A computação em nuvem ajuda as empresas a terem sua infraestrutura e siste-

mas de TI disponíveis quase que 100% do tempo. Com a mobile cloud você
consegue usufruir melhor da alta disponibilidade, uma vez que você pode aces-
sar seus dados quando desejar. Além disso, ainda tem a opção de salvar seus
dados e acessá-los, mesmo que off-line, sempre que necessário.
4. Eficiência de custos
Essa solução é muito econômica, pois o pagamento é baseado no uso. Ou seja,

você utiliza quando necessário e paga somente pelo que usar.
5. Backup de dados
Como você gera constantemente novos dados em seu dispositivo móvel, o apli-
cativo de mobile cloud pode realizar o backup na nuvem de forma automática.
Assim, garantindo a segurança das informações.
Dessa forma, caso aconteça roubo, furto ou avaria de seus dispositivos mó-
veis, seus dados estarão preservados.
22
6. Recuperação de dados
No caso de acontecer um desastre, você não precisa entrar em desespero. É

possível proceder com a recuperação de seus dados também nos seus disposi-
tivos móveis.
Para isso, você deve seguir alguns procedimentos específicos, que podem ser
realizados de qualquer local. Para isso, basta estar conectado à internet e ter
espaço de armazenamento suficiente no seu dispositivo.
Agora você já sabe mais sobre a mobile cloud e seus benefícios. Vale ressaltar
que para garantir a segurança dos seus dados é necessário adotar procedimen-
tos específicos para mobile.
7. Escalabilidade
Essa talvez é se não o maior, um dos maiores benefícios ao utilizar os padrões

de arquitetura em Micro serviços.
A coesão permite que requisitos não funcionais como escalabilidade e elastici-

dade que ocorrem em situações de alta volumetria comumente encontrados em
soluções de médio e grade porte, aumente e reduza instâncias de serviços de
acordo com a necessidade, consumindo recursos físicos sob demanda e apenas
para aquela funcionalidade (microserviço) que está sendo muito requisitado no
momento.
Ganho esse impossível de conseguir em arquiteturas monolíticas, que escalam
tudo ou nada, consumindo desnecessariamente recursos físicos e elevando
custo.
Pelo mesmo motivo, também tende a facilitar a implementação de soluções com-

plexas, possibilitando a segregação de funcionalidades (microserviço) em times
distintos, diminuindo assim a curva de aprendizado necessário do time para pro-
duzir código e funcionalidade que agrega valor.
23
CONCLUSÃO
Esta apostila apresentou uma revisão sobre arquiteturas orientadas a serviço

(SOA) e sua aplicação industrial.
Além disso, discutiu as características e vantagens de uma proposta de arquite-

tura orientada a microserviços em nuvem para aplicações de Internet das Coisas
Industrial (IIoT). Detalhes operacionais da proposta como o framework utilizado,
a comunicação e composição de serviços por coreografia foram explicados.
A integração das tecnologias de automação e TI usando uma arquitetura SOA

permitirá o uso e compartilhamento de microserviços para obtenção de uma ar-
quitetura flexível, escalável, interoperável, distribuída e conectada em rede, de
acordo com os requisitos das novas aplicações relacionadas à Industria 4.0 e
IIoT.
Testes operacionais iniciais da arquitetura realizados com a implementação de

uma malha de controle e supervisão de uma variável de processo usando micro
serviços validam a proposta e demonstram seu potencial para aplicações de
IIoT.
24
REFERÊNCIAS
ORACLE. White Paper. Gestão de Processos de Negócios, Arquitetura Ori-

entada a Serviços e Web 2.0: Transformação da Empresa ou Rota de Coli-
são? 2008.
GUEDES, Marilene. Você sabe o que é Arquitetura Orientada a Serviços

(SOA)? 2017.
GOMES, Daniel. Introdução a Microsserviços. 2019.
SERVICES, Amazon Web. Entenda como o mobile cloud pode impactar a

sua empresa. 2019.
Fowler, M. Microservices a definition of this new architectural term.2014.
25

Arquitetura de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Arquitetura de Software

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Arquitetura de Software

Enviado por

Direitos autorais:

Formatos disponíveis

PRINCÍPIOS DE ARQUITETURA DE SOFTWARE

A nossa história inicia com a realização do sonho de um grupo de empre-

A instituição tem por objetivo formar diplomados nas diferentes áreas de

A nossa missão é oferecer qualidade em conhecimento e cultura de forma

O QUE É A ARQUITETURA DE SOFTWARE? ...................................... 5

OBJETIVOS DA ARQUITETURA DE SOFTWARE ................................. 6

A FUNÇÃO DO ARQUITETO DE SOFTWARE ....................................... 7

PRINCÍPIO DA RESPONSABILIDADE ÚNICA ....................................... 9

PRINCÍPIO ABERTO-FECHADO .......................................................... 10

PRINCÍPIO DA SUBSTITUIÇÃO DE LISKOV ....................................... 12

PRINCÍPIO DE SEGREGAÇÃO DE INTERFACE ................................. 13

PRINCÍPIO DE INVERSÃO DE DEPENDÊNCIA .................................. 15

O PRINCÍPIO DA MENOR SURPRESA................................................ 16

O PRINCÍPIO DO MENOR ESFORÇO ................................................. 17

O PRINCÍPIO DO CUSTO DE OPORTUNIDADE ................................. 18

O PRINCÍPIO DO ÚLTIMO MOMENTO RESPONSÁVEL .................... 20

PRINCÍPIOS DE DESIGN DE SOFTWARE .......................................... 21

SEPARAÇÃO DE INTERESSES ....................................................... 21

INVERSÃO DE DEPENDÊNCIA ........................................................ 23

OS PRINCÍPIOS DA BOA ARQUITETURA........................................... 25

À medida que a complexidade e o tamanho dos sistemas de software têm

Para isso, o projeto da estrutura global do software (arquitetura de sof-

Esses pontos de vista compreendem princípios, padrões, antipadrões, re-

Em geral, esses princípios orientarão você para a criação de aplicativos

Definição pela IBM

Uma arquitetura é o conjunto de decisões significativas sobre a organiza-

Definição pela Microsoft

Arquitetura de Software é o processo de definição de uma solução estru-

Definição pela IEEE

Arquitetura é a organização fundamental de um sistema materializada em

Em resumo, as definições apresentadas concordam que a Arquitetura de

Uma série de causas individualmente ou em conjunto pode fracassar um

Shaw e Garlan (96) a arquitetura define o que é o sistema em termos de

Além da escolha dos algoritmos e estruturas de dados, a arquitetura en-

O profissional Arquiteto de Software é responsável por uma grande vari-

Além disso, faz parte do trabalho de um Arquiteto de Software envolver-

 Definir, criar e manter a documentação arquitetural para

Durante todo o projeto de desenvolvimento de um software, o Arquiteto

Arquitetos de soluções são os especialistas designados responsáveis

Cada capacidade do sistema (por exemplo, serviço/módulo/API) deve ter

A reposta é simples: quanto maior o número de responsabilidades, maio-

A extensibilidade! É comum a manutenção de códigos. Você deve, então,

Este princípio postula que é preferível estender um comportamento do

O princípio de Aberto/Fechado propõe que entidades (classes, funções,

Aberto para extensão significa que, ao receber um novo requerimento, é

Dependency Injection nada mais é do que passar uma dependência como

Dependency Injection é apenas uma maneira de estender uma classe

O ideal é que a entidade dependa de uma abstração que forneça uma

O princípio da Substituição de Liskov leva o nome da sua criadora Barbara

O que isso quer dizer afinal?

No desenvolvimento de software, isso significa que as classes derivadas

As interfaces/contratos devem ser o mais detalhados possível e específi-

Em programação orientada a objetos, quando falamos de interface, esta-

A interface funciona como um contrato: nós definimos o comportamento

As interfaces são comumente utilizadas por linguagens de programação

Linguagens como Ruby ou Python, definem sua interface de forma implí-

O ISP é violado quando uma classe é obrigada a implementar métodos

O princípio da inversão de dependência refere-se à dissociação de mó-

Para cumprir esse princípio, precisamos usar um padrão de design co-

A injeção de dependência é um tópico enorme e pode ser tão complicado ou