Arquitetura de Software

TRF5/2017 – ANALISTA JUDICIÁRIO
Curso de Engenharia e Desenvolvimento de Software

Prof. Diego Carvalho – Aula 05
COESÃO E ACOPLAMENTO
Bem, falemos brevemente sobre esses dois importantes princípios de engenharia de

software: coesão e acoplamento! Eles são fundamentais no conceito de arquitetura
de software. Logo, preciso que vocês decorem a seguinte frase como se fosse um
mantra: Uma oa rquitetura e ware eve er componentes de rojeto com baixo
acoplamento e alta coesão.
Como é, professor? Acoplamento trata do nível de dependência entre módulos ou

componentes de um software. Já a Coesão trata do nível de responsabilidade de
um módulo em relação a outros. Professor, por que é bom ter baixo acoplamento?
Porque se os módulos pouco dependem um o utro, modificações de
afetam os outros, além e ã prejudicar eúso.
Se sse rincípio não for bservado urante a nstrução a rquitetura e

sistema de ftware, pode r roblemas sérios e tenção tura Professor,
por que é bom ter alta coesão? Porque se os módulos têm responsabilidades
claramente definidas, eles serão altamente reusáveis, independentes e simples de
entender.
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 5 de 98
www.concurseirosunid
www.concurs www.concurseirosunidos.o
s.org
RQUITETURA EM CAMADAS
Inicialmente, os aplicativos ram mbinados em uma ica mada, incluindo

Banco de dos, Lógica o plicativo nterface de Usuário. O aplicativo, em geral,
era executado em um computador de grande porte, e os usuários o acessavam por
meio de terminais burros que podiam apenas realizar a entrada e exibição de dados.
Essa abordagem tem o benefício de ser mantida por um administrador central.
As arquiteturas de uma camada têm um grave empecilho: os usuários esperam

interfaces gráficas que exigem muito mais poder computacional do que o dos
simples terminais burros. A computação centralizada de tais interfaces exige muito
mais poder computacional do que um único servidor tem disponível, e ssim as
arquiteturas de a mada nã consegue portar lhares de u ários.
Temos, ntão, a A quitetura Cliente-Servidor de uas camadas. Para explicá-la,

precisamos passar alguns conceitos básicos. Bem, ela é organizada como um
conjunto de serviços, além de servidores e clientes associados que os acessam e os
usam. Compõem esse modelo: servidores, que oferecem serviços; clientes, que
solicitam os serviços; e uma rede que permite aos clientes acessarem esses serviços.
O processamento da informação é dividido em módulo ou processos distintos,

sendo uma abordagem de computação que separa os processos em plataformas
independentes que interagem, permitindo ue s recursos sejam compartilhados
enquanto obtém o áximo e enefício de da ispositivo diferente. Os
principais componentes desse modelo são:
▪ Servidores: que oferecem serviços para outros subsistemas (Ex: Servidores de

Impressão, Servidores de Arquivos, Servidor de Compilação, etc).
▪ Clientes: que solicita os serviços oferecidos pelos servidores. Geralmente são

independentes, podendo ser executados simultaneamente.
▪ Rede: que permite aos clientes acessarem esses serviços. Quando clientes e
servidores podem ser executados em uma única máquina, não são necessários.
Clientes iniciam/terminam a municação com servidores, solicitando/terminando

serviços distribuídos; eles não se comunicam com outros clientes diretamente; eles
são responsáveis pela entrada e saída de dados e comunicação com o usuário; eles
s.org
tornam a rede transparente ao usuário; em geral, são computadores pessoais

conectados a uma rede.
Servidores realizam uma xecução c ntínua; eles ecebem e espondem solicitações

dos clientes; não se comunicam com outros servidores diretamente; prestam
serviços distribuídos; atende a diversos clientes simultaneamente; em geral,
possuem um poder de processamento e armazenamento mais alto que de um
cliente.
Os clientes talvez precisem saber os nomes dos servidores e os serviços que eles
fornecem, mas os servidores não precisam saber sobre os clientes. Eles acessam os
serviços pelo servidor por meio de chamadas remotas de procedimento usando um
protocolo Request-Reply (Ex: HTTP). Essencialmente, um liente z um pedido
um rvidor spera té eceber a esposta.
Essencialmente, um iente az um edido u s rvidor spera té eceber a

resposta. A imagem acima mostra um exemplo de sistema baseado no modelo
cliente-servidor. Ele é multiusuário e baseado na Web, para fornecer um acervo de
filmes e fotografias. Nesse sistema, vários servidores gerenciam e apresentam tipos
diferentes de mídia.
Os frames do vídeo precisam ser transmitidos rapidamente em sincronia, mas com

uma resolução relativamente baixa. Podem ser comprimidos em um repositório e,
assim, o servidor pode cuidar da compressão/descompressão do vídeo. Fotografias
devem estar m alta esolução, portanto devem ser das em um rvidor
dedicado.
s.org
O catálogo deve ser capaz de lidar com várias consultas e de fornecer links para
Sistemas Web de informações com dados do filme e videoclipe, e um sistema de e-
commerce que apoie a venda desses. O rograma cliente mplesmente a
interface grada om o u ário, construída om o de egador eb
para esses serviços.
A vantagem mais importante de delo cliente-servidor ue le é a

arquitetura distribuída. O uso efetivo de sistemas em rede pode ser feito com muitos
processadores distribuídos. É fácil adicionar um novo servidor e integrá-lo ao
restante do sistema ou atualizar servidores de maneira transparente sem afetar
outras partes do sistema.
As arquiteturas cliente-servidor de duas camadas podem ter duas formas: Cliente-

Magro ou Cliente-Gordo. Como é isso, professor?
No delo Cliente-Magro, todo processamento da

