Arquit de Software e Comp em Nuvem

Prévia do material em texto

UNIDADE 1.1 - INTRODUÇÃO À ARQUITETURA DE SOFTWARE 
 
Apresentação 
Desde os tempos mais remotos, a arquitetura é uma ferramenta essencial para se obter uma qualidade melhor na construção de estruturas e 
sua utilização ajudou a garantir um melhor aproveitamento do espaço, dos recursos e da mão de obra. 
Na computação, especificamente no desenvolvimento de softwares e soluções, a necessidade de se ter alta qualidade e melhor 
aproveitamento de recursos e acabou criando uma demanda para que se houvesse uma metodologia e profissionais que suportassem e 
suprissem estas necessidades. Então, foi-se identificando, ao longo do tempo, modelos e padrões arquiteturais, que foram evoluindo e sendo 
acrescentados. 
Com a formalização do processo arquitetural e o aumento de sua utilização no ciclo de criação e desenvolvimento de software, algumas 
características foram se tornando a base do pensamento, servindo como guia para os profissionais desta área ao iniciarem o design e a 
construção da arquitetura de sistemas. 
Dessa forma, vemos todos os dias em todas as empresas, a importância e necessidade de se utilizar e aprimorar o processo de arquitetura de 
software, trazendo maturidade e qualidade para os processos arquiteturais. 
Objetivos 
• Apresentar o conceito de Arquitetura de Software; 
• Apresentar as principais estruturas e características da disciplina; 
• Apresentar o conceito de padrões arquiteturais; 
• Introduzir o leitor nos principais caminhos de utilização e definição da Arquitetura de Software. 
TÓPICOS DE ESTUDO 
Arquitetura de software 
// Requisitos não funcionais 
// O papel do arquiteto de software 
// Recuperação arquitetural de software 
// Erosão arquitetural 
Conectores arquiteturais 
Visões arquiteturais 
// A UML 
// Tipos de visão e suas utilizações 
Padrões arquiteturais de software 
// Cliente-servidor (client-server) 
// Arquitetura multi-camadas (multilayered) 
// Dutos e filtros (pipes and filters) 
// Microsserviços (Microservices) 
// Arquitetura orientada a Serviços (SOA) 
// Barramento de serviços (ESB) 
// Padrão do quadro negro (blackboard pattern) 
// Padrão ponto-a-ponto (peer-to-peer pattern) 
// Modelo MVC (mvc pattern) 
Arquitetura de software 
A arquitetura de software é um conceito que vem sendo muito discutido na última década pelo meio relacionado ao desenvolvimento de 
software, muito embora o conceito permeie os profissionais desta área bem antes disso. 
Muitas vezes, quando começamos o trabalho em uma aplicação legada, ou até mesmo quando utilizamos uma solução, sentimos alguns 
desconfortos com algumas de suas características. Esse sentimento se trata de um alerta natural que, muitas vezes, pode indicar uma falha 
arquitetural no software. 
A arquitetura de software tem como princípio a estruturação de soluções que possibilitam o atendimento de todos os requisitos técnicos e 
operacionais definidos pelo requerente. Tais requisitos buscam otimizar outras características importantes presentes nas soluções de 
software, representados, em sua maioria, pelos requisitos não funcionais (performance, segurança, disponibilidade, etc.). 
Além disso, a arquitetura de um software busca definir e agrupar o conjunto de decisões técnicas e estruturais que irão permear a confecção 
dos componentes de software. Junto a isto, utiliza-se um mapeamento do impacto que cada decisão terá na solução final. 
ASSISTA: Assista à palestra ministrada por André Paulovich, em um evento sobre Arquitetura de Software. Nesta palestra, ele fala sobre a 
importância de se pensar a arquitetura e sobre como a montagem e evolução da arquitetura no ciclo de vida de um software são importantes. 
REQUISITOS NÃO FUNCIONAIS 
Como vimos até este momento, podemos identificar a importância de se utilizar a arquitetura de software no desenvolvimento de softwares 
complexos e de grande porte. Essa importância é facilmente identificada em casos como o desenvolvimento de linhas de produção, nos quais 
um conjunto de estilos, prerrogativas arquiteturais e funcionalidades são utilizados como base nas arquiteturas de softwares. Entretanto, 
antes mesmo do design da arquitetura e de sua definição, temos um player importante a ser considerado, denominados requisitos não 
funcionais. 
Durante a fase de levantamento dos requisitos do sistema, o arquiteto de software utiliza seus conhecimentos e sua experiência para 
recuperar requisitos e identificar as características que não são consideradas diretamente funcionais, ou ligadas a uma funcionalidade de 
negócio. Basicamente, esse tipo de requisito não informa o que o sistema deve fazer, mas sim como ele deve realizar essas ações e 
funcionalidades. 
Alguns exemplos de requisitos não funcionais que são importantes em grande parte das soluções de software são: 
MANUTENBILIDADE 
É um dos conceitos mais entrelaçados com a arquitetura de um software, pois a definição da arquitetura impacta diretamente no nível de 
dificuldade que um sistema tem em ser corrigido em caso de um bug ou de uma nova implementação. 
COFIABILIDADE 
Este conceito abrange vários tipos de métricas que auxiliam a medir se o sistema é capaz de se manter em execução sem apresentar falha, 
dado um período de tempo definido. 
PERFORMANCE 
O conceito de performance é um dos mais importantes e normalmente está presente como requisito obrigatório em todos os softwares 
desenvolvidos. Sua principal característica é garantir que o software tenha um bom tempo de resposta/processamento nas funcionalidades do 
sistema, principalmente nas funcionalidades críticas. Dentre as métricas normalmente acompanhadas, estão: latência, capacidade de 
throughput, tempo de resposta e velocidade de processamento. 
USABILIDADE 
Este conceito envolve o trabalho em projetar um sistema/solução no qual o usuário tenha a facilidade de utilizá-lo, tornando agradável o seu 
uso. 
Outros requisitos não funcionais são muito importantes também, tais como segurança, interoperabilidade, testabilidade e outros. 
Outros requisitos não funcionais são muito importantes também, tais como segurança, interoperabilidade, testabilidade e outros. 
O PAPEL DO ARQUITETO DE SOFTWARE 
No desenvolvimento de softwares, é necessário levar em consideração três tipos de informações/requisitos para que se possa desenvolver 
uma solução de software: 
• Requisitos de negócio; 
• Requisitos de usuário; 
• Requisitos não funcionais. 
Pensando neste ponto, é necessário que haja um ou mais profissionais da área de desenvolvimento que tenha a capacidade e a expertise de 
trabalhar com todos os requisitos necessários. Esse papel é desempenhado pelo arquiteto de software. 
O arquiteto de software deve levar em consideração os três tipos de requisitos ao realizar o design da arquitetura e o mapeamento das 
decisões e tecnologias utilizadas. A Figura 1 demonstra a variação e o entrelaçamento desses requisitos. 
 
Figura 1. Entrelaçamento de requisitos. 
O arquiteto de software tem a responsabilidade de desenvolver uma arquitetura viva e evolutiva, com capacidade de suportar as necessidades 
do cliente. Desse modo, ele deve refletir bem sobre as decisões técnicas relacionadas ao hardware, componentes externos e outros recursos 
que possam ser importantes para o desenvolvimento da solução. Seguindo o processo evolutivo e incremental, o arquiteto de software pode 
criar sua primeira versão da estrutura arquitetural a ser utilizada, provendo detalhes de mais alto nível que, posteriormente, serão 
incrementados e detalhados. 
Ao final do trabalho do arquiteto de software, ele produz alguns artefatos importantes que irão permear o desenvolvimento do software, tais 
como: 
• Documentação arquitetural (em maior ou menor nível de detalhe, dependendo do projeto, metodologia e necessidade); 
• Definição dos atributos de qualidade a serem seguidos; 
• Requisitos de segurança; 
• Plano de implantação; 
• Documento de padrões técnicos de desenvolvimento; 
• Plano de testes.RECUPERAÇÃO ARQUITETURAL DE SOFTWARE 
Dentro da disciplina da arquitetura de software, vemos cenários dos quais é necessário extrair a arquitetura de um software legado para que 
se possa entender tanto sua estrutura quanto o modo como ele foi concebido. 
A recuperação de arquiteturas (ou arqueologia arquitetural) é um viés da disciplina de arquitetura de software que permite ao arquiteto 
realizar tal tarefa. Sua metodologia é composta por um conjunto de métodos para a extração de diversas informações arquiteturais, com 
representações da aplicação de mais baixo nível (como o código-fonte). 
Muitas vezes o processo de extração desses elementos arquiteturais envolve o agrupamento de partes do código-fonte em partes menores 
(subsistemas), seguindo um conjunto de definições e critérios que definem o escopo e tamanho de cada parte. Isso ocorre porque nesses 
sistemas legados normalmente a documentação arquitetural é ausente ou está desatualizada em relação ao que está implementado no 
sistema. 
Para realizar este tipo de análise e executar a recuperação da arquitetura, é utilizada, na maioria dos casos, a análise estática de sistemas 
(static analysis of systems), que consiste em realizar a análise do sistema sem executar a aplicação. A engenharia reversa e as métricas de 
software são formas de realizar essa análise estática. 
Outra forma de se realizar essa recuperação é utilizando análise dinâmica de sistemas (dynamic analysis of systems). Neste caminho, 
normalmente utilizado em sistemas baseados em orientação por objetos, a análise é realizada na execução da aplicação, observando seu 
comportamento durante este período. 
Alguns tipos de implementações da análise dinâmica são: 
• Cobertura de código (Code Coverage); 
• Detecção de erros de memória; 
• Erros de concorrência; 
• Análise de performance. 
Para todos os cenários, a utilização de ferramentas é necessária para a aquisição de dados e sua posterior análise. Um exemplo seria a 
utilização da ferramenta PurifyPlus, da Pure Software, para análise de memória, ou o Jmeter, para avaliação de performance. 
EROSÃO ARQUITETURAL 
Nesta parte da disciplina de arquitetura de software, o objetivo é identificar o gap entre o que foi inicialmente planejado e o que foi realizado 
em sua implementação. A erosão arquitetural ocorre quando a implementação viola as regras e decisões definidas no design da arquitetura ou 
na implementação parcial de algum requisito. Este gap identificado entre o planejado e o implementado é chamado de débito técnico 
(Technical Debt). 
Basicamente, podemos utilizar duas técnicas para identificar as violações arquiteturais: 
• Modelos de reflexão (Reflection Models): técnica que compara um modelo arquitetural disponibilizado pelo arquiteto de software 
com o código-fonte implementado; 
• Linguagens de domínio (Domain Languages): tipo de linguagem com abordagem específica para identificar as violações 
arquiteturais. Linguagens de domínio são específicas para um domínio de negócio, por exemplo: 
• MATLAB: linguagem para programação de matrizes; 
• MAPLE: linguagem para matemática simbólica; 
• SQL: linguagem para banco de dados relacionais. 
Como falado por De Silva & Balasubramaniam et. al., 
Essas abordagens, que incluem ferramentas, técnicas e processos, são principalmente classificadas em três categorias gerais que tentam 
minimizar, prevenir e reparar a erosão da arquitetura. Dentro dessas categorias amplas, cada abordagem é subdividida refletindo as 
estratégias de alto nível adotadas para combater a erosão. Estas são a conformidade com a arquitetura orientada a processos, gerenciamento 
de evolução de arquitetura, aplicação de projeto de arquitetura, arquitetura para implementar integração, técnicas de auto-adaptação e 
restauração de arquitetura, consistindo em recuperação, descoberta e reconciliação (DE SILVA; BALASUBRAMANIAM, 2012, tradução livre). 
Desse modo, é possível ver que vários diferentes tipos de abordagens foram propostos para auxiliar na solução de problemas e cenários 
relacionados à erosão de arquitetura de software. 
DICA 
Um dos melhores livros sobre arquitetura é o livro Software Architecture in Practice – 2nd Edition, do escritor Len Bass. Este livro também é 
conhecido como Yellow Book Of Software Architecture. 
Conectores arquiteturais 
Dentro do universo da arquitetura de software, temos a necessidade de realizar “conexões” com elementos externos a fim de garantir o fluxo 
da informação e das ações necessárias para que o sistema funcione corretamente. Neste contexto, utilizamos o conceito de conectores, que 
tem por definição a capacidade de realizar a transferência de controle e dados entre as partes. 
Com a utilização de conectores, os arquitetos podem realizar a integração entre elementos heterogêneos que fazem parte da 
macroarquitetura da solução, onde estas peças externas podem ter sido desenvolvidas em tecnologias e momentos diferentes. Desta forma, 
os conectores permitem aos arquitetos e ao sistema coexistirem com componentes legados e em diferentes tecnologias. 
Algumas características que indicam o que os conectores podem fazer são: 
• Realizar a distribuição de requisições entre componentes específicos; 
• Realizar o broadcast de notificações de eventos para componentes que possam escutar esse tipo de evento; 
• Realizar o controle transacional de processamento entre as partes, utilizando bloqueio síncrono (por meio de notificações de ACK) ou 
não; 
• Roteamento das requisições entre as partes; 
• Realizar o enriquecimento do contexto da requisição por meio de regras previamente definidas. 
Basicamente, podemos definir os conectores em simples e compostos. Os conectores simples normalmente fazem sua lógica utilizando dutos 
de comunicação simples entre as partes. Alguns componentes podem enriquecer esses conectores, introduzindo alguns controles de dados 
simples aos dutos. Os conectores mais complexos podem introduzir uma arquitetura interna para processamento e armazenamento mais 
elaborados da informação. Um exemplo que se pode utilizar é um conector de balanceamento de carga, que realiza o balanceamento da carga 
com base na utilização dos componentes. 
Os conectores simples disponibilizam apenas um tipo de serviço/funcionalidade, enquanto os conectores compostos podem agrupar outros 
conectores e componentes, proporcionando um poder maior para cumprir os requisitos e necessidades mais complexas. Os componentes 
compostos, devido à sua estrutura e complexidade, são disponibilizados como bibliotecas, ou até mesmo como frameworks. 
Um conector, independentemente de qual tipo, deve disponibilizar suas características por meio de serviços de interação. 
Os tipos disponíveis são: 
Comunicação 
Disponibilizam suporte à transmissão de dados entre componentes, utilizando blocos simples para a interação entre os componentes. Como 
exemplo podemos citar os dados simples de mensagens textuais e os resultados de processamento computacional; 
Coordenação 
Neste tipo de serviço, o suporte à transferência de controle entre os componentes é disponibilizada e a thread de execução é “trocada” entre 
as partes. As chamadas RPC são um exemplo deste tipo de serviço; 
Conversão 
Serviços deste tipo permitem a interação entre componentes heterogêneos que, inicialmente, não são compatíveis. As incompatibilidades são 
normalmente causadas por uma divergência no tipo, na ordem ou na estrutura dos dados. Um exemplo clássico é a utilização de conectores 
ETL ou de conectores que realizam wrappers de componentes legados. 
Facilitação 
Este tipo de serviço visa realizar a mediação entre os componentes que fazem a interação. Em alguns cenários, essa mediação é necessária 
para aprimorar a gestão dos dados e reduzir a interdependência entre as partes. Exemplo disto são os conectores de balanceamento de carga 
e de controle de processos. 
Dependendo da complexidade da ação e interação entre os componentes, a combinaçãode mais de um conector (ou serviço) pode ser 
necessária. 
Depois de entendermos os tipos de serviços disponibilizados pelos conectores, é necessário entendermos como os conectores são classificados 
da forma como os serviços são realizados. Os tipos utilizados para esta classificação são: 
• Procedure call; 
• Event; 
• Data Access; 
• Linkage; 
• Stream; 
• Arbitrator; 
• Adaptor; 
• Distributor. 
// Procedure call 
Estes tipos de conectores, realizam a modelagem do fluxo de controle entre os componentes (coordenação) e possuem a capacidade de 
realizar a transferência de dados entre os componentes através de parâmetros e valores de retorno (comunicação). 
São conhecidos como call-backs e são amplamente utilizados em componentes que realizam Remote Procedure Call (RPC). 
 
Diagrama 1. Conectores Procedure Call. Fonte: TAYLOR, 2009, p. 166. (Adaptado). 
// Events 
Neste caso, o fluxo de controle é disparado por um evento ocorrido, que é identificado pelo conector que irá gerar mensagens para os 
ouvintes. Este tipo de conector realiza a criação de “conectores virtuais”, que são gerados dinamicamente. 
 
Diagrama 2. Conectores Event. Fonte: TAYLOR, 2009, p. 167. (Adaptado). 
// Data access 
Neste tipo de conector, temos a possibilidade de interagir com componentes de armazenagem de dados (Data Stores), de forma temporária 
ou persistente. 
 
Diagrama 3. Conectores Data Access. Fonte: TAYLOR, 2009, p. 168. (Adaptado). 
// Linkage 
São conectores utilizados para unir componentes e mantê-los durante toda a duração de sua interação. Estes conectores criam canais de 
comunicação que são utilizados por outros tipos e conectores (facilitação). 
 
Diagrama 4. Conectores Linkage. Fonte: TAYLOR, 2009, p. 169. (Adaptado). 
// Stream 
Este tipo de conector é utilizado quando há a necessidade de se transferir uma grande quantidade de dados ou em transmissões de soluções 
cliente-servidor para entregar informações entre as partes. Um exemplo clássico são os pipes do UNIX e os sockets de comunicação TCP/UDP. 
 
Diagrama 5. Conector Stream. Fonte: TAYLOR, 2009, p. 170. (Adaptado). 
// Arbitrator 
Este conector tem a capacidade de resolver situações de conflito (facilitação) e de controle de fluxo (comunicação) em cenários nos quais a 
presença e outras partes são conhecidas por um componente, mas não há garantias sobre o estado das partes. Um exemplo comum deste tipo 
de conector são os balanceadores de carga e escalonamento. 
 
Diagrama 6. Conector Arbitrator. Fonte: TAYLOR, 2009, p. 171. (Adaptado). 
// Adaptor 
Esse tipo de conector tem uma finalidade muito clara: permitir a interação entre componentes que, originalmente, não são compatíveis ou 
não foram desenhados para serem convertidos. Um exemplo de conectores do tipo adapter são os frameworks ORM, ou os componentes de 
ETL em service bus. 
 
Diagrama 7. Conector Adaptor. Fonte: TAYLOR, 2003, p. 171. (Adaptado). 
// Distributor 
Estes tipos de conectores possuem a característica de mapeamento dos paths presentes na interação e o roteamento de informações de 
objetos durante o processo de comunicação (facilitação). Normalmente, esse tipo de conector coexiste com outros conectores, como Stream 
e/ou Procedure Call, para enriquecer seu funcionamento. Um exemplo clássico deste tipo de conector são os serviços de DNS. 
 