aplicação e o gerenciamento de dados é realizado
no servidor. O cliente é responsável somente por
executar o software de apresentação, portanto é
magro!
No delo Cliente-Gordo, o servidor somente é

responsável pelo gerenciamento de dados e o
software do cliente implementa a lógica da
aplicação e as interações com os usuários, portanto
é gordo!
As principais vantagens dos clientes magros são: baixo custo de administração;

facilidade de proteção; baixo custo de hardware; menor custo para licenciamento
de softwares; baixo consumo de energia; resistência a ambientes hosts; menor
dissipação de calor para o ambiente; mais silencioso que um PC convencional; mais
ágil para rodar planilhas complexas; entre outros.
As principais desvantagens dos clientes magros são: se o servidor der problema e

não houver redundância, todos os clientes-magros ficarão inoperantes; necessita de
maior largura de banda na rede em que é empregado; em geral, possui um pior
tempo de resposta, uma vez que usam o servidor para qualquer transação;
apresenta um apoio transacional menos robusto; entre outros.
s.org
As principais vantagens dos clientes gordos são: necessitam de requisitos mínimos

para servidores; apresenta uma performance multimídia melhor; possui maior
flexibilidade; algumas situações se beneficiam bastante, tais como jogos eletrônicos,
em que se beneficiam por conta de sua alta capacidade de processamento e de
hardware específico.
As principais desvantagens dos clientes gordos são: não há um local central para
atualizar e manter a lógica do negócio, uma vez que o código do aplicativo é
executado em vários locais de cliente; é exigida uma grande confiança entre o
servidor e os clientes por conta do banco de dados; não suporta bem o crescimento
do número de clientes.
Comparada à rquitetura e a amada, s arquiteturas de uas camadas

separam fisicamente rface o suário da amada e erenciamento e ados.
Para implementar arquiteturas de duas camadas, não se pode mais ter terminais
burros no lado do cliente; precisa-se de computadores que executem código de
apresentação sofisticado (e, possivelmente, a lógica do aplicativo).
Sistemas Cliente-Servidor em duas camadas foram dominantes durante

aproximadamente toda a década de noventa e são utilizados até hoje. Todavia, para
minimizar acto e danças nas aplicações, decidiu-se parar amada de
negócio da a ada e rface ráfica, gerando três camadas1: Camada de
Apresentação, Camada Lógica do Negócio e Camada de Acesso a Dados.
▪ Camada de presentação: também chamada Camada de Interface, possui

classes que contêm funcionalidades para visualização dos dados pelos usuários.
Ela tem o objetivo de exibir informações ao usuário e traduzir ações do usuário
em requisições às demais partes dos sistemas. O amplo uso da internet tornou
as interfaces com base na web crescentemente populares.
▪ Camada de egócio: também chamada Camada Lógica ou de Aplicação, possui

classes que implementam as regras de negócio no qual o sistema será
implantado. Ela realiza cálculos com base nos dados armazenados ou nos dados
de entrada, decidindo que parte da camada de acesso de ser ativada com base
em requisições provenientes da camada de apresentação.
1
Galera, diz-se Arquitetura em Três Camadas, 3-Layers Architecture ou 3-tiers Architecture. Apesar de muitas
pessoas usarem os dois termos indiferentemente, eles não são iguais: Layers são camadas lógicas, i.e., pode
haver três layers em uma única máquina e os Tiers são camadas físicas, i.e., pode haver apenas um tier por
máquina. Entenderam? ;)
s.org
Grosso odo: um usuário faz uma requisição por meio de um Navegador (Camada
do Cliente), essa requisição é passada para um Servidor Web (Camada de
Apresentação), que a processa e procura a regra de negócio correspondente no
Servidor de Aplicação (Camada de Aplicação), que procura os dados no banco de
dados (Camada de Dados).
s.org
Smalltalk. ideia original era organizar ódigo, separar esponsabilidades,

aumentar a nibilidade, promover m baixo acoplamento a lta coesão,
fomentar a eusabilidade o digo rnar o ma escalável.
Passou um bocadinho de tempo e, com o surgimento da WWW, algumas pessoas

pensaram em adaptar esse padrão arquitetural para o mundo web. Muitos
frameworks de plicação merciais e o comerciais foram criados tendo mo
base sse delo. Estes frameworks variam em suas interpretações, principalmente
no modo que as responsabilidades MVC são divididas entre o cliente e servidor.
Camada e delo:
Essa é a camada responsável pela rep e sentação dos dados, provendo meios de
acesso (leitura/escrita). Cara, sempre ue ocê ensar em manipulação e ados,
(leitura, escrita u validação e dados2), pense a amada e delo! Ela gerencia
não só os dados, mas também os comportamentos fundamentais da aplicação –
representados por regras de negócio (Sim, elas ficam na Camada de Modelo!).
A Camada e odelo encapsula s principais funcionalidades e ados do s stema.

Ela notifica suas visões e respectivos controladores quando surge alguma mudança
em seu estado, isto é, ela é responsável pela manutenção do estado da aplicação.
Estas notificações permitem que as visões produzam saídas atualizadas e que os
controladores alterem o conjunto de comandos disponíveis.
Camada e C ntrole:
Essa é a camada responsável por receber todas as requisições do usuário. Seus

métodos – chamados actions – são responsáveis por uma página, controlando qual
modelo usar e qual visão será mostrada ao usuário. Ele é apaz de nviar comandos
para delo atualizar u stado. Ele também pode enviar comandos para a
respectiva visão para alterar a apresentação da visão do modelo.
A Camada e ontrole tende às requisições do usuário e eleciona odelo e a

visão que ário usará ara ragir com o odelo. O usuário interage com
controladores – por meio de visões – que interpretam eventos e entradas enviadas
(Input), mapeando ações do usuário em comandos que são enviados para o modelo
e/ou para a visão para efetuar as alterações apropriadas (Output).
2
Galera, a validação ocorre na Camada de Modelo. Pode ocorrer na Camada de Visão? Sim, eu posso utilizar um
JavaScript p/ fazer algumas validações de dados, mas isso é inseguro e se trata de uma violação do modelo.
Logo, aceitem que validações ocorrem na camada de modelo. Bacana?
s.org
Um controlador define o comportamento da aplicação, interpretando as ações do

usuário e mapeando-as em chamadas do modelo. Em um te de plicações web,
essas ações do s ário poderiam ser ques em botões ou seleções de nus. As
ações realizadas pelo modelo poderiam ser ativar processos de negócio ou alterar
o estado do modelo.
Vocês já pensaram no porquê de essa camada ter esse nome? Porque ela controla o
fluxo da aplicação, interpretando os dados de entrada e coordenando/orquestrando
as manipulações do modelo e as interações com o usuário. Trata-se de uma camada
intermediária entre a Visão e o Modelo. Em geral, há c ntrolador ara da
visão, apesar e poder xistir várias controladoras para a sma visão.
Camada e isão:
Essa da esponsável pela ração com o s ário, sendo esponsável

apenas pela xibição de dados. Trata-se de uma representação visual do modelo.
Ela permite apresentar, de diversas formas diferentes, os dados para o usuário. A
visão não sabe nada sobre o que a aplicação está fazendo atualmente, ela recebe
instruções do controle, notifica o controle e recebe informações do modelo.
Há uma diferença fundamental entre Arquitetura em Três-Camadas e Arquitetura

MVC! Na rimeira, a amada o te mais se c munica diretamente m a
camada de ados da omunicação obrigatoriamente eve assar ela amada
intermediária. Na segunda, a camada de visão se comunica de volta com o modelo
e com o controlador para reportar o seu estado.
Podemos afirmar, portanto, que rimeira é a rquitetura ar, enquanto

segunda a rquitetura angular. A visão interage com o controle por meio de
eventos; o controle notifica o modelo sobre uma mudança; o modelo modifica seu
estado e notifica suas visões e controladores; as visões podem consultar diretamente
o estado do modelo, sem interferência do controlador.
Essa última sentença é extremamente polêmica – vocês encontrarão muitos lugares

dizendo que não é possível que a visão solicite diretamente o estado do modelo,
mas é possível, sim! Vamos supor que você esteja comprando cursos no site do
Estratégia! Colocou um no carrinho, colocou dois e colocou o terceiro. Você, então,
clica no botão de listar os itens que estão no carrinho.
s.org
Nesse momento, a visão não precisa necessariamente fazer uma requisição para o
controle, para que o controle peça a lista de itens para o modelo. Ora, ela pode
pedir diretamente para o modelo! Fiquem ligados também ue xistem diversas
visões para ada delo. Na imagem abaixo, podemos ver as possíveis interações
na Arquitetura MVC!
Para quem quiser conhecer melhor, recomendo os seguintes artigos:
▪ http://www.cfgigolo.com/2008/01/mvc-model-view-controller-e-os-tres-macacos
▪ https://r.je/views-are-not-templates.html
▪ http://tableless.com.br/mvc-afinal-e-o-que
s.org
a) renderiza a interface de usuário a partir da visão, o modelo encapsula

funcionalidades e objetos de conteúdo e a visão processa e responde a eventos
e invoca alterações ao controlador.
b) encapsula funcionalidades e objetos de conteúdo, o modelo processa e

responde a eventos e invoca alterações ao controlador e a visão renderiza a
interface de usuário a partir do modelo.
c) encapsula funcionalidades e objetos de conteúdo, o modelo renderiza a

interface de usuário a partir da visão e a visão processa e responde a eventos e
invoca alterações ao controlador.
d) processa e responde a eventos e invoca alterações ao modelo, o modelo

encapsula funcionalidades e objetos de conteúdo e a visão renderiza a interface
de usuário a partir do modelo.
e) processa e responde a eventos e invoca alterações ao modelo, o modelo

renderiza a interface de usuário a partir da visão e a visão encapsula
funcionalidades e objetos de conteúdo.
Comentários:
O Controlador processa e responde a eventos e invoca alterações ao modelo, o

modelo encapsula funcionalidades e objetos de conteúdo e a visão renderiza a
interface de usuário a partir do modelo.
Gabarito: D
11. (FCC – 010 A /SP A alista de temas) Sobre as camadas do modelo de

arquitetura MVC (Model- View-Controller) usado no desenvolvimento web é
correto afirmar:
a) Todos os dados e a lógica do negócio para processá-los devem ser

representados na camada Controller.
b) A camada Model pode interagir com a camada View para converter as ações
do cliente em ações que são compreendidas e executadas na camada Controller.
s.org
CLEAN CODE (CÓDIGO LIMPO)
Quando falamos em Clean Code, necessariamente passamos por Robert Martin!

Esse cara é um dos autores do Manifesto Ágil e ele foi o grande idealizador do Clean
Code. Em seu livro: “Clean code: a Handbook of Agile Software Craftsmanship”, ele
devora esse assunto em pouco mais de 400 páginas! Nós não entrar m tantos
detalhes, porque inda ssunto piente e que ó C E cobrou...
De acordo com Robert Martin, o CleanCode trata do uso disciplinado de uma