Diagrama 8. Conector Distributor. Fonte: TAYLOR, 2009, p. 172. (Adaptado). 
Visões arquiteturais 
Dentro do contexto da arquitetura de software, é necessário existir uma forma de representar a arquitetura para que ela seja compreensível e 
explicável. Pensando nessa necessidade, a arquitetura de software foi dividida em visões arquiteturais. 
Cada visão arquitetural irá lidar com um conjunto específico de informações e interesses envolvidos no processo de desenvolvimento. 
Basicamente, pode-se dizer que essas visões da arquitetura tentam capturar as principais decisões ligadas ao design, apresentando sua 
decomposição em componentes e a interação entre eles, utilizando conectores e formulários úteis. 
A UML 
Atualmente, existem algumas opções para representar essas visões a fim de facilitar sua confecção e compartilhamento entre as partes. Uma 
das formas mais utilizadas para isso é a linguagem de modelagem chamada UML (Unified Modeling Language). 
A UML é uma linguagem de notação que expressa, por meio de diagramas, as informações que se deseja expor. Esses diagramas podem ter 
relação entre si ou não. A UML é uma linguagem baseada nos princípios da orientação por objetos e utiliza essa prerrogativa para expor seus 
diagramas. 
A seguir, é possível conhecer alguns conceitos fundamentais do mundo orientado a objetos e utilizados na UML: 
Objetos 
Entidades dentro dos diagramas que são consideradas o bloco de construção básico a ser utilizado; 
Classes 
Representação visual de objetos dentro dos diagramas; 
Abstração 
Representa o comportamento de uma entidade no mundo real; 
Encapsulamento 
É uma forma de prover acesso a informações importantes, protegendo-as do acesso exterior; 
Herança 
Criação de novas classes utilizando comportamentos e propriedades já existentes em outras classes; 
Polimorfismo 
Permite que, dentro de uma hierarquia, classes em mais alto nível possam trocar seu comportamento à medida que sua instância interna 
(objeto carregado) referencie uma classe diferente. 
A UML se tornou um ativo importante na arquitetura de software, pois ela permite expressar as diversas visões de uma arquitetura por meio 
de diagramas. 
Os principais diagramas que podemos utilizar da UML e os tipos de modelagem suportados são: 
• Modelagem Estrutural 
• Diagrama de Classes – nesse diagrama são definidas as estruturas de classes e seus relacionamentos. Além disso, são mapeadas as 
propriedades e os métodos associados a cada classe a fim de melhorar o entendimento das informações. É o diagrama mais utilizado 
e serve como guia para outros diagramas. 
• Diagrama de Objetos – este diagrama funciona como um snapshot de um momento de execução de um determinado processo do 
software e seus valores armazenados pelos objetos. Ele funciona como um complemento do diagrama de classes. 
• Diagrama de Implantação – este tipo de diagrama traz para a arquitetura uma visão estrutural sobre as necessidades físicas 
(hardware) necessárias para o software. Com ele, conseguimos obter informações como protocolos utilizados, servidores e outros. 
• Diagrama de Componente – este tipo de diagrama proporciona uma visão geral dos componentes que serão implementados pelo 
sistema e como eles serão distribuídos em sua estrutura. Ele está fortemente ligado ao tipo de tecnologia utilizado. Além disso, ele 
apresenta a visão das interações entre os componentes e suas estruturas. 
• Modelagem Comportamental 
• Diagrama de casos de uso – o diagrama de casos de uso é, normalmente, um dos primeiros diagramas a serem construídos, pois são 
realizados nas fases de levantamento e análise de requisitos. Eles representam a visão das interações entre cenários e atores do 
sistema e servem de base para vários outros diagramas. 
• Diagrama de sequência – o diagrama de sequência é a representação temporal de um conjunto de eventos ocorridos em um 
determinado cenário do sistema, normalmente expresso inicialmente em um caso de uso. 
• Diagrama de colaboração – esse diagrama é um complemento do diagrama de sequência onde sua maior preocupação é com os 
eventos de vinculação entre os componentes e os tipos de mensagens trocadas entre eles durante o processo. 
• Diagrama de atividade – esse diagrama tem como principal objetivo mapear e demonstrar, de forma direta e simples, todos os 
passos necessários para que uma atividade do sistema seja executada. 
• Diagrama de estado – esse diagrama tem o foco é um determinado componente do sistema e visa demonstrar o conjunto de 
estados pelo qual este componente passa dentro do sistema. 
TIPOS DE VISÃO E SUAS UTILIZAÇÕES 
Uma das formasmais conhecidas de se representar as visões de uma arquitetura de software é a 4+1. Ela foi, inclusive, base do processo RUP 
e é muito utilizada nas definições, nas estruturas arquiteturais e nas documentações provenientes da criação da arquitetura de software. 
Este modelo de visão arquitetural, como o próprio nome indica, é dividido em 4 tipos de visões: lógica, processo, desenvolvimento e física. O 
que representa o “+1” é uma visão de sumarização, que ilustra de forma objetiva os cenários mais importantes e críticos, baseando-se em 
pequenos conjuntos de casos de uso. Essa última visão é muito utilizada para validação do design arquitetural e para um entendimento macro 
dos cenários mais críticos e/ou importantes. 
 
Figura 2. Visão "4+1". 
// Visão lógica (Logical View) 
Essa visão tem como objetivo primário representar os requisitos comportamentais. Em outras palavras, ela basicamente mostra os serviços 
fornecidos aos usuários finais. Os arquitetos de software ou os analistas de projetos decompõem o sistema em abstrações, baseando-se no 
conjunto de domínio do problema ou cenário. Essa visão, além de auxiliar na análise de negócio (funcional), permite a identificação de 
elementos dentro do projeto que podem se tornar comuns ao longo do ciclo de vida do sistema. 
Os diagramas UML associados a esta visão incluem: 
• Diagrama de classes; 
• Diagrama de estado; 
• Diagrama de objetos; 
• Diagrama de sequência; 
• Diagrama de colaboração/comunicação. 
// Visão de processo (Process View) 
Essa visão permite o entendimento de como os processos do sistema interagem com os componentes existentes, sua resiliência e tolerância a 
falhas. Neste tipo de visão, é possível identificar as possíveis threads de execução de um cenário e ver a interação entre o possíveis caminhos 
que irão ser executados. 
O diagrama UML que representa a visão de processo é o diagrama de atividades. 
// Visão de desenvolvimento (Development View) 
Essa visão foca na organização modular da aplicação, na qual os elementos são pequenas partes do software, podendo ser bibliotecas ou 
subsistemas, que poderão ser desenvolvidos por múltiplos profissionais. Além disso, ela proporciona a capacidade de avaliar o custo de 
produção, monitoração do progresso e visão da reutilização de código. 
Um dos diagramas que faz parte desta visão é o diagrama de componentes. 
// Visão física (Physical View) 
Essa visão possui uma integração maior com os requisitos não funcionais e com as características relacionadas à qualidade do software, 
mapeando os vários elementos identificados nas outras visões em nós de processamento. 
O diagrama UML que representa a visão deste processo é o diagrama de implantação. 
Padrões arquiteturais de software 
Os padrões arquiteturais são soluções já comprovadas e comumente utilizadas para problemas recorrentes no desenvolvimento de uma 
arquitetura de um software. Vários destes padrões arquiteturais se tornaram verdadeiros coringas nas mãos dos arquitetos de software, mas é 
importante analisar bem a aderência do padrão escolhido junto ao cliente. 
A escolha de um padrão arquitetural está entre uma das primeiras decisões a serem tomadas quando se está desenvolvendo uma arquitetura 
de software. Os padrões arquiteturais auxiliam o arquiteto de softwares a definir: 
• O possível conjunto de subsistemas; 
• Suas responsabilidades; 
• Suas regras de relacionamento e integração. 
Mesmo que os padrões se provem úteis e essenciais, eles não são responsáveis pela definição completa da arquitetura de um sistema. Os 
padrões devem ser utilizados como templates, moldes a serem utilizados e refinados no desenvolver da arquitetura da solução em questão. 
Dentre estes refinamentos, podemos incluir novos componentes e integrações, novos padrões de projetos e modelos de conversação. 
Ao se escolher um padrão de projeto, deve-se levar em consideração os seguintes fatores: 
• Requisitos não funcionais; 
• Perfil do sistema a ser desenvolvido; 
• Expertise da equipe de desenvolvimento. 
Neste caso, se torna interessante mapear algumas perguntas iniciais para auxiliar no entendimento. Alguns exemplos de perguntas são: 
• Quais são os principais requisitos não funcionais de acordo com a visão do cliente? 
• Qual a expertise técnica do time de desenvolvedores e testadores? 
• O sistema possui muitas interações externas? 
• O sistema deve suportar multithreading ou processamento distribuído? 
Atualmente, temos uma gama interessante de padrões de projeto já concretizados no mercado. A seguir, iremos falar dos principais deles e 
como eles podem ser úteis no desenvolvimento de uma arquitetura de software. 
CLIENTE-SERVIDOR (CLIENT-SERVER) 
Este é, provavelmente, o padrão mais conhecido dentre todas as opções disponíveis. Este padrão tem como característica a apresentação do 
relacionamento entre componentes (programas) dentro de uma aplicação. Neste caso, o componente servidor irá expor uma funcionalidade 
ou um tipo de serviço que será consumido por um ou mais componentes clientes. 
Neste tipo de padrão arquitetural, as funcionalidades são abstraídas entre o servidor e o cliente, de forma que o cliente não precisa saber 
como a funcionalidade é executada no servidor, ele precisa apenas interpretar o retorno da funcionalidade. Normalmente, o cliente e o 
servidor realizam a troca das mensagens por meio de um processo atômico chamado request-response message pattern. 
Um servidor tem a capacidade de suportar múltiplas conexões de vários clientes diferentes, mas isso é limitado pelo poder de processamento 
do computador/servidor que está hospedando a aplicação server side. Vendo este cenário, é muito comum que o servidor realize o controle da 
quantidade de clientes que podem interagir com ele, evitando, assim, a exaustão de recursos computacionais para o processamento server 
side e, posteriormente, a sua indisponibilidade. 
ARQUITETURA MULTICAMADAS (MULTILAYERED) 
Basicamente, podemos dizer que arquiteturas multicamadas são arquiteturas do tipo cliente-servidor nas quais as camadas de apresentação, 
aplicação e dados são fisicamente separadas. O uso mais comum e popular deste tipo de arquitetura se aplica em arquiteturas de 3 camadas 
ou n-camadas. 
Aplicações multicamadas se propõem a flexibilizar a criação de arquiteturas com maior propensão de reuso de seus componentes. Com a 
segregação da aplicação em camadas distintas, os profissionais de desenvolvimento têm a opção de trabalhar as camadas de forma 
independente, reduzindo o retrabalho em mudanças e implementações realizadas. 
Voltando a falar de aplicações que utiliza o padrão de três camadas, um dos pontos importantes que vale a pena ressaltar são as camadas que 
compõem este tipo de padrão: 
Camada de apresentação: É a camada que representa a interface gráfica da aplicação, ou GUI, responsável pela interação direta com o usuário 
e por onde as requisições dos usuários são realizadas. 
Camada de negócio: É responsável por realizar as regras de negócio que contemplam o núcleo do sistema, bem como as lógicas de 
direcionamento e tratamento de informações relacionadas ao negócio. 
Camada de dados: é responsável por receber as requisições oriundas da camada de negócio e persistir/recuperar as informações requisitadas 
de uma estrutura de dados persistente. Normalmente, esta estrutura de dados persistente é um banco de dados, mas podem ser utilizadas 
outras estruturas. 
DUTOS E FILTROS (PIPES AND FILTERS) 
Esse tipo de padrão de arquitetura é peculiar, pois sua estrutura é composta por uma cadeia de elementos de processamento, posicionados de 
forma que a saída de cada componente seja a entrada do próximo. Esse perfil de montagem traz a característica de rede para o 
processamento dos dados para quem adota este tipo de padrão arquitetural. 
Ainda neste tipo de padrão, os dutos (pipes) são os responsáveis por transportar a informação, enquanto os filtros (filters) se responsabilizam 
pelo processamentodesta informação e a direcionam para os próximos dutos do fluxo. Desta forma, conseguimos identificar que esse padrão 
é interativo e que a regra essencial é que um duto não pode se conectar a outro duto diretamente, apenas por meio dos filtros. 
A utilização desse tipo de padrão vem muito em conjunto com a ideia de segregação das funcionalidades de um sistema. Neste caso, a ideia é 
particionar processos mais complexos, em pedaços menores, em sequências de processamentos mais simples e reduzidos, conectados pelos 
dutos e filtros do padrão de arquitetura tratado nesta parte. 
MICROSSERVIÇOS (MICROSERVICES) 
Este padrão de arquitetura vem sendo cada vez mais comentado e adotado por arquitetos e empresas devido à sua estrutura. Neste tipo de 
arquitetura, ocorre a quebra da aplicação em uma coleção de serviços de baixo acoplamento, possibilitando serviços de granulagem fina e com 
protocolos de comunicação leves. Uma das grandes vantagens deste tipo de abordagem é que a quebra em serviços menores aumenta a 
modularidade do sistema. Dessa forma, a manutenção se torna mais fácil, os serviços são mais fáceis de entender e a adoção de implantação 
contínua se torna mais fácil. 
Ao se trabalhar com a arquitetura de microsserviços, é importante termos alguns guidelines para auxiliar no caminho a ser trilhado na 
utilização deste padrão arquitetural. Algumas ações importantes que podem ser consideradas são: 
• Tenha certeza que os serviços foram desenhados e desenvolvidos de modo que eles possam ser implantados individualmente, 
• Cada serviço desenvolvido deve atender apenas a uma funcionalidade, 
• A comunicação entre os microsserviços deve ser feita, preferencialmente, por servidores que não armazenam estado (stateless). 
Como todo padrão arquitetural, a estrutura de microsserviços possui suas vantagens e desvantagens. No quadro 1 é possível ver um 
comparativo entre estas características. 
ASSISTA 
Assista à apresentação de Martin Fowler, Microservices, sobre o padrão arquitetural dos microsserviços e veja quais são suas principais 
características e como é sua estrutura. 
 
Quadro 1. Vantagens e desvantagens dos microsserviços. 
ARQUITETURA ORIENTADA A SERVIÇOS (SOA) 
Esse tipo de arquitetura é baseado no conceito em que serviços são disponibilizados para outros componentes por meio de um protocolo de 
comunicação sobre uma rede. Os princípios básicos deste tipo de arquitetura é sua independência de provedor tecnológico e de produtos. Um 
serviço nada mais é do que uma unidade de implementação relacionada a uma funcionalidade que pode ser acessada remotamente e 
atualizada de forma independente. 
Basicamente, um serviço implementado neste padrão arquitetural, possui quatro propriedades, que seguem as definições da especificação 
SOA (BELL, 2008): 
• O serviço representa uma funcionalidade de negócio específica com uma resposta específica; 
• O serviço deve ser autocontido; 
• Para os clientes que o consome, sua estrutura é uma caixa-preta; 
• Internamente, ele pode ser composto de outros serviços para atender a funcionalidade requisitada. 
 
Figura 3. Estrutura SOA. Fonte: Shutterstock. Acesso em: 11/07/2019. 
O padrão arquitetural SOA visa promover a integração entre três partes fundamentais no desenvolvimento de software: o negócio, a 
tecnologia e os serviços. A adoção deste padrão pode trazer alguns benefícios, tais como: 
• Agilidade no atendimento de novas features a serem desenvolvidas; 
• Maior flexibilidade para a adequação às mudanças que podem ocorrer; 
• Redução dos custos, pois facilita a manutenibilidade; 
• Aumenta a possibilidade de reuso de componentes e serviços. 
BARRAMENTO DE SERVIÇOS (ESB) 
Dentro do padrão arquitetural SOA, uma das partes importantes é o ESB (Enterprise Service Bus). O ESB tem como funcionalidade atuar na 
intermediação de serviços expostos, provendo conectores e estruturas que permitam vários tratamentos e lógicas nas informações que serão 
intermediadas por ele, tais como: 
• Enriquecimento da informação; 
• Roteamento; 
• Transformação da informação (muito usado com ETL’s); 
• Validações. 
Um erro muito comum em relação aos ESBs é associar a sua existência ao SOA ou afirmar que apenas o fato de utilizar o software já utiliza o 
padrão orientado a serviços. O que ocorre com o barramento é que o mesmo possui em sua origem várias implementações e estruturas que, 
naturalmente, suportam um conjunto considerável de conceitos e funcionalidades do SOA. 
PADRÃO DO QUADRO NEGRO (BLACKBOARD PATTERN) 
Este é um tipo de padrão arquitetural que tem sua utilidade muito voltada para problemas nos quais nenhuma solução determinística foi 
encontrada. Sua utilização é muito comum nas seguintes situações: 
• Reconhecimento de fala necessário; 
• Identificação de tráfego em veículos; 
• Identificação de cadeias proteicas; 
• Interpretação autônoma de sinais de sonar. 
PADRÃO DO QUADRO NEGRO 
Blackboard: Memória global estruturada que mapeia todos os objetos usados na solução. 
Knowledge Source: Módulos especializados com suas próprias representações/implementações. 
Control Component: Responsável por selecionar, configurar e executar os módulos. 
PADRÃO PONTO-A-PONTO (PEER-TO-PEER PATTERN) 
Este padrão representa uma arquitetura distribuída que tem como princípio a quebra de tarefas ou atividades de trabalho entre os pontos da 
estrutura. Os pontos (peers) possuem um perfil de equivalência estrutural e são todos participantes da aplicação. Desse modo, é formada uma 
rede de nós de um ponto para outro. 
Uma rede ponto-a-ponto é definida a partir da noção de que todos os pontos devem ser equivalentes e devem funcionar como clientes e 
servidores ao mesmo tempo. Nesse sentido, o direcionamento da comunicação entre os nós se torna bidirecional. 
 
Figura 4. Estrutura Peer-to-Peer. Fonte: Shutterstock. Acesso em: 10/07/2019. 
A Figura 4 mostra que os nós dentro da rede ponto-a-ponto interagem entre si com pares, executando o papel de cliente e servidor ao mesmo 
tempo. Uma coisa importante dentro desta arquitetura é a forma como os nós são localizados. Neste contexto, é criada uma camada virtual de 
rede, chamada overlay network, sobre a camada física, e os nós usam uma estratégia de links para se identificarem e realizarem a 
comunicação. Esta overlay network é usada para indexar os nós e para descobrir os pontos disponíveis. 
MODELO MVC (MVC PATTERN) 
A arquitetura MVC (Model-View-Controller) é um padrão arquitetural que tem como maior característica definir uma clara separação entre as 
camadas de visão do usuário, controle e modelos utilizados. Como padrão arquitetural, seu uso é mais frequente no desenvolvimento de 
interfaces de usuários mais elaboradas, permitindo maior controle entre as informações internas utilizadas e as representações expostas ao 
usuário. 
Basicamente, esta abordagem realiza a separação destes componentes em três tipos: 
• Modelo (Model): são as regras de negócio, lógicas, funções e os dados da aplicação. 
• Visão (View): representação das visões para o usuário, como tabelas, diagramas ou formulários. 
• Controlador (Controller): lógica responsável pela mediação entre a camada de visão e a camada de modelo. Neste ponto, podemos 
ter ações de transformação e enriquecimento de dados. 
 
Diagrama 9. Estrutura MVC. 
VANTAGENS DO MODELO MVC: 
• Fácil manutenção, pois o MVC pode gerenciar várias visões com o mesmo modelo; 
• A aplicação é mais escalável, pois a separação flexibiliza isso; 
• Aumenta a reutilização do código; 
• Possibilita o desenvolvimento em paralelo e reduz a interdependência entre as partes; 
• Melhor performance, pois a separação de camadas reduz o peso de processamento e a quantidade de código nas camadas. 
DESVANTAGENS DO MODELO MVC: 
• Maior tempo para navegar no código e entender as ligações; 
• Maior especialização do profissional; 
• Com o aumento do tamanho do software e sua complexidade, aumenta também a complexidade da estruturaMVC, bem como dos arquivos 
relacionados a ele e suas pastas. 
Por fim, várias tecnologias implementam este modelo arquitetural em seus frameworks, a fim de aproveitar seus benefícios e características. 
Alguns exemplos são: 
• Java 
 • Java Server Faces (JSF) 
 • Spring MVC 
 • VRaptor 
• .NET 
 • ASP.NET MVC 
• PHP 
 • Laravel 
 • Symfony 
 