miríade de pequenas técnicas aplicadas por meio de uma sensibilidade
meticulosamente adquirida sobre ‘limpeza’ – a sensibilidade ao código é o segredo.
Alguns de nós já nascemos com ela; outros precisam se esforçar para adquiri-la. Um
código po mpre arece ue i escrito por lguém que orta.
s.org
Tudo rve ara ualquer profissão, mas por lguma razão, algumas pessoas
acham que a área e ecnologia da ormação diferente das demais. Ora, vocês
já imaginaram um médico fazendo uma cirurgia, quando recebe uma mensagem
do chefe do hospital dizendo: “Doutor, você está enrolando demais nas cirurgias,
acelera um pouco isso aí, porque você já está atrasado os próximos pacientes”.
“Outra coisa, essa mulher tinha pedido para colocar silicone nos seios, mas acabou
de desistir e, na verdade, ela vai querer uma plástica no nariz; não demore mais do
que vinte minutos, ok?!”. Existem muitos programadores ruins por aí, mas existem
muitos que bons programadores, porém fazem digos uins por nta de
todos esses motivos supracitados.
É preciso que todos tenham noção de que código ruim tem um preço alto. Por que?
Porque eventualmente ele irá falhar e, quando isso acontecer, alguém vai ter que
ler o código e entendê-lo para dar manutenção. Quanto ior scrito, mais difícil e
entender, mais demora para c nsertar. Fora a frustração e a irritação de mexer em
um código mal escrito. Quem já passou por isso sabe...
Acho que á icou aro ue u ódigo de aixa qualidade, pode atar rojeto
e té estruir a mpresa. Professor, o que seria um código limpo? É um código
eficiente, simples, direto, elegante, não-redundante, pouco dependente, fácil de
manutenir, ler e entender, coberto por testes, e que seguem padrões definidos.
Galera, um código limpo que pode ser lido quase como uma conversa. Vejam só:
Martin Fowler afirma que qualquer um é capaz de escrever um código que um

computador entenda. No ntanto, bons programadores escrevem código ue
humanos entendem. Professor, por que o nome ‘código limpo’? Cara, esse nome veio
s.org
de uma das regras do escotismo que diz: “Sempre deixe a área de acampamento
mais limpa do que estava” – isso serve para os programadores e seus códigos.
Vamos ver agora alguns princípios do CleanCode:
Nomes significativos: escolher bons nomes (para variáveis, métodos, funções, etc);
nomes devem ter significado (i.e., revelar a intenção); nomes devem estar de acordo
com o contexto empregado; nomes devem ser pronunciáveis (evitar siglas); nomes
não devem ser abreviados; nomes devem ser descritíveis; por devem ser ão-
ambíguos, fáceis de r e ompreender o ntexto m que re.
int d; //tempo gasto em dias
Em geral, se você precisa de um comentário para explicar o que significa uma

variável, algo está errado – o nome não revela a intenção. Agora jam a iferença
na rma de screver abaixo. Não é necessário comentário, porque ela já revela sua
intenção e seu significado. Programadores, parem de preguiça de criar variáveis
com nomes grandes, afinal toda IDE atualmente tem ctrl + space para completar.
int tempoGastoEmDias;
Nomes de classes não devem ser verbos, devem ser substantivos; já nomes de
métodos não devem ser substantivos, devem ser verbos. Quanto às funções: devem
ser pequenas e devem fazer apenas uma coisa (responsabilidade única); não deve
ter nível de endentação maior que dois; preferencialmente, devem ter poucos
parâmetros; recomenda-se não repetir código (evitar redundância).
Quanto aos comentários: somente são úteis se forem colocados nos lugares certos;
como comentários, em geral, não são atualizados, eles podem distorcer a realidade,
logo não são confiáveis; além disso, comentários por si só não transformam um
código sujo em um código limpo; deve-se evitar fazer controle de versão por meio
de comentários (//revisado por Diego).
Quanto rmatação: classes menores são mais fáceis de entender; conceitos

relacionados devem ficar próximos; endentar bem o código é fundamental; limite o
tamanho máximo da linha (Ex: 120 caracteres); recomenda-se combinar um estilo
de formatação entre toda equipe de desenvolvimento; use espaços entre
operadores, parâmetros e vírgulas; organize as declarações de variáveis e métodos;
s.org
Quanto s classes: também devem ser pequenas e ter responsabilidade única;

organize as declarações de variáveis e métodos. Galera, é isso... existe muito mais
no CleanCode – como eu disse, há um livro inteiro sobre isso. No entanto, é um
tema que caiu apenas uma vez até hoje, logo vamos nos limitar ao que foi dado.
Bacana? Vamos ver uns exercícios.
s.org
c) Os nomes de funções e de métodos devem ser longos e descritivos.
d) Os parâmetros devem ser aglutinados em funções, e cada função deve ter,

no máximo, três parâmetros.
e) O comando return deve ser evitado, ao passo que continue e break devem
ser priorizados, assim como o goto.
Comentários:
não devem ser abreviados; nomes devem ser descritivos; por fim, devem ser não-
ambíguos, fáceis de ler e de compreender no contexto em que se insere.
(a) Conforme vimos em aula, nomes devem ser pronunciáveis e que tenham um
propósito.
Nomes de classes não devem ser verbos, devem ser substantivos; já nomes de
métodos não devem ser substantivos, devem ser verbos. Quanto às funções: evem
ser pequenas e devem fazer apenas uma coisa (responsabilidade única); não deve ter
nível de endentação maior que dois; preferencialmente, devem ter poucos
parâmetros; recomenda-se não repetir código (evitar redundância).
(b) Conforme vimos em aula, nomes de classes não devem ser verbos – mas
substantivos.
não devem ser abreviados; nomes devem ser descritivos; por fim, devem ser não-
ambíguos, fáceis de ler e de compreender no contexto em que se insere.
(c) Conforme vimos em aula, nomes devem ser descritivos, mas isso não significa
necessariamente longo.
Robert C. Martin diz: “The ideal number of arguments for a function is zero (niladic).
Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic)
s.org
TRICAS SOFTWARE
De cordo m Sommerville: “A medição de software se dedica a derivar um valor