Agora é a hora de sintetizar tudo o que aprendemos nessa unidade. Vamos lá?! 
SINTETIZANDO 
Nesta unidade, tivemos a oportunidade de conhecer um pouco mais sobre as ferramentas de arquitetura de software com o objetivo de 
utilizá-las de forma efetiva e concisa no desenvolvimento de soluções. 
Aprendemos que a arquitetura é dividida em algumas partes e que suas visões possibilitam trabalhar diferentes pontos de vista em relação a 
sua estrutura e seudesign. Também vimos que dentro da arquitetura de software, há a opção de utilizar diferentes tipos de conectores para 
realizar a integração e a otimização de comunicação entre os diferentes tipos de componentes que compõem o ecossistema arquitetural. 
Entendemos que é necessário formas produtivas e simples de expressar as ideias e definições necessárias na arquitetura. Para isto, foi 
apresentado a UML, linguagem de notação que dispõe de uma série de diagramas realizadores deste trabalho de tradução das informações 
em um formato mais fácil e compreensível. 
Ainda dentro deste contexto arquitetural, foi possível visualizar a importância de se saber os tipos de padrões arquiteturais mais comuns. 
Assim sendo, vimos como a arquitetura de software é importante dentro do ciclo de vida de concepção e desenvolvimento de software e que 
sua utilização agrega, cada vez mais, qualidade e vantagens em sua adesão. 
REFERÊNCIAS BIBLIOGRÁFICAS 
ARQUITETURA DE SOFTWARE NUM CENÁRIO DE INCERTEZAS – ANDRÉ PAULOVICH. Postado por InfoQ. (44 min. 15 s.). son. color. port. 
Disponível em: <https://www.youtube.com/watch?v=bzUzndluD-M>. Acesso em: 16 jul. 2019. 
BASS, L.; CLEMENTS, P.; KAZMN, R. Software Architecture in Practice. 2. ed. Massachusetts: Editora Addison-Wesley Professional, 2003. 
BELL, M. Service-Oriented Modeling: Service Analysis, Design, and Architecture. Hoboken: Wiley & Sons, 2008. 
BOOCH, G; RUMBAUGH, J. UML – Guia do usuário. Rio de Janeiro: Editora Elsevier, 2006. 
BROOKS, J. F. The Mythical Man-Month – Essays on Software Engineering. Massachusetts: Addison-Wesley Professional, 1995. 
DE SILVA, L.; BALASUBRAMANIAM, D. Controlling software architecture erosion: A survey. Journal of Systems and Software, [s.l.], 2012, v. 85, 
n. 1, pp. 132-151. 
EBELING, C. E. An Introduction to Reliability and Maintainability Engineering. Boston: McGraw-Hill Companies, Inc, 1997. 
FOWLER, M. Patterns of Enterprise Application Architecture. Massachusetts: Addison-Wesley Professional, 2002. 
FOWLER, M.; & LEWIS, J. Microservices: a definition of this new architectural term. Martin Flower, 25 mar. 2014. Disponível em: 
<https://martinfowler.com/articles/microservices.html>. Acesso em: 05 jul. 2019. 
GOTO 2014 – MICROSERVICES – MARTIN FOWLER. Postado por GOTO Conferences. (26 min. 25 s.). eng. color. leg. Disponível em: 
<https://www.youtube.com/watch?v=wgdBVIX9ifA>. Acesso em: 16 jul. 2019. 
GUEDES, G. T. UML 2 - Uma Abordagem Prática. São Paulo: Editora Novatec, 2018. 
IEEE STANDARDS ASSOCIATION. IEEE Recommended Practice for Architectural Description. Nova Iorque: The Institute of Electrical and 
Electronics Engineers, Inc, 2000. Disponível em: <http://cabibbo.dia.uniroma3.it/ids/altrui/ieee1471.pdf>. Acesso em: 05 jul. 2019. 
KIWELEKAR, A. W. Architectural Connectors: Ph. D. Seminar Report. [s.l.], [s.d.]. Disponível em: 
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.99.9137&rep=rep1&type=pdf>. Acesso em: 05 jul. 2019. 
KRUCHTEN, P. The 4+1 view model of architecture. IEEE Software, [s.l.], v. 12, n. 6, 1995. 
NAUR, P.; RANDELL, B. Software Engineering – Report on a conference sponsored by the NATO SCIENCE COMMITTEE. Garmisch, Alemanha, 
out. 1968. Bruxelas: Scientific Affairs Division, 1969. Disponível em: <http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF>. 
Acesso em: 05 jul. 2019. 
NIELSEN, J. Usability 101: Introduction to Usability. NN/g Nielsen Norman Group, 04 jan. 2012. Disponível em: 
<https://www.nngroup.com/articles/usability-101-introduction-to-usability/>. Acesso em: 11/07/2019. 
PERRY, D. E.; WOLF, A. L. Foundations for the Study of Software Architecture. CM SIGSOFT Software Engineering Notes, Nova Iorque, 1992, v. 
17. N. 4, pp. 40-42. 
TAYLOR, R. N.; Software Architecture: Foundations, Theory and Practice. [s.l.]: Editora Wiley, 2009. 
TERRA, R. et al. Recommending Refactorings to Reverse Software Architecture Erosion. In: 16th European Conference on Software 
Maintenance and Reengineering, Szeged, Hungria, 2012. Disponível em: gsd.uwaterloo.ca: 
<http://gsd.uwaterloo.ca/sites/default/files/Full%20Text.pdf>. Acesso em: 05 jul. 2019. 
TODINOV, M. Reliability and Risk Models: setting reliability requirements. Chichester: John Wiley & Sons, 2016. 
https://www.youtube.com/watch?v=bzUzndluD-M
https://martinfowler.com/articles/microservices.html
http://cabibbo.dia.uniroma3.it/ids/altrui/ieee1471.pdf
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.99.9137&rep=rep1&type=pdf
http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF
https://www.nngroup.com/articles/usability-101-introduction-to-usability/
http://gsd.uwaterloo.ca/sites/default/files/Full%20Text.pdf
W3.ORG. Transport Message Exchange Pattern: Single-Request-Response. W3.org, 11 out. 2001. Disponível em: 
<https://www.w3.org/2000/xp/Group/1/10/11/2001-10-11-SRR-Transport_MEP>. Acesso em: 05 jul. 2019. 
WESCOTT, B. Every Computer Performance Book. [s.l.]: CreateSpace, 2013. 
 
https://www.w3.org/2000/xp/Group/1/10/11/2001-10-11-SRR-Transport_MEP
UNIDADE 1.2 - MODELAGEM E ANÁLISE ARQUITETURAL 
OBJETIVOS DA UNIDADE 
• Falar sobre o que é e como realizar a modelagem de arquiteturas; 
• Apresentar os processos para realizar a modelagem de software e suas técnicas; 
• Apresentar o que é e como pode ser realizada a análise de arquiteturas; 
• Apresentar técnicas iniciais e princípios para a realização da análise arquitetural. 
TÓPICOS DE ESTUDO 
Modelagem de arquiteturas 
// Conceitos de modelagem 
// Modelagem complexa 
// Técnicas de modelagem 
Análise de arquiteturas 
// Conceitos e abordagem 
// Formalidade e automação 
// Tipo e técnicas 
 