numérico para algum atributo de um produto de software ou de um processo de
software. Comparando-se esses valores uns com os outros e aos padrões que se
aplicam em uma organização, você pode ser capaz de tirar conclusões sobre a
qualidade de software ou dos processos de software”.
As medições de software podem ser usadas para realizar previsões gerais sobre um
sistema, i.e., encontrar uma estimativa geral de algum atributo do sistema (ex:
quantidade de defeitos) ou para identificar componentes anômalos, i.e., partes que
possuem características que desviam de alguma regra específica. Uma trica de
software a dição que efere a software, processo u ocumentação.
Na ia os empreendimentos técnicos, as medidas e s métricas ajudam-nos a

entender rocesso cnico do ara esenvolver roduto. O processo é
medido num esforço para melhorá-lo, e o produto é medido para aumentar sua
qualidade, quantificar e administrar mais efetivamente. Vamos ver agora algumas
métricas e grupos (observem que uma métrica pode pertencer a mais de um grupo).
Métricas de Software podem ser de controle ou de predição:
▪ Métricas de Controle/Processo: estão relacionadas a processos e ftware; são

utilizadas para tomada de decisões sobre alterações no processo de
desenvolvimento de software, por exemplo: esforço médio e tempo necessário
para reparar os defeitos reportados.
▪ Métricas de edição/Produto: estão relacionadas a rodutos e oftware; são

utilizadas para estimar o esforço necessário para construção ou alteração de
software e auxiliam a prever características dele, por exemplo: complexidade de
um módulo ou a extensão média dos identificadores em um programa.
Métricas de Predição/Produto podem ser internas/estáticas ou externas/dinâmicas:
▪ Métricas Estáticas u nternas: são aquelas coletadas em representações do

sistema como rojeto, programa ou documentação – sem a necessidade da
execução dos programas. Ajudam a mensurar a complexidade e a facilidade de
s.org
compreensão e manutenção de um sistema de software. Permitem medir a

qualidade dos artefatos intermediários e prever a qualidade do produto final.
▪ Métricas Dinâmicas u Externas: são aquelas coletadas durante a execução de

um programa, a partir do comportamento do sistema ou do seu efeito no
ambiente real de operação. Elas ajudam a valiar a eficiência e confiabilidade
de m programa e quase sempre estão relacionadas com atributos da qualidade
de software.
Métricas de Software podem ser diretas ou indiretas:
▪ Métricas Diretas: também conhecidas como básicas, quantitativas ou primitivas,

são quelas que o dependem da dição de utros atributos, por exemplo:
custo/esforço do desenvolvimento, linhas de código, velocidade de execução,
quantidade de memória, número de erros, quantidade de defeitos.
▪ Métricas Indiretas: também conhecidas como qualitativas ou derivadas, são

aquelas que ependem da dição de outros atributos. Por exemplo:
produtividade, qualidade e técnicas (funcionalidade, complexidade, eficiência,
confiabilidade, manutenibilidade, modularidade, portabilidade).
Métricas de Software podem ser orientadas a tamanho, função ou pessoas:
▪ Métricas Orientadas a amanho são aquelas baseadas no mero e has de

código produzidas, também conhecidas como Lines Of Code (LOC).3
▪ Métricas Orientadas à ão: são aquelas baseadas na funcionalidade do

software, tais como Análise de Pontos de Função.
▪ Métricas O ntadas ssoas são aquelas que indicam a rma mo s

pessoas devem desenvolver rogramas de computador.
Métricas de Software podem ser objetivas ou subjetivas:
▪ Métricas Objetivas são aquelas que independem do utor a dição ou

julgamento mano, por exemplo: quantidade de defeitos.
3
Como medir Produtividade? KLOC/Pessoa-Mês. Como medir Qualidade? Erros/KLOC. Como medir Custo?
$/KLOC. Como medir Documentação? Páginas/KLOC.
s.org
complexidade omática ã têm um elacionamento ro nsistente m

atributos de qualidade, como ac lidade e mpreensão u manutenção.
O que fazer, então? Bem, uma alternativa seria coletar uma grande quantidade de
dados de sistemas existentes e descobrir como os atributos de produto de software
se relacionam com as qualidades externas. As métricas de produtos se dividem em
duas classes: métricas dinâmicas, coletadas em um rograma m execução; e
métricas estáticas, coletadas em uma ocumentação, projeto, etc.
Em geral, métricas dinâmicas ajudam a avaliar a eficiência e a confiabilidade de um

programa. Já as métricas estáticas ajudam a avaliar a complexidade, facilidade de
compreensão e facilidade de manutenção de um sistema de software. As métricas
dinâmicas geralmente ossuem uma elação mais estreita m atributos de
qualidade e s ftware o ue as métricas estáticas. Vamos ver algumas métricas?
▪ Fan-in/Fan-out:
Fan-in é uma medida do número de funções ou métodos que chamam alguma

outra função ou método (digamos X). Fan-out é o número de funções chamadas
pela função X. Um valor alto para fan-in significa que X está firmemente acoplado
com o resto do projeto, e mudanças em X terão grande impacto.
▪ Extensão e C digo:
É uma medida do tamanho de um programa. Geralmente, quanto maior for o

tamanho do código de um componente, mais complexo e propenso a erros esse
componente será. A extensão de código foi mostrada como uma das métricas mais
confiáveis de previsão de propensão a erros em componentes.
▪ Complexidade C clomática:
É uma medida da complexidade de controle de um programa. Essa complexidade

de controle pode estar relacionada à facilidade de compreensão do programa.
Utiliza a fórmula M = E – N + 2.P (M = Complexidade Ciclomática; E = Quantidade
de Setas; N = Quantidade de Nós; P = Quantidade de Componentes Conectados).
▪ Extensão e dentificadores:
É uma medida da extensão média de identificadores distintos em um programa. Em