MODELAGEM DE ARQUITETURAS 
Podemos assumir que todo software possui uma arquitetura, mesmo que não planejada. Sempre que um software é planejado e 
desenvolvido, algumas informações importantes sobre ele precisam, necessariamente, de registro, como: 
• Decisões arquiteturais; 
• Decisões técnicas; 
• Decisões de projeto. 
Normalmente, as decisões de projetos são capturadas e representadas em modelos arquiteturais e o processo que é executado para a captura 
dessas decisões e sua representação em modelos é chamado de modelagem arquitetural. Os modelos podem capturar as decisões 
arquiteturais em diferentes níveis de formalidade e rigor, permitindo que se tenha um melhor entendimento da arquitetura e que otimize a 
discussão em torno da visão, avaliação e evolução arquitetural. 
Dentro desse contexto de modelagem, são introduzidas as notações de modelagem arquitetural, que podem variar de linguagens mais 
informais e flexíveis (como a linguagem natural) até linguagens mais restritas e altamente formais. As notações podem ser utilizadas 
singularmente ou em conjunto com outras linguagens disponíveis, como a UML e a linguagem natural. 
CONCEITOS DE MODELAGEM 
Dentro do que foi introduzido sobre a modelagem arquitetural e sua utilização dentro do contexto da criação e desenvolvimento da 
arquitetura de software, podemos identificar alguns conceitos que permeiam e definem o funcionamento e as abordagens utilizadas nela. Os 
conceitos abordados são: 
• Conceitos arquiteturaisbásicos; 
• Modelagem dirigida a stakeholders; 
• Elementos de um estilo arquitetural; 
• Aspectos estáticos e dinâmicos; 
• Aspectos funcionais e não funcionais. 
// Conceitos arquiteturais básicos 
Dentro de uma arquitetura de software, existem diretrizes e conceitos básicos que devem ser identificados e levados em consideração na hora 
de realizar a modelagem arquitetural, seja ela de um novo software ou de um já existente. 
Nesse caso, podemos considerar os elementos a seguir como os centrais dentro de um projeto arquitetural. 
Componentes 
Blocos de construção que têm como objetivo encapsular pedaços de funcionalidades e informações do sistema e que expõem interfaces claras 
e bem definidas para acesso. 
Conectores 
Blocos que realizam a intermediação e a regulamentação entre os componentes. 
Interfaces 
São definidas como pontos externos de interação de componentes e conectores com os elementos externos à aplicação. 
Configurações 
São, normalmente, associações e definições específicas entre componentes e conectores. 
Rationale 
Este ponto representa o porquê de determinadas decisões arquiteturais serem tomadas e com qual propósito. 
Com esses conceitos, conseguimos ter um norte que oriente nos primeiros passos na modelagem arquitetural. Para a utilização desses 
conceitos, inicialmente, devemos usar notações que nos ajudem a representá-los de forma simples e objetiva, como gráficos de flowcharts 
(setas e retângulos). 
Com a natureza do sistema e a complexidade das regras de negócio e requisitos, a representação desses elementos pode se tornar mais difícil 
e mais demorada. 
// Modelagem dirigida a stakeholders 
Quando os arquitetos necessitam realizar a confecção da modelagem arquitetural, é preciso pensar e definir algumas diretrizes, como: 
• Decisões arquiteturais e técnicas; 
• Nível de detalhe a ser alcançado; 
• Nível de detalhe e de formalidade requeridos. 
Diante dessas diretrizes, o arquiteto de software e os stakeholders precisam incluir uma verificação entre o custo e o benefício de tomar as 
decisões e as diretrizes necessárias para a modelagem arquitetural. Normalmente, as características e as diretrizes mais importantes serão 
aquelas modeladas com mais detalhes e mais formalidade. 
Como todo processo ou atividade dentro de um ciclo de desenvolvimento de software, existem alguns passos básicos a serem seguidos. Na 
modelagem dirigida, a stakeholder não seria diferente. A seguir, temos as atividades básicas que podemos identificar nesse conceito: 
• Mapeamento das principais características do software a serem modelados; 
• Definição da importância dessas características e da categorização; 
• Definição e mapeamento de goals para cada característica principal ou crítica; 
• Definição das notações a serem utilizadas e criação dos modelos a serem implementados; 
• Utilização dos recursos de modelagem em consistência com os goals definidos. 
Os passos mencionados podem e devem ser executados de forma interativa e aplicados em uma arquitetura evolutiva. Normalmente, no início 
de um projeto, não temos todos os detalhes e goals necessários, mas podemos enriquecer esses dados à medida que a arquitetura amadurece 
e ganha robustez em sua confecção. 
// Elementos de um estilo arquitetural 
Um estilo arquitetural pode ser resumido em um conjunto de decisões arquiteturais que serão aplicadas em um determinado contexto de 
solução a ser desenvolvido. Os estilos, de uma forma geral, auxiliam na restrição e na definição do escopo das decisões do projeto, tornando 
mais direcionadas e específicas ao contexto desejado. 
Em adição à modelagem arquitetural, é muito útil e benéfico realizar a modelagem dos estilos que gerem a utilização desses componentes. 
Seguindo esse pensamento, os estilos arquiteturais também são baseados nas decisões tomadas no projeto, permitindo que possam ser 
modelados também. 
Veja algumas vantagens da modelagem dos estilos arquiteturais: 
• Maior visibilidade sobre o escopo arquitetural (o que é permitido e o que não é); 
• Nesse processo de modelagem, temos uma alta taxa de redução de desvio e erosão arquitetural; 
• Ajuda a classificar e identificar a causa das decisões arquiteturais e seu acompanhamento; 
• Cria um mapa evolutivo da arquitetura; 
• A modelagem do estilo arquitetural, em algumas situações, pode ser mais viável e útil que a modelagem arquitetural em si. Exemplo: 
sistemas dinâmicos; 
• Por trabalhar sobre os estilos e serem baseados em decisões de projetos que podem ser similares a outros projetos, facilita sua 
reutilização entre diversos projetos; 
• É uma forma centralizada de manter uma referência ao rationale e aos conceitos arquiteturais. 
Por se tratar de estilos arquiteturais que podem ser reutilizados em diversos projetos, as decisões que são utilizadas para defini-los tendem a 
ser mais abstratas e genéricas do que as decisões arquiteturais em si. Nessa linha de pensamento, podemos definir alguns conjuntos ou 
classificações desses tipos de decisões. São elas: 
Decisões por elementos específicos 
Neste contexto, o estilo pode demandar que componentes, conectores e interfaces sejam referenciados na arquitetura e utilizados em 
situações específicas. Para tornar esta modelagem mais fácil e mais legível, a utilização de templates é uma boa alternativa. 
Decisões baseadas em tipos de componentes, conectores ou interfaces 
Neste contexto, alguns elementos específicos podem ser proibidos, requeridos ou permitidos em uma determinada arquitetura. A maioria das 
abordagens de modelagem possui uma clara definição de tipos que podem ser utilizados, tornando esse tipo de mapeamento mais 
padronizado. 
Decisões por restrição de interação 
Neste contexto, as restrições de interação podem ser: 
// Temporais: componentes que iniciam a comunicação devem chamar a função de inicialização antes de qualquer outra ação; 
// Topológicas: apenas componentes da camada de cliente podem referenciar componentes da camada servidora; 
// Protocolares: definem o protocolo de interação (exemplo: FTP, HTTP etc.) ou especificação de comunicação (exemplo: diagrama de 
sequência, CSP etc.). 
CONTEXTUALIZANDO 
File Transfer Protocol (Protocolo de Transferência de Arquivos) é uma forma de transferir arquivos e permite duas maneiras de transferência 
de mensagens FTP: texto e código binário. 
Decisões por restrições comportamentais 
Neste contexto, as modelagens seguirão um escopo maior de atuação, podendo variar de regras mais simples a comportamentos mais 
complexos. Para a modelagem desse tipo de estilo, as notações devem suportar modelos lógicos e/ou formais como os autômatos. 
Decisões por restrições concorrentes 
Neste tipo de contexto, é necessário modelar a estratégia de concorrência entre os elementos e como a sincronização de recursos entre eles é 
realizada, bem como a utilização de recursos compartilhados. Neste tipo de modelagem, a notação deve suportar a representação temporal, 
como diagramas de sequência e de transição de estados. 
// Aspectos estáticos e dinâmicos 
Todo sistema possui aspectos estáticos e dinâmicos, que podem ser identificados e classificados. 
Os aspectos estáticos são aqueles que não estão relacionados ao comportamento do sistema durante sua execução. Por serem estáticos, são 
mais fáceis de modelar. Podemos usar como exemplos de aspectos estáticos os próprios componentes do software, conectores, configurações 
de redes e servidores. 
Os aspectos dinâmicos são o oposto dos estáticos e estão intrinsecamente relacionados ao comportamento do sistema durante sua execução. 
Por serem dinâmicos e possuírem maior volatilidade, seu mapeamento se torna mais complexo e difícil. Alguns exemplos que podem ser 
classificados nesse aspecto são os modelos de interação entre componentes, modelos de fluxo de dados e outros. Algumas características 
devem ser levadas em consideração quando são trabalhados os modelos dinâmicos, que podem aumentar a dificuldadeem utilizar esse tipo 
de modelo. Podemos considerar, nesses casos: 
• Os modelos dinâmicos são incorporados ao sistema em modelo de leitura e escrita, sendo que sua execução pode modificar o 
modelo em si; 
• Necessita de ferramentas próprias que possibilitem a sincronização entre o modelo e o sistema; 
• Devem ser construídos e armazenados com uma notação que seja legível para a máquina (machine-readable e machine-writable); 
• Devem conter correlação com os elementos da implementação; 
• A visualização dos modelos pode suportar mudanças em tempo real, devendo refleti-las automaticamente. 
// Conceitos arquiteturais básicos 
Neste contexto, é de extrema importância que se entenda as diferenças entre os aspectos funcionais e não funcionais. Para auxiliar nessa 
identificação, podemos assumir o seguinte: 
// Aspectos funcionais 
• Estão relacionados ao que o sistema faz e são descritos de forma declarativa, como em: “o sistema salva formulário de cadastro”; 
• Geralmente, são mais concretos, proporcionando maior facilidade na modelagem e na descrição; 
• Podem capturar o comportamento de componentes, conectores ou subsistemas; 
• Podem ser estáticos ou dinâmicos; 
• A maioria das notações disponíveis mapeia aspectos funcionais, diferindo apenas em quais e como estes aspectos são descritos. 
// Aspectos não funcionais 
• Dizem respeito ao que o sistema fará. Exemplo: “o sistema envia mensagens confidencialmente”; 
• Os aspectos não funcionais tendem a ser qualitativos e subjetivos; 
• Podem ter um perfil mais informal e menos rigoroso em sua apresentação em relação aos funcionais; 
• Em vários cenários, os aspectos funcionais são trabalhados para resolver os aspectos não funcionais. Exemplo: na descrição não 
funcional, o componente de processamento de fatura de cartão de crédito deve ser rápido. Já na descrição funcional, o componente 
de processamento de fatura de cartão de crédito irá utilizar cache e processamento em paralelo. Duas estratégias funcionais que 
buscam atingir o aspecto não funcional; 
• Importante implantar uma forma de suporte à rastreabilidade, permitindo aos arquitetos associarem os aspectos não funcionais às 
decisões. 
// Ambiguidade, exatidão e precisão 
Quando pensamos na arquitetura, em seu design e sua modelagem, é possível identificar que as arquiteturas são, por natureza, incompletas 
em relação ao todo do software. Isso ocorre porque a arquitetura, normalmente, reflete as decisões principais e as críticas do sistema, não 
todas as decisões. 
Pensando nesse aspecto, é fácil identificar porque, geralmente, torna-se uma tarefa quase impossível eliminar a ambiguidade em uma 
arquitetura. Quando se tem esse cenário, algumas ações que auxiliam nas tratativas dessa situação podem ser realizadas, como: 
• Apresentar e permitir as ambiguidades, desde que autorizadas pelos stakeholders; 
• Realizar um processo de avaliação contínua da arquitetura, mapeando e documentando os aspectos ambíguos identificados até que 
se encontre um nível de qualidade aceitável. 
Outros dois fatores importantes que devemos levar em conta nos modelos são as prerrogativas de exatidão e de precisão. Um modelo se 
torna exato se apresenta informações corretas sobre o sistema sendo modelado. Já um modelo preciso é aquele que contém informações 
detalhadas sobre o sistema. 
Normalmente, na modelagem, a balança tende a priorizar a exatidão sobre a precisão, pois ter as informações mais precisas é mais relevante 
no início do projeto que seu detalhamento, podendo ser obtido e melhorado durante as fases posteriores do projeto. 
MODELAGEM COMPLEXA 
Quando pensamos em modelos arquiteturais e em todas as características e elementos que os acompanham, vemos que eles são artefatos de 
alta complexidade que buscam mapear e identificar as decisões importantes e críticas para uma variedade considerável de stakeholders. 
Utilizando essa linha de pensamento, conseguimos visualizar que é meramente inviável para os stakeholders interagirem com todos os 
aspectos de uma só vez, por isso a importância de identificar os pontos mais importantes e críticos. 
Para nos auxiliar na melhor utilização das informações capturadas e apresentá-las para os stakeholders e outras partes envolvidas, podemos 
utilizar duas estruturas que nos ajudam muito. São elas: 
VIEW: Esse tipo de estrutura representa um conjunto de decisões de projetos que estão relacionadas por um interesse comum ou um 
conjunto destes interesses. 
VIEWPOINT: Esse tipo de estrutura define uma perspectiva em que se pode extrair uma view. Funciona como um filtro de informações. 
Podemos utilizar as views em vários momentos e em várias estruturas da arquitetura de software. Uma delas é a visão de implantação 
(deployment view), que pode ser representada da seguinte forma: 
https://sereduc.blackboard.com/courses/1/7.5099.80686/content/_5078757_1/scormcontent/index.html
 
Diagrama 1. Visão de implantação. Fonte: Centro de Informática – UFPE. Acesso em: 28 ago. 2019. (Adaptado). 
Assim como as views, as estruturas de viewpoints também possuem um papel de extrema importância na apresentação dos aspectos 
capturados. A seguir temos alguns exemplos de viewpoints que frequentemente são identificados: 
• Logical viewpoint: realiza a captura das entidades lógicas do sistema e suas conexões. 
 
Diagrama 2. Exemplo de logical viewpoint. Fonte: The Open Group, 2013. Acesso em: 10/10/2019. (Adaptado). 
• Physical viewpoint: realiza a captura das entidades físicas do sistema e suas conexões. 
 
Diagrama 3. Exemplo de physical view. Fonte: The Open Group, 2013. Acesso em: 10/10/2019. (Adaptado). 
• Deployment viewpoint: realiza a captura do mapeamento das entidades lógicas em entidades físicas. 
 
Diagrama 4. Exemplo de deployment viewpoint. Fonte: The Open Group, 2013. Acesso em: 10/10/2019. (Adaptado). 
• Concurrency viewpoint: realiza a captura das formas de tratamento referentes à concorrência e ao multiprocessamento gerenciados 
pelo sistema. 
• Behavioral viewpoint: realiza a captura do comportamento (ou parte desse comportamento) esperado pelo sistema. 
 
Diagrama 5. Exemplo de behavioral viewpoint para um sistema de seguros. Fonte: The Open Group, 2013. Acesso em: 10/10/2019. 
(Adaptado). 
Tendo em vista as estruturas de views e viewpoints, é facilmente identificável o relacionamento existente entre elas e como podem interagir. 
Um ponto importante que vale a pena ressaltar é a possibilidade de se obter múltiplas views a partir de uma mesma viewpoint. 
Sempre que analisamos essas estruturas, vemos como elas são importantes. Alguns motivos pelos quais podemos pensar dessa forma: 
• Com essas estruturas, temos a possibilidade de limitar o escopo de visão da informação a um conjunto controlado e cognitivamente 
gerenciável da arquitetura; 
• Apresentam uma forma clara de exibir, às vezes simultaneamente, conceitos relacionados; 
• Possuem flexibilidade suficiente para se adaptarem às necessidades dos stakeholders; 
• Possuem flexibilidade para trabalhar as mesmas informações em níveis diferentes de abstração e apresentação. 
Claro que nem tudo é perfeito dentro desse contexto da modelagem arquitetural e da utilização de suas estruturas. Por conta disso, é 
necessário verificar algumas consistências para garantir a integridade das informações. Dentro dessa visão, existem alguns tipos de 
inconsistências que podemos identificar. 
// Inconsistência direta 
Neste tipo de inconsistência, temos o cenário em que duas views apresentam proposições diretamente contraditórias, podendo ser 
detectadas por mecanismos automáticos que utilizam regras específicas. 
Exemplo: uma view indica que o sistema deve ser executado em dois hosts versus outra view que determina que o mesmo sistema seja 
executado em três hosts. 
// Inconsistência de refinamento 
Neste tipo de inconsistência, temos o cenário com duas views de um mesmo sistema, mas com níveis de detalhamento diferentes, que 
apresentam proposiçõesque são diretamente contraditórias, podendo ser detectadas automaticamente, utilizando regras de consistência 
bem definidas. Sabe-se que para essas regras funcionarem adequadamente, é necessário que as views apresentem informações suficientes 
para suportá-las. 
Exemplo: uma view estrutural com nível mais alto apresentando um componente que não está presente na view estrutural das sub-
arquiteturas. 
// Inconsistência de aspecto estático versus dinâmico 
Esses tipos de inconsistência são mais complexos de serem identificados. Basicamente, ocorrem quando uma view de aspecto estático se 
encontra em conflito com uma view de aspecto dinâmico. 
Um exemplo desse tipo de caso pode ocorrer quando demonstramos em uma sequência de mensagens (dinâmico) um componente que não 
possui representação em uma view do tipo estrutural (estático). 
Também podemos ter uma inconsistência entre duas views dinâmicas. Esse tipo de inconsistência é de extrema dificuldade de ser detectada 
de forma automática, pois requer extensas e mais complexas simulações de estados e cenários. 
// Inconsistência de aspecto funcional versus não funcional 
Esse tipo de inconsistência é mais comum de ocorrer, pois envolve um relacionamento/mapeamento tradicional identificado nas arquiteturas: 
o mapeamento funcional versus não funcional. Esse tipo de inconsistência ocorre quando temos uma propriedade não funcional, identificada 
em uma view não funcional, ausente nas views funcionais do projeto. Deve-se mapear e atender todas as propriedades não funcionais nas 
views funcionais, pois é uma forma de manter a consistência do design arquitetural. 
Um exemplo desse tipo de cenário pode ocorrer quando temos uma propriedade não funcional que define para um sistema uma alta taxa de 
disponibilidade e, ao realizar a view física do sistema, inclui-se apenas um servidor, quebrando a ideia de alta disponibilidade. 
Esse tipo de inconsistência é extremamente difícil de identificar automaticamente, pois esses cenários e views possuem uma natureza 
genérica e abstrata em relação às propriedades não funcionais. 
TÉCNICAS DE MODELAGEM 
Dentro do universo da modelagem arquitetural, os arquitetos de software têm à sua disposição um conjunto grande de opções de notação e 
técnicas de modelagem que permitem realizá-la em diversos aspectos arquiteturais e em estruturas de diversas complexidades. 
Devido a essa grande variedade, algumas abordagens apresentam uma amplitude considerável de aplicações e soluções de cenários que são 
extremamente úteis; mas mesmo contendo todas essas opções, é importante manter abertas as opções de utilização, não se prendendo 
apenas a uma técnica específica. Seguindo essa linha de pensamento, podemos separar esse conjunto da seguinte forma: 
// Técnicas genéricas 
• Linguagem natural 
• Gráficos informais 
• UML (Unified Modeling Language) 
// ADLs (Architecture Description Languages) 
• Darwin 
• Rapide 
• Wright 
• Koala 
• AADL (Architecture Analysis and Design Language) 
// Técnicas genéricas – linguagem natural 
Esse tipo de técnica busca realizar a descrição dos conceitos utilizando vocabulários extensivos e informais, podendo mapear qualquer tipo de 
conceito sem um detalhamento mais aprofundado. Trabalha tanto com conceitos estáticos quanto dinâmicos. 
Dentre as técnicas disponíveis, é a que introduz a maior quantidade de ambiguidades, podendo ocasionar dificuldades de entender as views 
definidas. Uma forma de reduzir as ambiguidades é a introdução de templates e dicionários de dados bem definidos. Esse mecanismo não 
disponibiliza nenhuma definição para automatização de verificação de inconsistência, sendo que essa deve ser realizada de forma manual e 
frequente. 
Esse tipo de técnica é muito útil na especificação de propriedades não funcionais (genéricas/abstratas) e como uma estrutura de suporte a 
outros tipos de linguagens mais formais e fechadas em que se deve expor maiores detalhes e mais rigor. 
// Técnicas genéricas – gráficos informais 
Essa técnica envolve a possibilidade de utilização de diagramas de tipos diferentes, compostos por elementos gráficos e textuais. Entre os 
elementos gráficos, podemos utilizar as formas geométricas, caixas de texto e outros. Por ser uma técnica que não está associada à semântica 
arquitetural, ela não possui a noção definida de aspectos estáticos e dinâmicos. 
Assim como a linguagem natural, também apresenta ambiguidades que podem ser controladas com a utilização de um dicionário controlado. 
Também não apresenta uma forma automatizada de testes e, portanto, as verificações relacionadas a inconsistências devem ser feitas de 
forma manual e frequente. 
// Técnicas genéricas – UML 
Nessas técnicas, temos a possibilidade de utilizar uma linguagem notacional com uma variedade considerável de diagramas e estruturas que 
auxiliarão os arquitetos de software a conseguirem expressar, de forma mais clara, todas as estruturas e os cenários que precisam ser 
contemplados na modelagem arquitetural. 
Essa notação possui uma estrutura de diagramas bem definida e com várias regras de criação e modelagem que trouxeram para a linguagem 
notacional o posto de principal linguagem utilizada na modelagem arquitetural. Basicamente, podemos dividir a UML em duas categorias: 
DIAGRAMAS ESTRUTURAIS 
São estruturas que representam aspectos estáticos da solução e que não levam em consideração a ação temporal sobre elas. 
DIAGRAMAS COMPORTAMENTAIS 
São estruturas que representam os aspectos dinâmicos da solução e como esses aspectos se relacionam no decorrer do tempo dentro da 
solução. Dentro dessa categoria, temos um subgrupo de diagramas chamado diagramas de interação, que auxilia na representação das 
interações dinâmicas entre os componentes. 
https://sereduc.blackboard.com/courses/1/7.5099.80686/content/_5078757_1/scormcontent/index.html
Um dos principais motivos de a UML ter sido adotada como um dos padrões de representação de aspectos na modelagem arquitetural é o fato 
de ela não estar sob o domínio de uma empresa específica, mas de um consórcio aberto de empresas chamado Open Management Group ou 
OMG. 
 