geral, quanto maiores forem os identificadores, mais eles serão significativos e, por
s.org
isso, mais compreensível será o programa. Vocês entendem isso? Uma variável com
30 caracteres, em geral, possui mais significado.
▪ Profundidade e hamento e D clarações Condicionais:
É uma medida da profundidade de aninhamento de declarações IF em um

programa. As declarações IF profundamente aninhadas são difíceis de compreender
e são potencialmente propensas a erros. Basta imaginar um IF dentro de um IF
dentro de um IF dentro de um IF – fica complicado!
▪ Índice e Fog
É uma medida da extensão média das palavras e das sentenças em documentos.

Quanto maior for o valor para o índice de Fog, mais difícil será a compreensão de
documentos. Galera, vocês devem saber como é chato ler documentação e o Índice
de Fog ajuda a medir aqueles mais difíceis de entender.
s.org
Comentários:
▪ Métricas Orientadas a amanho: são aquelas baseadas no número de inhas de

código produzidas, também conhecidas como Lines Of Code (LOC).4
▪ Métricas rientadas à unção: são aquelas baseadas a uncionalidade do

software, tais como Análise de Pontos de Função.
▪ Métricas Orientadas a Pessoas: são aquelas que indicam a a o as pessoas

devem desenvolver programas de computador.
Conforme vimos em aula, a questão trata das métricas orientadas à função.
Gabarito: E
10. (CESPE - 009 NTAQ sta dministrativo - nformática) Métricas de

produto dinâmicas são coletadas por meio de medições realizadas em
representações do sistema, como projeto, programa ou documentação, ao
passo que métricas de produto estáticas são coletadas em programas em
execução.
Comentários:
▪ Métricas Estáticas ou Internas: são aquelas coletadas em representações do

sistema o projeto, programa documentação – sem a necessidade da
execução dos programas. Ajudam a mensurar a complexidade e a facilidade de
compreensão e manutenção de um sistema de software. Permitem medir a
qualidade dos artefatos intermediários e prever a qualidade do produto final.
▪ Métricas Dinâmicas ou Externas: são aquelas coletadas durante a execução de um

programa, a partir do comportamento do sistema ou do seu efeito no ambiente
real de operação. Elas ajudam a valiar a ficiência e onfiabilidade e
programa e quase sempre estão relacionadas com atributos da qualidade de
software.
Conforme vimos em aula, a questão inverteu os conceitos.
Gabarito: E
4
Como medir Produtividade? KLOC/Pessoa-Mês. Como medir Qualidade? Erros/KLOC. Como medir Custo?
$/KLOC. Como medir Documentação? Páginas/KLOC.
s.org
a) É uma abordagem utilizada para definir o tempo gasto, em cada ponto de

função.
b) Oferece meios de mensurar o tempo gasto, para o desenvolvimento do

software.
c) Fornece informações sobre a quantidade de linhas de código.
d) É uma abordagem utilizada, para reforçar os testes de aceitação.
e) Oferece uma estimativa de quanto o software se adequa às exigências

implícitas e explícitas do cliente.
Comentários:
a) Não, tempo gasto por ponto de função está mais para medição de produtividade
do que de qualidade; b) Não, isso é para estimar o tempo gasto para desenvolver
o software; c) Não, quantidade de linhas de código não servem para medir a
qualidade de um software e vice-versa; d) Não existe essa relação; e) Perfeito,
permite estimar a aderência aos requisitos do usuário.
Gabarito: E
14. (IADES 013 BSERH - a ista de ologia a nformação este

Qualidade) À qual modalidade de métrica pertencem a funcionalidade, a
modularidade e a manutenibilidade?
a) De qualidade.
b) Técnicas.
c) Produtividade.
d) De estabilidade
e) De vulnerabilidade.
Comentários:
Existem muitas classificações para métricas. Uma delas organiza as classes em

Métricas de Produtividade (resultado do processo de desenvolvimento), Qualidade
(Nível de Exigência/Satisfação) ou Técnicas (Funcionalidade, Manutenibilidade,
Modularidade, etc).
s.org
Gabarito: B
15. (FUNCAB - 010 JUS-RO - n sta e Sistemas) É um exemplo de métrica

de controle de software:
a) a complexidade ciclomática de um módulo.

b) o comprimento médio de identificadores em um programa.
c) o número de atributos e operações associadas com objetos em um projeto.
d) o tempo médio requerido para reparar defeitos relatados.
e) o número de mensagens de erro.
Comentários:
Complexidade Ciclomática, comprimento médio de identificadores, número de

atributos e operações associadas com objetos e número de mensagens de erro são
todas métricas de predição, porque estão todas diretamente relacionadas com o
produto de software. Já o tempo médio requerido para reparar defeitos é métrica
de controle, porque estão diretamente relacionados com o processo de software.
Alguns podem se confundir com a Complexidade Ciclomática! Ela auxilia a estimar

o esforço necessário para construir um software ou fazer alterações nele, certo? Ela
mostra todos os caminhos independentes de um código-fonte como em um fluxo
de controle (mas não confundam com Métrica de Controle). É puramente uma
Métrica de Produto.
Gabarito: D
16. (FEPESE - 010 C - lista e mas) Considere as seguintes

afirmativas relacionadas a métricas de software:
1. A contagem de linhas de código (LOC) constitui um exemplo de métrica direta.
2. A medida de qualidade expressa em erros/KLOC constitui um exemplo de

métrica orientada a tamanho (KLOC = 1000.LOC).

métrica indireta (KLOC = 1000.LOC).
Assinale a alternativa que indica todas as afirmativas corretas.
s.org
P ADIGMA ESTRUTURADO
O Paradigma Estruturado tem o objetivo de melhorar a clareza, qualidade e tempo

de desenvolvimento de um programa de computador por meio da utilização
extensa de sub-rotinas, estruturas de bloco e loops, em contraste à utilização de
desvios incondicionais (famosos saltos ou goto). Por que? Porque eles dificultavam
imensamente a leitura, compreensão e depuração do código.
Quem já programou em Assembly sabe que os saltos são bastante problemáticos e

complexos. Portanto, o Paradigma Estruturado busca organizar o fluxo de controle
de execução dos programas de maneira lógica, por meio da modularização do
código em blocos aninhados de comando, oferecendo ao rogramador
controle sobre ux .
Agora vamos mais a fundo! As linguagens estruturadas reduzem qualquer

programa a ês estruturas principais: sequência, seleção epetição. Sequencial,
porque possui uma ordem de execução; seletiva, porque seleciona um trecho de
código dentre diversas opções de fluxo; e repetitiva, porque realiza a iteração de
diversos trechos de código.
s.org
/* Representação de um algoritmo genérico */
variavel 1;
variavel 2;
variavel 3;
Inicio
{
comando 1;
comando 2;
comando 3;
comando 4;
comando 5;
}
Fim
Bem, primeiro vamos ver a estrutura de um algoritmo em uma linguagem

estruturada (na verdade, essa estrutura serve para diversos outros paradigmas),
como mostra a imagem acima. Observem que, primeiro, há uma declaração de
variáveis e, em seguida, há o corpo do algoritmo – essa estrutura é lida ara odo
e ualquer lgoritmo struturado: corpo ariáveis.
/* Representação de uma estrutura sequencial */
Inicio
{
comando 1;
comando 2;
comando 3;
comando 4;
comando 5;
}
Fim
A Estrutura de S quência ealiza njunto e

comandos sequencialmente rdenados, descendente
e a ordem em que oram declarados, como mostra
a imagem ao lado.
Esses comandos podem ser: uma leitura, uma

gravação, uma atribuição, etc. O foco aqui é apenas
demonstrar a sequência ordenada de execução dos
comandos.
s.org
A Estrutura de leção (ou

Decisão ou ainda ndicional)
realiza njunto e
comandos dependendo a
veracidade a c ndição
imposta, como mostra a
imagem abaixo. Pode ser de
três modos: por seleção simples
ou composta; por meio de um
operador ternário; ou por meio
de uma seleção de múltipla
escolha.
/* Representação de uma estrutura condicional por seleção simples/composta */
Inicio
Se (condição 1) Então
(comandos)
Senão
(comandos)
Fim-Se
Fim
/* Representação de uma estrutura condicional por meio de um operador ternário */
(condição) ? (comandos do Então):(comandos do Senão)
/* Representação de uma estrutura condicional por meio de uma seleção de múltipla escolha */
Escolha a
Caso 1:
(comandos)
Caso 2:
(comandos)
...
Caso Contrário
(comandos)
Fim-Escolha
No rimeiro so, é em simples! Exemplo: se eu tenho mais de 18 anos, então sou

maior de idade; se não tenho mais de 18 anos, então sou menor de idade. Tranquilo,
né?! Já quanto s za perador rnário, funciona de odo s ar, i.e., a
condição é ter ou não mais de 18 anos. Se eu tiver, sou maior de idade e se eu não
tiver, sou menor de idade.
No há ma s leção m múltipla scolha. Caso eu tenha até 3 anos,

então sou um bebê; caso eu tenha entre 4 e 12 anos, então sou uma criança; caso
eu tenha entre 13 e 18 anos, então sou um adolescente; caso eu tenha entre 19 e 59
s.org
anos, então sou um adulto; por fim, caso contrário, i.e., eu tenha mais de 60 anos,
então sou um idoso.
Por fim, vamos falar sobre a

Estrutura de Repetição. Ela epete
ou itera conjuntos de c mandos
dependendo da racidade da
condição osta, como mostra a
imagem abaixo.
Pode r e s modos: por

repetição pré-testada; por
repetição pós-testada; ou por meio
de repetição com variável de
controle.
/* Representação de uma estrutura de repetição pré-testada */
Enquanto (condição) Faça

(comandos)
Fim-Enquanto
/* Representação de uma estrutura de repetição pós-testada */
Repita
(comandos)
Até (condição)
/* Representação de uma estrutura de repetição com variável de controle */
Para x=1 até 100 Faça

(comandos)
Fim-Para
No primeiro caso, inicialmente testa-se a condição e, caso ela seja verdadeira, entra-
se no bloco de comandos, saindo – apenas – quando a condição se tornar falsa. No
segundo caso, entra-se no bloco de comandos, realizam-se todos os passos até
testar a condição. Da sma forma, caso la ja a, o u sai do loco e
comandos.
Por fim, na estrutura de repetição com variável de controle, utiliza-se uma variável
que controlará a quantidade de iterações do bloco de comandos, isto é, nesse caso,
há uma quantidade definida de repetições e, portanto, quando chegar ntagem
máxima, o ontrole e o s o loco de comandos e parte para a próxima
instrução do programa.
s.org
funcional relativa dos módulos (coesão), a respectiva sequência, da pior para a

melhor, é temporal, lógica e sequencial.
s.org
a) Model, View e Control.

b) Control, View e Model.
c) View, Model e Control.
d) Control, Model e View.
e) View, Control e Model.
s.org
a) A segurança do código é vital, por isso os programadores devem deixar o

código o mais obscuro possível.
b) Se um valor deve ser utilizado em múltiplos locais do código, é imperativo

atribuir esse valor a uma variável ou a uma constante com nome amigável.
c) As classes devem possuir nome amigável oriundo de verbos, escolhidos no