Diagrama 6. Visão geral dos diagramas a partir da versão 2.4 da UML. 
Nesse contexto, podemos definir que os objetivos principais da linguagem notacional UML são: 
• Documentar; 
• Especificar; 
• Maior visualização lógica do sistema. 
Veja a seguir alguns exemplos dos principais diagramas da UML: 
 
Diagrama 7. Exemplo de diagrama de classes. 
 
Diagrama 8. Exemplo de diagrama de sequências. 
• ADL – Darwin (1ª geração): é um tipo de ADL de propósito geral que é, normalmente, utilizado em sistemas em que os componentes 
utilizam interfaces explícitas para se comunicarem. Possui uma representação em formato de texto que é possível descrever os 
componentes e suas interconexões, bem como uma representação gráfica.Possui elementos básicos que representam os 
componentes, os conectores (obrigatórios e os disponibilizados no sistema), as ligações e as composições hierárquicas. 
EXPLICANDO 
Apesar de suportar os elementos padrões, esse tipo de ADL não suporta modelagem dinâmica nem aspectos não funcionais e não possui, 
nativamente, nenhum suporte à consistência de views. 
• ADL – Rapid (1ª geração): esse tipo de ADL tem como principal característica a abordagem direta de aspectos dinâmicos da 
arquitetura, disponibilizando uma ferramenta de apoio para a simulação dos aspectos necessários. Apesar disso, a notação dessa 
ADL é muito precária e, dessa forma, impõe uma alta curva de aprendizado. 
• Em relação às verificações estruturais, esse tipo de ADL não possui recursos básicos para garantir que as implementações estejam 
em conformidade com as especificações. 
• ADL – Wright (1ª geração): essa ADL possui um alto overhead cognitivo e uma alta curva de aprendizado. Apesar disso, disponibiliza 
capacidades mais fortes e definidas de análise da arquitetura. Então, é possível ver que esse tipo de ADLé muito utilizado em 
sistemas com perfil do tipo safety-critical, pois demandam uma modelagem extensivamente formal. 
• Nessa ADL, há uma deficiência no suporte para realizar o refinamento das especificações arquiteturais definidas no sistema. 
• ADL – Koala: tem como escopo inicial capturar a estrutura, a configuração e as interfaces dos componentes existentes no contexto 
de sistemas embarcados em dispositivos eletrônicos. Nesta estrutura, essa ADL apenas captura as estruturas estáticas e as interfaces 
são modeladas. 
Embora os aspectos sejam definidos estaticamente, a seleção de variantes pode ser alterada em tempo de execução, 
 proporcionando a possibilidade de ter uma flexibilização na sua utilização. Dentro dessa estrutura, a identificação de erros é 
 relativamente fácil de identificar, pois os modelos gerados com o uso da ADL possuem regras e padrões de interconexão muito bem 
 definidos. 
• ADL – AADL: tem como escopo principal a utilização de modelos multinível relacionados a elementos de hardware e software que 
possuem conexões. Dentro desses elementos, podem ser identificados componentes, como redes, barramentos, processos e outros. 
Nesse contexto, essa ADL não possui suporte explícito à modelagem dinâmica, mas permite a captura de propriedades não funcionais 
definidas pelo usuário, com o viés de não poder incluir esses tipos de propriedades em análises automáticas. Assim, esse tipo de ADL 
apresenta certa flexibilidade para suportar alguns determinados cenários. O Open Source ADDL Tool Environment (OSATE) possui diversos 
plug-ins para realizar análise e verificação de consistências. 
Análise de arquiteturas 
A análise arquitetural é uma etapa de muita importância dentro do ciclo de vida de desenvolvimento de um software, pois possibilita que 
propriedades significativas do sistema sejam identificadas, partindo-se das estruturas de modelagem disponíveis no contexto arquitetural do 
projeto. 
Com essas propriedades identificadas e corretamente documentadas dentro do processo arquitetural utilizado, o arquiteto de software tem a 
possibilidade de realizar importantes questionamentos e aferições sobre a solução a ser desenvolvida e como isso será feito no momento do 
desenvolvimento propriamente dito. 
Para isso, o arquiteto deve usar todas as ferramentas disponíveis para identificar propriedades importantes, como as metas a serem atendidas, 
o escopo a ser alcançado e os aspectos que devem ser considerados. Claro que, dentro desse contexto de análise arquitetural, outros 
conceitos e estruturas devem ser abordados e considerados, como veremos em nosso estudo. 
CONCEITOS E ABORDAGEM 
Para conseguirmos entender como aplicar e identificar os principais conceitos presentes na análise arquitetural, precisamos entender como 
eles funcionam e quais são suas principais características. Então, vamos começar pelos itens básicos que utilizamos na análise das arquiteturas. 
// Metas 
As metas são elementos que devem ser definidos pelo arquiteto de sistemas com os stakeholders para assegurar o direcionamento correto do 
projeto e das implementações que serão realizadas. No contexto das metas, podemos utilizar quatro tipos principais de categorias que 
auxiliam em sua identificação e em sua utilização na análise arquitetural. São elas: 
COMPLETUDE 
// Completude pode ser separada em externa e interna; 
// Completude externa visa a estabelecer se a arquitetura apresentada captura de forma correta todos os requisitos funcionais e não 
funcionais principais e críticos do sistema; 
// Completude interna visa a estabelecer se todos os elementos do sistema foram capturados integralmente em relação à modelagem e ao 
sistema que está sendo projetado. 
CONSISTÊNCIA 
// Neste conceito, identificamos e garantimos que diferentes elementos presentes no modelo não são contraditórios; 
// Ao realizar a captura dos detalhes dos projetos, podem ser identificadas ou introduzidas algumas inconsistências que podem ser 
identificadas como: 
Inconsistência de nome 
Esse tipo de inconsistência está relacionado aos nomes utilizados nos componentes, nos conectores e nas estruturas internas a esses 
elementos. Arquiteturas que possuem um perfil mais desacoplado, como arquiteturas baseadas em produtor/consumidor, possuem a 
característica de serem dinâmicas e adaptáveis, dificultando a detecção desses tipos de inconsistências. 
Inconsistência de interface 
Normalmente, nesta categoria, são identificadas todas as inconsistências de nome. Aqui, podemos dizer que o nome de um serviço sendo 
consumido ou disponibilizado pode conter o mesmo nome, mas deve possuir os parâmetros diferentes em sua quantidade e/ou seu tipo. O 
retorno também é considerado neste cenário. 
Inconsistência comportamental 
Ocorre entre componentes que expõem e consomem serviços nos quais as interfaces são compatíveis, mas o comportamento difere entre 
eles. 
Inconsistência de interação 
Ocorre quando temos uma violação nas restrições de interação entre operações de um componente. Um exemplo seria uma violação na 
ordem de execução de determinadas operações. 
Inconsistência de refinamento 
É mais complexo de ser identificado e mapeado, uma vez que sua ocorrência está vinculada ao fato de que as arquiteturas são capturadas em 
diferentes níveis de abstração. Para a identificação deste tipo de inconsistência, podemos levar em conta as seguintes diretrizes: 
// Elementos presentes no modelo de mais alto nível devem estar presentes no modelo de baixo nível; 
// As decisões principais mapeadas no modelo de alto nível não foram omitidas, modificadas ou violadas no modelo de baixo nível; 
// Novos detalhes introduzidos em modelos de baixo nível devem se manter consistentes com os detalhes no modelo de mais alto nível. 
Compatibilidade 
É verificado se o modelo arquitetural está em conformidade com todas as restrições e diretrizes definidas pela arquitetura de referência, pelo 
modelo arquitetural ou pela padronização arquitetural utilizada no projeto. 
Corretude 
É verificado se as decisões arquiteturais do projeto atendem de forma adequada às definições externas do sistema. 
https://sereduc.blackboard.com/courses/1/7.5099.80686/content/_5078757_1/scormcontent/index.html
// Escopo 
O escopo é uma característica que nos auxilia na identificação das fronteiras arquiteturais que devemos definir para que possamos ter uma 
estrutura de modelagem e implementação adequada e aderente às necessidades do software a ser desenvolvido. 
Dentro da análise arquitetural, temos a possibilidade de quebrar os diferentes tipos de escopo em: componente-conector, sistema-
subsistema, troca de dados, arquitetura em níveis e benchmark arquitetural. 
Componente-conector 
Neste tipo de escopo, é verificado se o serviço disponibilizado é o esperado pelo componente e/ou conector apresentado. 
Sistema-subsistema 
Neste tipo de escopo, deve-se verificar a relação entre o sistema principal e seus inter-relacionamentos internos com os subsistemas, a fim de 
garantir que sua composição esteja adequada e que o relacionamento esteja dentro das diretrizes definidas na modelagem arquitetural e nos 
aspectos capturados. 
Troca de dados 
Neste tipo de escopo, são verificados os elementos de dados em relação a: 
// Estrutura dos dados; exemplo: tipados versus não tipados; 
// Fluxo de dados no sistema; exemplo: ponto a ponto versus broadcast; 
// Propriedades da troca de dados; exemplo: latência e consistência dos dados. 
Arquitetura em níveis 
Este tipo de escopo sofre com os efeitos relacionados ao processo incremental que, normalmente, as arquiteturas sofrem ao longo de seu 
ciclo de vida. Nesse caso, a cada nível de evolução arquitetural, novas informações introduzidas podem causar modificações no escopo 
arquitetural. Dentre essas alterações, inconsistências podem ocorrer, demandando que o escopo seja redefinido e replanejado. 
Dessa forma, esse tipo de escopo auxilia a controlar as alterações arquiteturais,