infinitivo, e não no gerúndio.
d) Para customizar o código, deve-se utilizar o mesmo termo para duas

diferentes ideias.
e) Os nomes das variáveis devem ser simplificados, de forma a não criar códigos
gordos (fat codes) — por exemplo, o uso de x para o nome de uma variável é
mais apropriado que MediadosAlunosAprovados.
s.org
b) Oferece meios de mensurar o tempo gasto, para o desenvolvimento do

software.
c) Fornece informações sobre a quantidade de linhas de código.
d) É uma abordagem utilizada, para reforçar os testes de aceitação.
e) Oferece uma estimativa de quanto o software se adequa às exigências

implícitas e explícitas do cliente.
14. (IADES 013 BSERH - a ista e ologia a nformação te

Qualidade) À qual modalidade de métrica pertencem a funcionalidade, a
modularidade e a manutenibilidade?
a) De qualidade.
b) Técnicas.
c) Produtividade.
d) De estabilidade
e) De vulnerabilidade.
15. (FUNCAB - 010 JUS-RO - sta e Sistemas) É um exemplo de métrica

de controle de software:
a) a complexidade ciclomática de um módulo.

b) o comprimento médio de identificadores em um programa.
c) o número de atributos e operações associadas com objetos em um projeto.
d) o tempo médio requerido para reparar defeitos relatados.
e) o número de mensagens de erro.
16. (FEPESE - 010 C - A lista e mas) Considere as seguintes

afirmativas relacionadas a métricas de software:
1. A contagem de linhas de código (LOC) constitui um exemplo de métrica direta.

métrica orientada a tamanho (KLOC = 1000.LOC).

métrica indireta (KLOC = 1000.LOC).
s.org

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

TRF5/2017 – ANALISTA JUDICIÁRIO

Curso de Engenharia e Desenvolvimento de Software

Bem, falemos brevemente sobre esses dois importantes princípios de engenharia de

Como é, professor? Acoplamento trata do nível de dependência entre módulos ou

Se sse rincípio não for bservado urante a nstrução a rquitetura e

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 5 de 98

Inicialmente, os aplicativos ram mbinados em uma ica mada, incluindo

As arquiteturas de uma camada têm um grave empecilho: os usuários esperam

Temos, ntão, a A quitetura Cliente-Servidor de uas camadas. Para explicá-la,

O processamento da informação é dividido em módulo ou processos distintos,

▪ Servidores: que oferecem serviços para outros subsistemas (Ex: Servidores de

▪ Clientes: que solicita os serviços oferecidos pelos servidores. Geralmente são

Clientes iniciam/terminam a municação com servidores, solicitando/terminando

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 10 de 98

tornam a rede transparente ao usuário; em geral, são computadores pessoais

Servidores realizam uma xecução c ntínua; eles ecebem e espondem solicitações

Essencialmente, um iente az um edido u s rvidor spera té eceber a

Os frames do vídeo precisam ser transmitidos rapidamente em sincronia, mas com

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 11 de 98

A vantagem mais importante de delo cliente-servidor ue le é a

As arquiteturas cliente-servidor de duas camadas podem ter duas formas: Cliente-

No delo Cliente-Magro, todo processamento da

No delo Cliente-Gordo, o servidor somente é

As principais vantagens dos clientes magros são: baixo custo de administração;

As principais desvantagens dos clientes magros são: se o servidor der problema e

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 12 de 98

As principais vantagens dos clientes gordos são: necessitam de requisitos mínimos

Comparada à rquitetura e a amada, s arquiteturas de uas camadas

Sistemas Cliente-Servidor em duas camadas foram dominantes durante

▪ Camada de presentação: também chamada Camada de Interface, possui

▪ Camada de egócio: também chamada Camada Lógica ou de Aplicação, possui

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 13 de 98

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 16 de 98

Smalltalk. ideia original era organizar ódigo, separar esponsabilidades,

Passou um bocadinho de tempo e, com o surgimento da WWW, algumas pessoas

A Camada e odelo encapsula s principais funcionalidades e ados do s stema.

Essa é a camada responsável por receber todas as requisições do usuário. Seus

A Camada e ontrole tende às requisições do usuário e eleciona odelo e a

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 23 de 98

Um controlador define o comportamento da aplicação, interpretando as ações do

Essa da esponsável pela ração com o s ário, sendo esponsável

Há uma diferença fundamental entre Arquitetura em Três-Camadas e Arquitetura

Podemos afirmar, portanto, que rimeira é a rquitetura ar, enquanto

Essa última sentença é extremamente polêmica – vocês encontrarão muitos lugares

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 24 de 98

Para quem quiser conhecer melhor, recomendo os seguintes artigos:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 25 de 98

a) renderiza a interface de usuário a partir da visão, o modelo encapsula

b) encapsula funcionalidades e objetos de conteúdo, o modelo processa e

c) encapsula funcionalidades e objetos de conteúdo, o modelo renderiza a

d) processa e responde a eventos e invoca alterações ao modelo, o modelo

e) processa e responde a eventos e invoca alterações ao modelo, o modelo

O Controlador processa e responde a eventos e invoca alterações ao modelo, o

11. (FCC – 010 A /SP A alista de temas) Sobre as camadas do modelo de

a) Todos os dados e a lógica do negócio para processá-los devem ser

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 32 de 98

CLEAN CODE (CÓDIGO LIMPO)

Quando falamos em Clean Code, necessariamente passamos por Robert Martin!

De acordo com Robert Martin, o CleanCode trata do uso disciplinado de uma

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 35 de 98

Martin Fowler afirma que qualquer um é capaz de escrever um código que um

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 37 de 98

Vamos ver agora alguns princípios do CleanCode:

int d; //tempo gasto em dias