Arquitetura de Sistemas

Prévia do material em texto

Introdução à arquitetura de sistemas
APRESENTAÇÃO
Você já ouviu falar em arquitetura de sistemas? Assim como na construção civil, a arquitetura 
de um sistema tem a finalidade de criar uma estrutura conceitual que mostre ao cliente e à 
equipe de desenvolvimento uma visão geral do sistema antes que a sua construção se inicie. 
Trata-se de um elemento importante no processo de desenvolvimento de software, consistindo 
em um modelo a ser seguido no qual são definidos os componentes do sistema e como esses 
componentes vão funcionar e se interligar.
O uso de princípios de arquitetura está diretamente relacionado ao tipo de sistema que será 
desenvolvido. Por exemplo, uma arquitetura em camadas pode ser ideal para um tipo de sistema, 
enquanto uma arquitetura orientada a objetos pode ser uma solução melhor para outro tipo de 
sistema.
Nesta Unidade de Aprendizagem, você vai conhecer o conceito de arquitetura de sistemas e a 
sua importância, identificando os tipos de arquitetura e relacionando estes no desenvolvimento 
de sistemas.
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Reconhecer a arquitetura de software e sua importância.•
Identificar os tipos de arquiteturas.•
Relacionar a escolha do tipo de arquitetura para o desenvolvimento de sistemas.•
DESAFIO
Escolher a arquitetura de um sistema é um dos passos decisivos para a implementação deste. 
Apesar da existência de diversos gêneros de sistemas, as arquiteturas disponíveis são restritas 
em número. Além disso, vale destacar que um sistema pode ter, inclusive, mais de um tipo de 
arquitetura.
Nesse contexto, para este Desafio, imagine que você foi convidado para integrar a equipe de 
desenvolvimento de um sistema para um software de gestão escolar. Esse sistema precisa conter 
todas as funções básicas disponíveis em um sistema deste gênero, sendo elas: 
 
Cadastrar Aluno;•
Cadastrar Coordenador;•
Cadastrar Curso;•
Cadastrar Responsável;•
Cadastrar Professor;•
Gerar Diário;•
Emitir Relatórios;•
Inserir Notas;•
Emitir Boletos;•
Calcular Salários.•
Entre outras requisitadas pelos clientes.
Assim, perante as funções apresentadas, indique ao menos duas arquiteturas que poderão ser 
funcionais para este caso e justifique a sua resposta.
INFOGRÁFICO
A arquitetura de software consiste em uma área da Engenharia de Software que se preocupa com 
a escolha dos elementos do sistema, suas funcionalidades e a maneira como eles se integram 
para formar o sistema. Assim, durante o projeto de arquitetura, diversos elementos devem ser 
considerados, desde os requisitos levantados pelo usuário até os sistemas que irão interagir com 
o sistema que será desenvolvido.
Pensando nisso, neste Infográfico, você vai conhecer o diagrama de contexto arquitetural, uma 
representação gráfica que exibe todos os elementos externos ao sistema-alvo. 
CONTEÚDO DO LIVRO
Elemento importante da Engenharia de Software, a arquitetura de sistemas objetiva facilitar a 
comunicação entre todas as partes envolvidas no desenvolvimento de um sistema 
computacional. Dessa forma, envolve decisões durante a fase inicial que podem impactar toda a 
construção do projeto e o produto final, e que, quando bem conduzidas, levam o projeto a 
alcançar a satisfação do cliente.
No capítulo Introdução à arquitetura de sistemas, da obra Arquitetura de sistemas, você vai 
estudar a importância dessa arquitetura, além de conhecer seus tipos, relacionando-os, por 
fim, com o desenvolvimento de softwares.
Boa leitura.
ARQUITETURA DE 
SISTEMAS
Paulo Antonio Pasqual Júnior
Introdução à arquitetura 
de sistemas
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Reconhecer a arquitetura de software e sua importância.
  Identificar os tipos de arquiteturas.
  Relacionar a escolha do tipo de arquitetura para o desenvolvimento 
de sistemas.
Introdução
A arquitetura de sistemas é um elemento importante da engenharia de 
software, em que são definidos quais componentes farão parte de um 
sistema e como eles se comunicarão. Definir a arquitetura é importante 
principalmente para que a equipe de desenvolvimento tenha uma visão 
geral do que será o produto do software. 
Existem diversos tipos de arquitetura de sistemas. Escolher uma ar-
quitetura é fundamental para garantir um template, que será o nortea-
dor do desenvolvimento do sistema. Neste capítulo, você vai estudar a 
arquitetura de um software, verificando sua importância e identificando 
os tipos de arquitetura existentes. Por fim, você vai analisar a escolha do 
tipo de arquitetura no desenvolvimento de sistemas. 
Conceitos fundamentais
Quando pensamos em arquitetura de sistemas, é comum fazermos analogias 
com a construção civil, assim como é comum comparar a engenharia de sof-
tware com as outras engenharias. A arquitetura de sistemas é uma subárea da 
engenharia de software. Enquanto a primeira se preocupa com as características 
do sistema, dos elementos necessários e das suas interrelações, a segunda se 
preocupa com todos os processos que envolvem o desenvolvimento de um 
produto de software, abrangendo a concepção, o gerenciamento do projeto e 
o desenvolvimento do produto.
Apesar de as analogias com a construção civil serem úteis para que en-
tendamos esses conceitos, é importante ressaltar que arquitetura de software 
não é uma área independente, como é o caso da arquitetura no âmbito da 
construção civil. Pressman e Maxim (2016, p. 253) definem arquitetura de 
software da seguinte forma: “A arquitetura de software de um programa ou 
sistema computacional é a estrutura ou as estruturas do sistema que abrange 
os componentes de software, as propriedades externamente visíveis desses 
componentes e as relações entre eles”.
Pressman e Maxim (2016) ainda acrescentam que a arquitetura do sistema 
consiste em um modelo relativamente pequeno e compreensível acerca de como 
o sistema será estruturado e como os seus componentes vão se comunicar. 
Gallotti (2016) complementa essa definição ao dizer que, quando falamos da 
arquitetura de um software, estamos nos referindo à estrutura interna do seu 
sistema. Basicamente, ela explica como um software se organiza, funciona, 
além da forma como é implementado. 
As analogias entre a arquitetura e a engenharia no âmbito da construção civil são 
comuns para que entendamos os processos no campo do desenvolvimento de sistemas. 
Contudo, é importante ressaltar que a arquitetura de sistemas não é uma área distinta 
da engenharia de software; na verdade, a arquitetura de sistemas é uma subárea da 
engenharia de software. 
Ao fazermos uma analogia, mais uma vez, com a construção civil, o projeto 
arquitetônico se preocupa basicamente em satisfazer os requisitos do cliente 
e apresentar para ele uma ideia concreta do projeto. Por exemplo, imagine o 
projeto de uma casa; o arquiteto, após levantar os requisitos com o cliente, vai 
elaborar uma planta e uma visualização em 3D do que ele apreendeu a partir 
do que foi estabelecido pelo cliente. O arquiteto vai escolher os elementos que 
Introdução à arquitetura de sistemas2
ele julga ideais, incluindo formas e acabamentos, para que o projeto esteja 
mais próximo do que foi solicitado. 
Nesse sentido, Sommerville (2007) explica que o projeto de arquitetura 
é o primeiro passo no processo do desenvolvimento de software, sendo o 
elo entre o projeto e a engenharia de requisitos, já que identifica os prin-
cipais componentes estruturais do software. O autor ainda ressalta que a 
importância do projeto de arquitetura de sistemas está relacionada ao 
desempenho e à robustez, além da capacidade de manutenção e distribuição 
do sistema. 
Normalmente, em uma empresa de desenvolvimento de software, os pro-
cessos envolvendo o projeto de arquitetura e o desenvolvimento do sistema 
ocorrem paralelamente, e as funções são compartilhadas entre arquitetos 
de sistema e desenvolvedores de software. Dificilmenteuma equipe será 
responsável apenas pela programação, enquanto outra fica responsável pela 
modelagem. Isso porque essa distinção de responsabilidades não faz sentido, 
já que, geralmente, o processo de desenvolvimento de software ocorre em 
ciclos iterativos, que podem modificar o projeto original. 
Ao se considerar a arquitetura de um sistema, são analisados principalmente os requi-
sitos apontados pela equipe responsável pelo levantamento de requisitos. Analisar 
detalhadamente os requisitos contribui para que a escolha da arquitetura esteja de 
acordo com os objetivos do desenvolvimento do sistema. 
Pressman (2011) explica que a arquitetura de sistemas é importante por 
três motivos. Em primeiro lugar, as diversas representações da arquitetura 
de software permitem a comunicação entre todas as partes envolvidas no 
desenvolvimento de um sistema computacional. Em segundo lugar, porque a 
arquitetura implica em decisões durante a fase inicial que impactam todo o 
desenvolvimento do projeto e o produto final de software. Por fim, a arquitetura 
se constitui como um modelo mental de como o sistema será estruturado e 
como os seus componentes trabalharão em conjunto. 
3Introdução à arquitetura de sistemas
Nesse contexto, Sommervile (2007), baseado em outros autores, amplia 
a reflexão sobre a importância da arquitetura do sistema, apontando as três 
vantagens do projeto de arquitetura de software listadas a seguir.
  Comunicação de stakehoders: refere-se à capacidade de a arquitetura 
representar, em alto nível, o sistema, garantindo assim uma comunicação 
entre as partes interessadas. 
  Análise do sistema: a análise do sistema permite que a arquitetura 
torne explícitos alguns elementos do sistema ainda na fase inicial, o 
que permite à equipe analisar detalhes do sistema que não poderiam 
ser considerados sem um projeto arquitetural. 
  Reúso de componentes: como a arquitetura do sistema mapeia os 
componentes e suas relações, o projeto de arquitetura viabiliza a reu-
sabilidade de software para sistemas com requisitos semelhantes. 
Sommerville (2007) ainda aponta que o uso de um projeto de arquitetura 
contribui para viabilizar discussões acerca do sistema, já que possibilita uma 
visão de alto nível do sistema. Além disso, o autor argumenta que o projeto 
de arquitetura possibilita uma forma de documentação do sistema, em que 
são explicitados os componentes, suas propriedades e suas interpelações.
A escolha da arquitetura pode contribuir para que o projeto nasça ali-
nhado aos requisitos para os quais ele será desenvolvido. Definir um tipo de 
arquitetura de sistemas corrobora para que sejam detalhados e desenvolvidos 
componentes que poderão ser reutilizados mais tarde, além de garantir a ma-
nutenibilidade de cada um desses componentes de forma mais simples. Dessa 
forma, o arquiteto de software terá, dentre outras funções, a responsabilidade 
de mapear quais são esses componentes e como eles vão interagir com os outros 
elementos do sistema. Além disso, o arquiteto precisa ser capaz de identificar 
os componentes e saber quais deles podem ser reutilizados, melhorando o 
tempo de desenvolvimento. 
Tipos de arquitetura de sistemas
As decisões que devem ser tomadas em relação às arquiteturas de sistemas 
podem ser classifi cadas utilizando diversos fatores. Uma visão dessa classi-
fi cação pode ser observada na Figura 1.
Introdução à arquitetura de sistemas4
Figura 1. Estruturas das arquiteturas fundamentais.
No âmbito da arquitetura de sistemas, podemos elencar três elementos 
fundamentais para qualquer projeto.
1. Componentes: unidades principais do sistema; podem ser caracte-
rizados por módulos de software com responsabilidades específicas 
dentro do sistema.
2. Propriedades: elementos que se referem às particularidades de cada 
componente. 
5Introdução à arquitetura de sistemas
3. Conectores: caracterizados por todas as formas de conexão entre os 
componentes de um sistema. Eles podem ser caracterizados por cha-
madas de métodos, envio e requisição de mensagens e outras formas 
que garantem a interação entre os componentes do sistema. 
Entre os componentes, as propriedades e os conectores que podem ser 
usados no âmbito da arquitetura de sistemas, Pressman (2011) aponta as prin-
cipais como “estruturas de arquitetura canônicas”, as quais se encontram 
listadas a seguir. 
  Estrutura funcional: os componentes se referem a entidades que 
refletem funcionalidade. Os conectores se referem à capacidade das 
interfaces em transmitir dados para um componente e, desse modo, 
fornecer a capacidade de uso. Já as propriedades se referem à descrição 
dos componentes e à organização das interfaces. 
  Estrutura de implementação: nessa estrutura, os componentes se 
referem a elementos para “empacotar” funcionalidades em vários níveis 
de abstração, como classes, funções, métodos, objetos, etc. Os conectores 
se referem a como esses elementos vão se comunicar dentro do sistema, 
transmitindo dados de controle e instâncias de objetos e compartilhando 
dados. As propriedades se referem a elementos de qualidades como 
manutenibilidade e reusabilidade. 
  Estrutura de concorrência: nessa estrutura, os componentes são res-
ponsáveis por representar estruturas para tarefas paralelas ou threads. 
Os conectores “[...] incluem as relações sincronizações-com, é-de-maior 
prioridade-que, envia-dados-a, não-é-possível-executar-sem e não-é-
-possível-executar-com” (BASS, 2003 apud PRESSMAN, 2010, p. 235).
  Estrutura física: os conectores consistem nas interfaces entre os com-
ponentes de hardware, já as propriedades se referem a desempenho, 
largura da banda, entre outros aspectos. 
  Estrutura de desenvolvimento: refere-se aos componentes, artefatos 
e outras fontes que são necessárias durante o desenvolvimento dos 
processos da engenharia de software. Os conectores têm a função de 
representar o relacionamento entre os artefatos e as propriedades, iden-
tificando as características de cada item. Já as propriedades identificam 
as características de cada item. 
Introdução à arquitetura de sistemas6
Outro elemento fundamental no processo de escolha da arquitetura é a 
definição do gênero arquitetural do sistema. Pressman (2011) entende gê-
nero como uma categoria particular de sistemas; nesse sentido, inclui toda a 
variedade de produtos de software, como aplicativos, sistemas comerciais, de 
escritório e tantos outros. Cada um desses gêneros de arquitetura demandam 
a existência de estruturas específicas a serem modeladas e desenvolvidas. A 
seguir, estão listados alguns exemplos de gêneros de arquitetura de sistemas, 
com base em Pressman (2011). 
  Inteligência artificial
  Comercial
  Comunicações
  Autoria de conteúdo
  Dispositivos
  Esportes e entretenimento
  Financeiros
  Jogos
  Governo
  Industriais
  Legais
  Médicos
  Sistemas operacionais
  Plataformas
  Científicos
  Ferramentas
  Transportes
  Serviços públicos
A partir da definição do gênero arquitetural, também devem ser definidos os 
estilos de arquitetura que poderão nortear o projeto. Existem diversos estilos 
de arquitetura de sistemas; Pressman (2011), ao exemplificar esses estilos, 
faz a analogia com os estilos arquitetônicos presentes nas casas americanas. 
Segundo o autor, quando se fala em estilo colonial americano com hall central, 
muitas pessoas familiarizadas com esse estilo arquitetônico já imaginarão do 
que se trata (PRESSMAN, 2011). Do mesmo modo, os estilos arquitetônicos 
no âmbito de sistemas consistem, segundo Pressman (2011, p. 234), em um “[...] 
um template para a construção”.
Ou seja, é por meio da definição de estilos que se podem considerar as 
características personalizadas a serem acrescentadas ao produto que será 
desenvolvido. Nesse sentido, o estilo arquitetônico de um sistema define o 
conjunto de componentes, as conexões entre eles, as restrições e os modelos 
semânticos que permitem que o projetista compreenda as propriedades gerais 
de um sistema.De acordo com Pressman e Maxim (2016), embora muitos 
sistemas tenham sido desenvolvidos nos últimos anos, a maior parte deles 
pode ser classificada em pequenos estilos de arquitetura. 
7Introdução à arquitetura de sistemas
  Arquitetura centralizada em dados: consiste em sistemas que 
compartilham o banco de dados ou um sistema de arquivos como 
elemento central do sistema. Todos os componentes do sistema se 
comunicam individualmente, tendo como elo apenas o banco de dados. 
A troca de informação é feita entre os componentes do sistema e o 
banco de dados. 
  Arquitetura de fluxo de dados: é um tipo de arquitetura que é aplicada 
quando dados de entrada devem ser transformados passando por várias 
etapas, em um fluxo dentro do próprio sistema, até as etapas de saída. 
Geralmente, um componente se comunica com outro de forma restrita 
e interdependente. 
  Arquitetura de chamadas e retornos: consiste em uma arquitetura em 
que o programa é desenvolvido de forma hierárquica, por meio de um 
programa principal, que pode acessar outros subprogramas e, assim, 
sucessivamente. Esse tipo de arquitetura é útil, pois essa estrutura 
é relativamente fácil de aumentar e modificar, segundo Pressman e 
Maxim (2016). 
  Arquiteturas orientadas a objetos: são sistemas baseados em classes 
e objetos com certo grau de encapsulamento, em que a comunicação e 
a coordenação ocorrem entre os objetos por meio de mensagens. 
  Arquitetura em camadas: praticamente todo sistema, independente-
mente da sua função, é baseado em camadas. Essa arquitetura consiste 
em níveis que vão da interface (camada mais externa) até a camada 
central (mais próxima da linguagem de máquina).
De maneira geral, a partir da escolha da arquitetura do sistema, ficarão 
evidenciadas as camadas que o sistema terá. Se a arquitetura for de um sistema 
operacional, obviamente as camadas serão diferentes de um software de gestão 
empresarial. Entre as camadas comuns em um software, temos: 
  interface;
  camada de negócios;
  camada central.
Uma vez definida a arquitetura do sistema e as camadas que serão utiliza-
das, cada uma dessas camadas será desenvolvida com as suas especificidades. 
Introdução à arquitetura de sistemas8
Definir a arquitetura e as camadas de um sistema pode contribuir também 
para que os próximos projetos de software sejam desenvolvidos de forma 
mais rápida e com menor número de erros. Isso ocorre porque essas camadas 
podem ser reaproveitadas para outros sistemas similares. 
Um exemplo bastante simples é o uso da interface. Imagine um sistema de cadastro 
e gerenciamento de clientes que foi desenvolvido para uma empresa X. Quando 
a equipe de desenvolvimento de software precisar desenvolver um outro software 
do mesmo gênero, a interface será muito próxima da que já está desenvolvida, 
assim como o banco de dados. Assim, bastará integrar o novo sistema às camadas 
já existentes. Como essas camadas já foram utilizadas outras vezes e testadas, a 
probabilidade da incidência de erros será muito menor do que se o sistema fosse 
desenvolvido desde o início.
No âmbito dos estilos de arquitetura, Sommerville (2007) ainda acres-
centa a arquitetura cliente-servidor, que consiste em uma arquitetura 
baseada em serviços, ou seja, cada cliente acessa o servidor para ter acesso 
aos dados e funcionalidades específicas. Muitos sistemas possuem esse 
tipo de arquitetura; em especial, esse tipo de arquitetura privilegia sistemas 
distribuídos. 
Arquitetura de sistemas e desenvolvimento 
de software
Quando você pensa em tipos de arquitetura, o que vem à sua mente? É pos-
sível que você imagine diferentes tipos de construções, sejam elas casas ou 
prédios. Enfi m, podemos pensar em diversos tipos de arquitetura — clássica, 
colonial, moderna, entre outras. Mais uma vez pensando na analogia com 
a construção civil, quando um arquiteto começa a desenvolver um projeto, 
certamente ele já terá em mente a arquitetura em que ele se baseará. O mesmo 
acontece quando falamos em arquitetura de sistemas. Antes que o processo 
9Introdução à arquitetura de sistemas
de desenvolvimento seja iniciado, é provável que o arquiteto de sistemas, a 
partir dos requisitos apontados pela equipe, seja capaz de indicar um tipo de 
arquitetura a ser seguida. 
Suponha que um cliente tenha solicitado um game para computador. Assim, o arquiteto 
de software deverá determinar quais componentes desse sistema serão necessários 
para que a aplicação funcione, bem como quais serão as formas de conectar cada 
um desses componentes. Da mesma forma que um software comercial, um game 
possui uma interface e um banco de dados, além das especificidades de um game, 
que são diferentes daquelas de outras arquiteturas. Por exemplo, o game poderá 
ser controlado por teclado, controle ou mouse? Poderá se comunicar com algum 
sensor de movimento? Quais outras questões são distintas de um software de gestão? 
Todas essas questões deverão ser consideradas para que a escolha, a modelagem e 
o desenvolvimento do sistema esteja de acordo com os requisitos necessários para 
viabilizar o projeto. Ao definir a arquitetura, deve-se mapear não só esses elementos, 
mas também as interpelações entre eles. 
Para construir uma arquitetura, é importante considerar a utilização 
de diagramas de contexto arquitetural e de arquétipos; enfim, deve ocor-
rer o refinamento da arquitetura. O diagrama de contexto arquitetural 
(Figura 2) é utilizado para mapear e modelar a maneira como o software vai 
interagir com entidades externas, conforme aponta Pressman (2011). Nesse 
contexto, o sistema que está sendo desenvolvido é representado como o 
centro do processo, e são expressas no diagrama as relações com os sistemas 
apresentados a seguir.
  Sistemas superiores: consistem em sistemas que usam o sistema-alvo. 
  Sistemas subordinados: sistemas que são utilizados pelo sistema-alvo. 
  Sistemas de mesmo nível: consistem em sistemas que compartilham 
informação com o sistema-alvo.
  Atores: consistem em entidades, pessoas ou dispositivos que utilização 
o sistema, como se pode observar na Figura 2.
Introdução à arquitetura de sistemas10
Figura 2. Diagrama de contexto arquitetural.
Fonte: adaptada de Pressman (2016).
Os arquétipos são utilizados para representar conceitos e conhecimentos 
de um domínio específico. São descritos como modelos formais e reutilizáveis 
do conceito do domínio, que são aplicados nos vários cenários em que esses 
conceitos são utilizados. Por exemplo, a pressão sanguínea pode ser repre-
sentada pelos valores da pressão sistólica e diastólica, pela data e horário em 
que a pressão foi aferida e pelo local onde a pressão foi aferida. Sempre que 
a pressão sanguínea precisar ser utilizada, o modelo conceitual da pressão 
será utilizado. Os arquétipos formam a base da arquitetura, mas devem ser 
refinados à medida que a arquitetura é detalhada. 
Na sequência, os componentes da arquitetura devem ser definidos com 
base no domínio da aplicação, na infraestrutura e no diagrama de contexto 
arquitetural. Os componentes da arquitetura devem, portanto, ser modelados. 
Por fim, uma das etapas finais do projeto de arquitetura consiste em desenvolver 
uma instância real do problema, mostrando que a estrutura e os componentes 
projetados são adequadas à necessidade do software. 
11Introdução à arquitetura de sistemas
Ao fim do processo de projeto de arquitetura, é comum que outro processo 
se inicie: o processo de avaliação do projeto. Nessa fase, são analisados os 
projetos de arquitetura e, a partir de uma série de princípios, são analisados 
os pontos fortes e fracos da arquitetura escolhida para o desenvolvimento do 
sistema. Esse processo pode ocorrer imediatamente após o projeto de arqui-
tetura, ou poderá ocorrer durante a implementação do sistema. 
Pressman (2011) aponta três modelos para a avaliação de um projeto de 
arquitetura. O primeiro corresponde a analisar o projeto desde os casos de 
uso, passando por fases de elicitação de requisitose descrição de estilos, 
pela análise de atributos de qualidade, entre outras fases, até chegar ao ponto 
em que são analisados os pontos fortes das arquiteturas candidatas. Uma 
segunda forma, ainda segundo o autor, consiste em avaliar a complexidade da 
arquitetura a partir da análise dos componentes e de suas interdependências. 
Como última forma de avaliação, Pressman (2011) aponta a utilização de uma 
linguagem formal para o mapeamento da arquitetura, que pode contribuir para 
um processo de avaliação mais formal. Tendo esses processos finalizados, 
o sistema então poderá ser implementado, levando em consideração todos 
os aspectos elencados pela equipe de projeto e a avaliação da arquitetura 
de sistemas. 
No âmbito do desenvolvimento do sistema, da escolha e do projeto de arqui-
tetura, Sommerville (2007) ressalta a necessidade de se focar nos requisitos 
não funcionais, uma vez que eles estão diretamente vinculados à arquitetura 
do sistema. Nesse sentido, o autor lista alguns exemplos de requisitos não 
funcionais que podem ser influenciados pela arquitetura do sistema, são eles: 
desempenho, proteção, segurança, disponibilidade e manutenção. 
Por exemplo, se o desempenho for um requisito não funcional, o sistema não poderá 
estar organizado em uma série de pequenos componentes, que levam tempo para 
serem acessados e geram um feedback tardio para o usuário. Do mesmo modo, se um 
requisito não funcional for a segurança, um módulo de segurança deve estar restrito 
ao menor número de componentes possível, o que possibilita maior segurança em 
relação aos dados desse sistema. 
Introdução à arquitetura de sistemas12
Sommerville (2007) ainda aponta que, muitas vezes, dependendo dos 
requisitos não funcionais, pode haver conflitos; por exemplo: o uso de grandes 
componentes melhora o desempenho, mas o uso de pequenos componentes 
melhora a manutenibilidade. Se desempenho e manutenibilidade forem requi-
sitos não funcionais, é preciso avaliar uma arquitetura que possa contemplar, 
ao menos em partes, ambos os requisitos não funcionais. 
O autor aponta que, muitas vezes, o projeto de arquitetura pode ser desneces-
sário, quando o sistema é relativamente pequeno e simples de desenvolver, ao 
passo que, no caso de sistemas críticos, o projeto de arquitetura contribui para 
a redução de possíveis falhas do sistema. Em síntese, o projeto de arquitetura 
se relaciona com o desenvolvimento do sistema, na medida em que fornece um 
modelo conceitual, que, ainda no início da fase de desenvolvimento, possibilita 
uma visão geral do sistema, com base não apenas nos requisitos funcionais, 
mas também nos requisitos não funcionais. 
GALLOTTI, G. M. A. (org.). Arquitetura de Software. São Paulo: Pearson Education do 
Brasil, 2016.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 7. ed. Porto 
Alegre: McGraw-Hill, 2011.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8. 
ed. Porto Alegre: AMGH, 2016.
SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Pearson Addison Wesley, 2007.
Leitura recomendada
BARBOSA. G. M. G. Um livro-texto para o ensino de projeto de arquitetura de software. 
2009. Dissertação (Mestrado em Ciência da Computação) — Centro de Engenharia 
Elétrica e Informática, Universidade Federal de Campina Grande, Campina Grande, 
SP, 2009.
13Introdução à arquitetura de sistemas
DICA DO PROFESSOR
Analisar a melhor arquitetura para um projeto pode parecer uma tarefa difícil. No entanto, 
existem diversas formas para realizar essa escolha, seja baseada nos requisitos ou no 
desenvolvimento de protótipos. O Software Engineering Instituite (SEI) desenvolveu um 
método que analisa os pontos fortes e fracos de possíveis arquiteturas para um projeto de 
sistema. 
Acompanhe, nesta Dica do Professor, mais detalhes sobre esse método e conheça as seis 
atividades de análise propostas pelo instituto. 
Conteúdo interativo disponível na plataforma de ensino!
EXERCÍCIOS
1) A arquitetura de um sistema é uma área importante da Engenharia de Software, 
responsável por definir um modelo para o sistema que será projetado. Entre as ações 
relacionadas com o projeto de arquitetura de sistemas, é possível citar:
A) definir o processo de inspeção do sistema.
B) determinar o processo de desenvolvimento de um componente.
C) determinar como a interface do sistema se comunicará com as outras camadas do sistema.
D) elencar e testar os componentes de um sistema.
E) definir as métricas de qualidade no âmbito do desenvolvimento do sistema.
2) A escolha de uma arquitetura de sistemas pode minimizar a quantidade de erros e 
aumentar o sucesso de um sistema. Dentro desse contexto, está correto inferir que:
A) definir a arquitetura do sistema contribui para o reúso e para a manutenção do sistema.
B) é tarefa da arquitetura de sistemas elicitar requisitos.
C) uma vez definida a arquitetura do sistema, não é possível alterá-la.
D) a arquitetura do sistema diz respeito aos processos de desenvolvimento do software.
E) a arquitetura do sistema é responsável por estabelecer o fluxo de desenvolvimento do 
software.
3) Existem diversos estilos de arquitetura de sistemas. A figura a seguir representa o 
modelo conceitual de um desses estilos. 
Analisando a imagem, qual sistema pode se adequar nesse modelo? E qual é esse estilo 
de arquitetura?
A) Um sistema de bibliotecas com diversos componentes que se comunicam com um 
repositório de dados. Arquitetura centralizada em dados.
B) Um sistema de faturas em que informações avançam por um fluxo. Arquitetura de fluxo de 
dados.
C) Um sistema bancário em que os componentes são representados por classes que se 
comunicam com um diretório central de dados. Arquitetura orientada a objetos.
D) Um sistema de análises clínicas desenvolvido em várias camadas que se comunicam entre 
si. Arquitetura em camadas.
E) Um sistema de gerenciamento de rede em que vários componentes se comunicam com um 
servidor central. Arquitetura cliente-servidor.
4) Um determinado cliente elaborou a seguinte lista de requisitos para um sistema de 
atendimento ao público em um hospital:
a. A interface do sistema deve ser baseada em um avatar.
b. O sistema deve ser capaz de interagir com o usuário como se fosse um ser humano.
c. O sistema deve aprender e se ajustar a cada novo atendimento.
Baseando-se nessas informações, que gênero de arquitetura de sistemas poderá ser 
utilizado para o desenvolvimento desse sistema?
A) Negócios.
B) Inteligência Artificial.
C) Plataformas.
D) Jogos.
E) Sistemas de saúde.
5) Certa empresa de desenvolvimento de software necessita desenvolver um sistema 
para um banco com algumas funcionalidades, tais como: sacar, depositar, criar 
conta, investir, realizar pagamentos, entre outras. Um requisito não funcional 
prioritário é que esse sistema possua alta manutenibilidade e que partes dele possam 
ser aproveitadas para os próximos módulos que serão desenvolvidos para esse banco. 
Sendo assim, qual é o melhor estilo de arquitetura para este sistema?
A) Arquitetura centralizada em dados.
B) Arquitetura cliente-servidor.
C) Arquitetura de chamadas e retornos e arquitetura orientada a objetos.
D) Arquitetura em camadas e arquitetura de duto e filtro.
E) Arquitetura orientada a objetos e arquitetura em camadas.
NA PRÁTICA
Geralmente, definir a arquitetura do sistema é um passo importante para o desenvolvimento de 
um projeto de software. Em muitos casos, pode ser necessário desenvolver sistemas ou módulos 
para sistemas que já estão implementados. 
Neste Na Prática, acompanhe um caso hipotético no qual uma arquitetura é proposta a partir das 
características do sistema.
SAIBA +
Para ampliar o seu conhecimento a respeito desse assunto, veja abaixo as sugestões do 
professor:
Arquitetura em camadas com uso do paradigma MVC e processo unificado na 
programação de software orientado a objetos
O seguinte artigo apresenta uma aplicação do paradigma arquiteturalde camadas como subsídio 
para a qualidade de software. Confira.
Conteúdo interativo disponível na plataforma de ensino!
Um modelo de arquitetura para sistemas gerenciadores de dados na Web
No artigo a seguir, atente-se para o Capítulo 6 - Prova de conceito do modelo de arquitetura 
para um SGDW, em que é apresentada a aplicação de um sistema com arquitetura cliente-
servidor.
Conteúdo interativo disponível na plataforma de ensino!
Engenharia de software: uma abordagem profissional 
A fim de conhecer uma série de elementos importantes para compreender e aplicar princípios de 
arquitetura de sistemas, leia o Capítulo 13 - Projeto de arquitetura desta obra.
Reúso de software
APRESENTAÇÃO
Desenvolver um software não é uma tarefa simples. Trata-se de um processo caro e lento, 
acompanhado pela pressão por: busca de redução de custos, alcance de ganhos em qualidade do 
produto e diminuição de tempo no desenvolvimento. Sendo assim, através do reúso de software 
é possível evitar retrabalho no desenvolvimento de um novo projeto, levando em consideração 
trabalhos anteriores e fazendo com que soluções previamente desenvolvidas sejam aproveitadas 
e implementadas em novos contextos, aumentando, dessa forma, a qualidade e a produtividade 
dos projetos.
Nesta Unidade de Aprendizagem, você vai identificar os benefícios e também os problemas do 
reúso do software, analisando a construção de softwares utilizando componentes e reconhecendo 
o conceito de frameworks.
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Contrastar os benefícios e os problemas do reúso do software.•
Explicar o conceito de frameworks.•
Analisar a construção de softwares utilizando componentes.•
DESAFIO
O desenvolvimento de um software é um processo que requer atividades organizadas, análise de 
requisitos, além de implementação e teste para manter e implantar o sistema. Sua construção 
pode ser do "zero" ou contar com reúso de software, utilizando, assim, da experiência de outros 
desenvolvedores através de padrões estabelecidos e testados.
Para este Desafio, imagine que você é desenvolvedor de softwares e trabalha na Empresa 
Refactor Code, a qual precisa da implementação de uma nova aplicação.
Acompanhe o caso:
 
Avaliando os quesitos apresentados e prezando por um sistema que satisfaça o cliente e seja 
implementado de maneira inteligente e com o intuito de pular tarefas repetitivas, resolva 
a seguinte questão:
Sabendo que a linguagem de programação utilizada no projeto é o Java, qual framework, 
componente ou API seria mais adequado para implementação do banco de dados dessa 
aplicação? Cite algumas vantagens que comprovem sua escolha.
 
INFOGRÁFICO
O termo reúso compreende uma série de técnicas que podem ser utilizadas, as quais vão desde a 
etapa de modelagem de um projeto até a implementação. Nesse sentido, uma boa técnica de 
reúso de software deve assegurar de forma assertiva a adaptação ao novo contexto.
Tendo isso em vista, acesse o Infográfico a seguir para conhecer as diferentes técnicas de reúso, 
possibilitando comparações, e para entender melhor o que é reúso, suas vantagens e 
desvantagens.
CONTEÚDO DO LIVRO
O reúso de software não é uma atividade nova; ganhou força na década de 1980, quando os 
projetos se tornaram mais complexos e as empresas se obrigaram a procurar formas de facilitar o 
desenvolvimento. A reutilização de software traz conceitos, produtos e soluções já 
implementados, testados e aprovados para a criação de um software. 
No capítulo Reúso de software, da obra Arquitetura de sistemas II, base teórica desta Unidade 
de Aprendizagem, você verá conceitos associados à reutilização de softwares, às vantagens e 
desvantagens do reúso, além de conhecer tipos de reúso e de facilidades em utilizar frameworks 
e softwares baseados em componentes. 
Boa leitura.
ARQUITETURA DE 
SISTEMAS II
Aline Maciel Zenker
Reúso de software
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Contrastar os benefícios e os problemas do reúso do software.
  Explicar o conceito de frameworks.
  Analisar a construção de softwares utilizando componentes.
Introdução
Reúso vem do termo reutilizar e consiste em reaproveitar algo que já 
foi desenvolvido, testado e aprovado. O ato de reutilizar é próprio do 
processo de solução de problemas. Uma vez que se encontre a solução 
de um problema específico, essa solução poderá ser aplicada em outras 
situações em que o problema seja semelhante. O termo reúso, quando 
aplicado ao desenvolvimento de software, está atrelado a uma série de 
análises da engenharia de desenvolvimento de software.
O reúso de software é baseado em conceitos, produtos ou soluções 
elaboradas ou adquiridas na criação de um software novo. Antes de criar 
o software do zero, verifica-se a existência de um projeto semelhante que 
resolva o problema. Reutilizar um software não é apenas uma técnica; 
trata-se de um processo contínuo que a empresa precisa adotar na cria-
ção de projetos e que traz diversas vantagens ao desenvolvimento — e 
algumas dificuldades. A motivação maior em fazer reúso de software é o 
aumento dos níveis de qualidade e produtividade no desenvolvimento. 
Neste capítulo, você vai entender como funciona o reúso de software 
e quais são as vantagens e desvantagens em fazê-lo. Você também vai 
estudar os tipos de reúso, especialmente o reúso com utilização de fra-
meworks, e vai analisar a construção de softwares utilizando componentes.
Origem do reúso de software
Reutilizar especifi cações da engenharia, módulos de um projeto, arquitetura 
e código-fonte de um software não é uma atividade nova. Ao contrário do 
âmbito social, em que o ato de reutilizar normalmente é associado à imitação 
e à falta de criatividade, no desenvolvimento de software, a utilização de 
componentes que já foram aplicados, testados e validados traz aumento de 
produtividade, qualidade e segurança ao software.
Segundo Devmedia (2011), o reúso de software foi introduzido no início 
na década de 1960, quando Doug McIlroy, matemático e informático norte-
-americano, demonstrou interesse em softwares que funcionassem como 
circuitos integrados (CIs) e que pudessem ser fabricados em massa. McIlroy 
examinou os tipos de variabilidade necessários aos CIs e os possíveis tipos 
de CIs que poderiam ser padronizados. Sua visão era baseada na indústria 
de componentes eletrônicos, que podiam ser selecionados em catálogos de 
diferentes fabricantes, apresentando propriedades configuráveis e diferentes 
níveis de confiabilidade.
Mesmo tendo sido conceituado em 1968, o reúso de software ganhou ênfase 
somente na década de 1980, quando os projetos se tornaram mais complexos, 
e as empresas se obrigaram a procurar formas de facilitar o desenvolvimento. 
Foi em 1980 que o primeiro projeto de pesquisa universitário teve o tema de 
reutilização, coordenado por Peter Freeman, na Universidade da Califórnia.
A partir disso, o reúso de software passou a ser considerado uma maneira 
promissora para desenvolver sistemas, ajudando a organização a aumentar a 
produtividade e a qualidade dos projetos. O reúso pode ser aplicado a qualquer 
ciclo de vida de produtos, não apenas ao código-fonte.
Atualmente, existe uma conferência sobre reúso de software, a Conferência Internacional 
sobre Software e Reutilização de Sistemas (ICSR, do inglês International Conference 
on Software Reuse). Trata-se de um evento mundial que ocorre anualmente. A ICSR 
é o principal evento no campo da pesquisa, tecnologia e prática de reutilização de 
software e sistemas. O principal objetivo da ICSR é apresentar os mais recentes avanços 
na área de reutilização de software e sistemas e promover uma troca de ideias intensa 
e contínua entre pesquisadores e profissionais.
Reúso de software2
Vantagens e desvantagens em reutilizar softwares
A principal motivação para o reúso está relacionada àqualidade e à produ-
tividade no desenvolvimento de software. Porém, o reúso apresenta muitas 
outras vantagens quando aplicado de forma efetiva e sistemática, conforme 
descrito a seguir.
1. Melhorias na qualidade de software:
 ■ qualidade do código;
 ■ produtividade;
 ■ confiabilidade.
2. Melhorias na produção:
 ■ entregas mais rápidas;
 ■ menores custos.
3. Melhorias na manutenção do software:
 ■ redução de riscos nos processos;
 ■ reúso de componentes;
 ■ conformidade com padrões;
 ■ validação e testes.
Porém, o reúso de software pode trazer problemas ou obstáculos em sua 
aplicação, conforme elencado a seguir.
  falta de apoio de ferramenta — os ambientes de desenvolvimento podem 
não estar preparados para reutilização;
  dificuldade em encontrar um componente reutilizável para o projeto 
em questão;
  custo maior — muitos componentes não são livres de licença;
  falta de manutenção da biblioteca de componentes escolhida;
  falta de conhecimento/maturidade da equipe para poder aplicar com-
ponentes de reúso;
  falta de padrão no projeto.
Mesmo com algumas dificuldades, as vantagens oferecidas no reúso de 
um projeto se sobressaem, desde que o mesmo seja aplicado de forma correta 
e com responsabilidade.
3Reúso de software
Os autores Kotonya e Sommerville (1998 apud DEVMEDIA, 2011, documento on-line) 
afirmam que “50% dos requisitos normalmente são os mesmos para sistemas e domínios 
semelhantes. O fato de os sistemas serem diferentes conceitualmente e terem diferentes 
stakeholders não significa que eles não possuem requisitos comuns”.
Tipos e técnicas de reúso
Decidir por fazer reúso de software é uma escolha da empresa, que deve estar 
ciente das inúmeras vantagens e dos desafi os ou difi culdades que poderão 
surgir. O reúso pode ser aplicado em qualquer ciclo do projeto, desde a cria-
ção até a implantação do mesmo. É possível fazer a reutilização de ideias, 
especifi cações do projeto, artefatos, códigos-fonte e áreas de testes.
Quando mencionamos o ciclo de vida de um projeto, abordamos uma área 
muito importante a qualquer projeto: a engenharia de software. A engenharia 
de software é responsável pelo estabelecimento de técnicas e práticas para 
o desenvolvimento de software, cobrindo uma ampla área de aplicações e 
diferentes tipos de dispositivos.
O reúso de software pode ser aplicado por meio de técnicas distintas, 
conforme apresentado no Quadro 1. A escolha pela técnica mais apropriada 
vai depender dos requisitos do sistema, da tecnologia disponível, dos dispo-
sitivos de ativos reusáveis e do conhecimento e da experiência da equipe de 
desenvolvimento do projeto.
Tipo de reúso 
de software Abordagem
Padrão de arquitetura Padrões de arquitetura de software que oferecem 
suporte a tipos comuns de sistemas de aplicação; 
são usados como base para outras aplicações.
Padrões de projeto Abstrações genéricas que ocorrem em 
todas as aplicações; são representadas como 
padrão de projetos, podendo ser utilizadas 
em diversos projetos orientados a objetos.
Quadro 1. Tipos e técnicas de reúso
(Continua)
Reúso de software4
Fonte: Adaptado de Sommerville (2011).
Tipo de reúso 
de software Abordagem
Desenvolvimento 
baseado em 
componentes
Subsistemas que são integrados 
para criação da aplicação.
Frameworks de aplicações Coleção de classes abstratas e concretas; 
são adaptadas e estendidas para 
criar sistemas de aplicações.
Empacotamento de 
sistemas legados
Sistemas legados; são empacotados pela 
definição de interfaces de acessos.
Sistemas orientados 
a serviços
Sistemas desenvolvidos pela criação 
de serviços compartilhados.
Linhas de produto 
de software
Família de aplicações desenvolvidas em 
torno de uma arquitetura comum.
Reúso de produtos COTS 
(commercial off-the-shelf )
Sistemas desenvolvidos pela configuração e 
interação de sistemas de aplicação existentes.
Sistemas de ERP (enterprise 
resource planning) 
Sistemas de grande porte que sintetizam a 
funcionalidade e as regras de negócios genéricos.
Aplicações verticais 
configuráveis
Sistemas genéricos; são projetados para 
poderem ser configurados para as necessidades 
dos clientes de sistemas específicos.
Bibliotecas de programas Classes e funções que implementam 
abstrações comumente usadas.
Engenharia dirigida 
a modelos
O código é gerado a partir de modelos de 
domínio e modelos de implementação.
Geradores de programas Um sistema gerador incorpora o 
conhecimento de um tipo de aplicação.
Desenvolvimento de 
software orientado 
a aspectos
Técnica avançada de modularização de 
código para apoiar a reutilização.
Quadro 1. Tipos e técnicas de reúso
(Continuação)
5Reúso de software
Reúso por frameworks
Frameworks são projetos de subsistemas constituídos por uma estrutura 
genérica para criar uma aplicação. Possuem um conjunto de classes, objetos 
e componentes, que favorecem o desenvolvimento por meio do reúso desses 
componentes. Sua implementação no paradigma orientado a objetos é com o 
uso de coleção de classes concretas e abstratas. 
São características básicas de um framework orientado a objetos:
  estrutura reutilizável, bem-documentada e de fácil entendimento;
  estrutura extensível, isto é, suas funcionalidades são abstratas (sem 
implementação), para facilitar o uso e possibilitar que sejam completadas 
com as ações e os parâmetros que o sistema precisar;
  possui uma linguagem segura, evitando que sua estrutura seja destruída 
ao ser utilizado.
Como exemplos de frameworks populares, podemos citar os seguintes frameworks 
em Java:
  Hibernate: framework de persistência — site: https://hibernate.org/
  Java Bean Validator: framework para validação — site: https://beanvalidation.org/
  Spring MVC: framework Web — site: https://spring.io/
Vantagens e desvantagens do uso de frameworks
Muitas equipes de desenvolvimento utilizam frameworks nas suas aplicações, 
trabalhando de forma mais efi caz e criando facilidades na construção de 
sistemas. Mas essa é apenas uma das vantagens da utilização de frameworks. 
Existem outras vantagens no uso de frameworks, bem como desafi os e difi -
culdades. São vantagens do uso de frameworks:
  Eficiência: o desenvolvimento é facilitado, por não ter a necessidade 
de implementar tantas linhas de código, uma vez que diversas rotinas 
comuns estão prontas no framework.
Reúso de software6
  Custo: existem muitos frameworks disponíveis de forma gratuita e no 
modelo open source.
  Apoio técnico: a maioria dos frameworks possui documentação rica 
em detalhes e com explicação de sua aplicação.
  Segurança: códigos são altamente testados e utilizados. Assim, o 
nível de segurança é mais alto, e qualquer falha é avisada e corrigida 
rapidamente.
  Padrões de codificação: para utilizar o framework, é preciso utilizar o 
padrão de escrita determinado por ele. Isso aprimora o código e melhora 
a legibilidade, facilitando o entendimento e a manutenção.
Agora, você pode observar as desvantagens do uso de frameworks:
  Dependência: ao utilizar o framework, sua aplicação fica amarrada a 
ele; caso o mesmo seja descontinuado ou seja atualizado com quebra 
de compatibilidade, o projeto deve ser reestruturado.
  O framework não é uma linguagem: isso significa que o desenvolvedor 
terá que aprender como o mesmo funciona, como é implementado; 
ou seja, deverá aprender as peculiaridades do framework, e não da 
linguagem.
  Sua modificação central não é tão simples: o código-base do fra-
mework normalmente é complexo; o desenvolvedor deve ter conhe-
cimento pleno para que possa modificar sua estrutura, a fim de não 
danificar o uso do framework e prejudicar a aplicação.
  Códigos desnecessários: ao escolher o framework, é importante atentar 
para as funcionalidades e evitar escolher um framework complexo para 
aplicações simples.
Em resumo, um framework é como um kit de ferramentas com inúmeras 
funcionalidades implementadas, testadas, prontas e devidamente adaptadas 
para o reúso em outros projetos, facilitando odesenvolvimento de códigos 
como acesso a banco de dados, sistemas de templates, mapeamento de rotas 
e validação de dados.
Engenharia de software baseada em componentes
A engenharia de software baseada em componentes (CBSE, do inglês compo-
nent based software engineering) é uma abordagem ao desenvolvimento de 
software baseada em reúso de software a partir de componentes. Componente 
7Reúso de software
é um bloco construído para defi nir uma parte da aplicação, uma representação 
de algo a ser implantado, conforme as especifi cações construídas no ciclo de 
vida de um projeto.
Os componentes são abstratos e podem ser considerados prestadores de 
serviços autônomos. Um componente é considerado uma unidade de composi-
ção com interfaces contratualmente especificadas e dependências de contexto 
explícitas. É uma unidade executável independente, como uma interface, e 
os seus serviços são disponibilizados por meio desta. Como objetivos de um 
componente, podemos citar:
  descrever ou realizar uma função específica;
  estar em conformidade e prover um conjunto de interfaces bem-definidas;
  disponibilizar uma documentação adequada;
  estar inserido no contexto de um modelo, que guia a composição desse 
componente junto com outros componentes (arquitetura de software).
Destacam-se as seguintes características dos componentes:
  são implantáveis — para tanto, o componente deve ser autoeficiente, 
o que significa que ele é binário e não precisa ser compilado antes de 
ser implantado;
  precisam ser documentados, para ser possível avaliar se atendem às 
necessidades da aplicação (a sintaxe e a semântica das interfaces devem 
ser especificadas);
  devem ser independentes, possibilitando seu uso e sua implantação 
sem requerer outros componentes específicos (caso haja necessidade de 
outros componentes ou serviços, os mesmos devem ser especificados 
em require — interface que requer algo para funcionar corretamente);
  são representados por uma caixa com o seu nome.
Existem dois tipos de interfaces na linguagem de modelagem unificada 
(UML, do inglês unified modeling language): interfaces provedoras e inter-
faces requeridas (Figura 1). As interfaces provedoras definem os serviços 
prestados pelo componente e são representadas por círculos. Já as interfaces 
requeridas definem quais serviços devem ser fornecidos ao componente e 
são representadas por semicírculos.
Reúso de software8
Figura 1. Interface requerida e interface provedora.
Fonte: Adaptada de Sommerville (2011).
Componentes podem ser simples, como uma função matemática, ou um 
sistema maior, como um componente de planilha de cálculo, um coletor de 
dados ou uma biblioteca de fotos.
A Figura 2 traz um exemplo de modelagem de um componente de serviço para 
impressão UML. Esse componente possui como interfaces requeridas um arquivo 
para impressão e entradas de impressão, como quantidade de páginas, cor, etc. Como 
interface provedora, ou serviços oferecidos, ele apresenta: impressão, remoção da 
impressão, transferência, registro de impressão e saída de registro. O modelo padroniza 
o componente e define suas reais funções no projeto que será implementado.
Figura 2. Exemplo UML de componente de serviço de impressão.
9Reúso de software
O desenvolvimento de software pode fazer uso de diferentes componentes, 
como modelos de componentes para análise do software, modelos para projeto 
e modelos para implementações, como ActiveX, Enterprise Java Beans e 
CORBA. O Enterprise JavaBeans (EJB) é um dos principais componentes da 
plataforma Java Enterprise Edition (Java EE) para desenvolvimento de sistemas 
corporativos. É utilizado para o desenvolvimento e a implantação de aplicações 
distribuídas baseadas em componentes que são escaláveis, transacionais e 
seguros. Um EJB normalmente contém a lógica de negócio, que atua sobre os 
dados de negócio. O mesmo oferece serviços de persistência de dados, controle 
de concorrência, envio de mensagens, serviço de agendamento, chamadas a 
métodos remotos e Web services.
Acesse o link a seguir e saiba mais sobre o EJB, que traz como principal vantagem a 
rapidez em gerar soluções no desenvolvimento de aplicações Java. 
https://qrgo.page.link/kd13Y
Reúso de software10
DEVMEDIA. Reutilização de software. Revista Engenharia de Software Magazine, v. 39, 
2011. Disponível em: https://www.devmedia.com.br/reutilizacao-de-software-revista-
-engenharia-de-software-magazine-39/21956. Acesso em: 12 jul. 2019.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.
Leituras recomendadas
HORSTMANN, C. Padrões e projetos orientados a objetos. 2. ed. Porto Alegre: Bookman, 
2007.
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientado 
a objetos e ao desenvolvimento iterativo. 3. ed. Porto Alegre: Bookman, 2007.
NARAYANAN, V. Dicas para reúso efetivo de software. InfoQ Brasil, 2009. Disponível 
em: https://www.infoq.com/br/articles/vijay-narayanan-software-reuse. Acesso em: 
12 jul. 2019.
PRESSMAN, R.; MAXIM, B. Engenharia de software: uma abordagem profissional. 8. ed. 
Porto Alegre: AMGH, 2016.
SAMETINGER, J. Software engineering with reusable components. Berlin: Springer-Verlag, 
1997
SHALLOWY, A. Explicando padrões de projeto: uma nova perspectiva em projeto orien-
tado a objetos. Porto Alegre: Bookman, 2004.
11Reúso de software
DICA DO PROFESSOR
Framework é um projeto de subsistema constituído por uma estrutura genérica para criar uma 
aplicação; possui um conjunto de classes, objetos e componentes que favorecem o 
desenvolvimento do software através do reúso desses componentes.
Para compreender melhor o conceito de framework, bem como suas classificações e alguns 
frameworks de mercado, assista à Dica do Professor a seguir.
Conteúdo interativo disponível na plataforma de ensino!
EXERCÍCIOS
1) O objetivo do reúso de software é o aumento da produtividade e a redução no esforço 
de desenvolvimento de novos sistemas por parte dos analistas e desenvolvedores. 
Porém, a falta de conhecimento de técnicas de reúso, a falta de ferramentas ou a 
infraestrutura do software podem trazer problemas na implementação.
Nesse contexto, analise as seguintes afirmativas:
I. O uso de padrão de projeto é uma forma de fazer reúso. Os padrões de projetos ou 
Design Patterns, comumente conhecidos, são modelos, referências aplicadas ao 
projeto, trazendo soluções para problemas específicos do desenvolvimento do projeto 
de software orientado a objetos.
II. O sistema ERP é uma estrutura de códigos e é gerado a partir de modelos de 
domínio e modelos de implementação de sistemas legados.
III. Frameworks de aplicações é um tipo de reúso através de abstração, que une 
códigos comuns entre vários projetos de software, incorporando funcionalidades 
genéricas ao sistema.
Verifica-se que é(são) verdadeira(s):
A) somente a I.
B) somente a II.
C) somente a I e a III.
D) somente a I e a II.
E) somente a II e a III.
2) Com a ascensão do desenvolvimento de sistemas, é comum que muitos projetos 
possuam funções ou partes do código semelhantes, isso beneficia os processos de 
criação de software com foco no reúso. Acerca desse assunto, é correto afirmar que:
A) reutilizar softwares existentes não é uma ideia inovadora, ela surgiu em 1968 quando o 
matemático e informático Doug McIlroy demonstrou interesse em integrar circuitos para 
produção em massa; porém, o reúso só ganhou ênfase em 1980, com o surgimento da 
primeira pesquisa sobre o assunto.
B) o reúso de software é considerado uma forma de desenvolvimento com apoio de 
ferramentas, frameworks e exemplos de códigos que ajudam a organização a aumentar a 
produtividade e a qualidade dos projetos. Teve ênfase na década de 1960, com a ideia do 
matemático e informático estadunidense Doug McIlroy, que se mostrou motivado por 
softwares que funcionassem como circuitos integrados.
C) a motivação maior em fazer reúso de software está no aumento dos níveis de qualidadee 
produtividade no desenvolvimento deste. Seu conceito inicial surgiu na década de 1960. 
Através do reúso, é possível implementar grandes sistemas, sem a preocupação com o 
ciclo de vida do projeto, podendo adaptar e pular etapas do desenvolvimento.
D) a reutilização não é uma ideia nova, seu conceito surgiu em 1968 e ganhou foco na década 
de 1980. Tal processo pode ser utilizado em sistemas com contextos diferentes, sendo 
incorporado exclusivamente na implementação do projeto, com uso de código e ações 
prontas.
E) reutilizar especificações da engenharia, módulos de um projeto, arquitetura e código fonte 
de um software não é uma atividade nova, visto que as primeiras ideias sobre reutilização 
de software são do ano de 1968, quando Doug McIlroy mostrou a sua motivação por 
softwares com circuitos integrados. Seu uso é exclusivo à definição de requisitos e testes.
3) Os frameworks são como caixas de ferramentas que possibilitam à equipe de 
desenvolvimento trabalhar com uma coleção de classes concretas e abstratas 
aplicadas a uma linguagem orientada a objetos. São basicamente um template com 
diversas funções que podem ser usadas pelo desenvolvedor.
Sabendo disso, leia as afirmativas a seguir.
I. Entre as características de um framework estão: a linguagem padronizada e 
documentada, a estrutura fixa para facilitar o uso e impedir que a linguagem seja 
corrompida ou danificada, além de ser de fácil entendimento.
II. Uma das desvantagens em utilizar o framework é a dependência da ferramenta 
para seguimento do projeto. Caso a ferramenta não receba atualizações ou seja 
descontinuada, prejudicará a manutenção do sistema desenvolvido com o apoio dela.
III. Para que o desenvolvedor trabalhe com um framework é necessário obter 
conhecimento técnico acerca da ferramenta, aplicando a cada fase do projeto a 
estrutura disponibilizada pelo mesmo. A maioria dos frameworks não disponibiliza 
documentação e apoio técnico, sendo esta uma das desvantagens em seu uso.
Qual(is) está(ão) correta(s)?
A) Apenas a I e a II.
B) Apenas a II e a III.
C) Apenas a I e a III.
D) Apenas a II.
E) Apenas a I.
4) A engenharia de software baseada em componentes é uma abordagem ao 
desenvolvimento de software baseado no reúso, através de um bloco construído para 
definir uma parte da aplicação, uma representação de algo a ser implantado, 
conforme as especificações construídas no ciclo de vida de um projeto.
Sobre as características do software baseado em componentes, assinale a alternativa 
correta.
A) Os componentes precisam ser documentados para avaliar se atendem às necessidades da 
aplicação. Eles são testados, executados e utilizados. Assim, o nível de segurança é mais 
alto, e qualquer falha já é avisada e corrigida.
B) O componente é uma entidade executável e dependente, portanto, o código-fonte não está 
disponível. Além disso, ele não tem que ser compilado antes de ser usado com os outros 
componentes do sistema.
C) O componente é uma estrutura reutilizável para projetos orientados a objetos ou projetos 
web. Ele é como um kit de ferramentas com inúmeras funcionalidades implementadas.
D) Os componentes devem ser dependentes de classes abstratas, e seu uso e implantação 
requererem outros componentes específicos.
E) Os componentes não precisam ser documentados. A sintaxe e a semântica das interfaces já 
são especificadas.
5) Tratando-se da construção de sistemas desenvolvedores experientes, é comum se 
pensar em reúso de software, ou seja, reaproveitar algo que já foi desenvolvido, 
testado e aprovado, o que oferece inúmeras vantagens. No entanto, tal processo 
também pode trazer problemas ou obstáculos. Que problemas são esses?
A) O ambiente de desenvolvimento normalmente não é padronizado e preparado para o reúso, 
não possui conformidade com padrões de escrita e muitas vezes falta conhecimento 
técnico para aplicar o reúso da forma correta.
B) O ambiente de desenvolvimento normalmente não é padronizado e preparado para reúso; 
além disso, o custo do reúso é alto e não compensa o investimento.
C) O custo do reúso é caro e não compensa investimento; além disso, os códigos 
normalmente não possuem padronização, dificultando a aplicação de ferramentas de reúso.
D) Nem todas as ferramentas de reúso são testadas antes de serem disponibilizadas.
E) O reúso de software aumenta os riscos no processo de desenvolvimento de software.
NA PRÁTICA
O reúso de software ajuda a encontrar soluções para problemas semelhantes, ou seja, problemas 
já ocorridos no desenvolvimento de sistemas, que já foram documentados e elaborados padrões 
para serem reutilizados. Escolher um modelo ou técnica apropriada depende de diversos fatores.
Neste Na Prática, acompanhe um estudo de caso envolvendo teste de software em que foi 
utilizado um framework Java.
SAIBA +
Para ampliar o seu conhecimento a respeito desse assunto, veja abaixo as sugestões do 
professor:
Frameworks
Framework é um template com diversas funções que podem ser usadas pelo desenvolvedor. 
Saiba mais no vídeo indicado e conheça as vantagens em utilizá-lo.
Conteúdo interativo disponível na plataforma de ensino!
Listagem de frameworks Java
O desenvolvedor ou arquiteto de software de uma corporação deve conhecer o máximo possível 
das opções de componentes e frameworks existentes no mercado para não cair no velho e já 
conhecido buraco de tentar “reinventar a roda” a sua maneira. Diante disso, acesse o link a 
seguir e conheça a listagem de frameworks e componentes Java.
Conteúdo interativo disponível na plataforma de ensino!
Reúso de software: suas vantagens, técnicas e práticas
Este artigo busca mostrar uma visão geral do conceito de reúso de software, retratando sua 
história, bem como suas principais técnicas e abordagens. Aproveite a leitura.
Conteúdo interativo disponível na plataforma de ensino!
Serviços de desenvolvimento de software: uma abordagem para reutilização de modelos 
conceituais
A fim de aprofundar ainda mais o seu conhecimento sobre o reúso de software, efetue a leitura 
do estudo apresentado a seguir.
Conteúdo interativo disponível na plataforma de ensino!
Descrição de arquiteturas de sistemas
APRESENTAÇÃO
O processo de desenvolvimento de um software tem início com o projeto da arquitetura 
desse sistema. Essa é a fase em que são identificados quais serão os principais componentes do 
sistema a ser desenvolvido. Portanto, é essencial que seja realizada com cautela, já que, dentre 
outros aspectos, a arquitetura impactará no desempenho do sistema. Vale destacar ainda 
que uma arquitetura clara e bem definida ajuda a aumentar a qualidade do projeto e do produto 
de software, influenciando diretamente a satisfação dos usuários.
Nesta Unidade de Aprendizagem, você vai estudar as arquiteturas de sistemas, entender como é 
o processo para o seu desenvolvimento e identificar os seus principais componentes.
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Descrever as características de um diagrama de contexto arquitetural e arquétipos.•
Distinguir componentes e instâncias da arquitetura.•
Identificar as linguagens utilizadas para descrição da arquitetura.•
DESAFIO
A automação residencial tem se tornado uma realidade cada vez mais presente na sociedade. 
Facilidades como controlar a intensidade da luz, ligar ou desligar aparelhos sem mesmo estar 
em casa e ter eletrodomésticos com conexão à Internet são modernidades que facilitam muito a 
vida de todos. Além disso, para pessoas idosas ou com deficiência, automatizar as tarefas mais 
simples pode ajudar a reduzir riscos, assim como melhorar a qualidade de vida.
Imagine, por exemplo, uma pessoa idosa que more sozinha. É noite, ela já está deitada no 
segundo andar de sua residência e não lembra se trancou as portas ou se desligou as luzes 
do andar inferior. Colocar o controle dessas operações em seu telefone celular facilitaria sua 
vidae evitaria acidentes ao fazê-la andar à noite, com sono e sozinha pela casa.
Sob essa perspectiva, considere o seguinte cenário:
Mediante o exposto, seu Desafio é construir o diagrama de contexto arquitetural para 
transformar essa casa de repouso em uma smart home. Não é necessário usar o padrão UML, 
faça apenas um desenho de alto nível da arquitetura e responda as seguintes perguntas:
a) Quais seriam os sistemas superiores, subordinados e de mesmo nível?
b) Quem seriam os atores?
Dica: para criar o diagrama, use algum dos modelos hierárquicos do SmartArt do Microsoft 
Power Point ou outro a sua escolha.
INFOGRÁFICO
Existem diversas linguagens para descrição de arquiteturas, conhecidas por ADL (do inglês, 
Architecture Description Language), que são muito usadas para facilitar a padronização na 
descrição de arquiteturas de sistemas.
Acesse o Infográfico para conhecer uma taxonomia de ADLs, determinada por objetivos e pelo 
tipo de conteúdo que possibilitam criar.
CONTEÚDO DO LIVRO
Em termos gerais, a arquitetura de sistemas é uma maneira de criar sistemas eficientes e 
eficazes, fornecendo base para o entendimento efetivo das necessidades do cliente e oferecendo 
uma visão genérica do sistema, em tempo que ainda haja possibilidade de mudanças a baixo 
custo.
No capítulo Descrição de arquiteturas de sistemas, da obra de Arquiteturas de sistemas, você 
verá quais são as características de um diagrama de contexto arquitetural e o que são arquétipos. 
Você se tornará capaz de distinguir componentes de instâncias de arquitetura e identificar as 
linguagens utilizadas para a descrição de uma arquitetura de sistemas.
Boa leitura.
ARQUITETURA 
DE SISTEMAS
Júlia Mara Colleoni Couto
Descrição de arquitetura 
de sistemas
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Descrever as características de um diagrama de contexto arquitetural 
e arquétipos.
  Distinguir componentes e instâncias da arquitetura.
  Identificar as linguagens utilizadas para descrição da arquitetura.
Introdução
Quando um projeto de arquitetura é criado, ele deve ser baseado em um 
contexto, que leva em consideração as entidades externas ao sistema-
-alvo; isto é, o sistema para o qual um projeto de arquitetura deve ser 
desenvolvido. As entidades externas são consideradas outros sistemas, 
dispositivos, pessoas, etc., que interagem com o sistema-alvo. 
Para estabelecer esse contexto, normalmente são utilizadas as in-
formações que constam no modelo de requisitos elaborado para o 
sistema-alvo. Para a modelagem do contexto, é utilizado um diagrama 
de contexto arquitetural, que apresenta de maneira visual como as 
entidades externas interagem com as fronteiras do sistema-alvo. Com 
esse contexto modelado, o próximo passo é identificar o conjunto de 
arquétipos arquiteturais.
Levando em consideração o modelo de requisitos, os requisitos de 
sistema podem ser divididos em dois tipos: funcionais e não funcionais. 
Os requisitos funcionais especificam o que um sistema faz, enquanto 
os requisitos não funcionais descrevem o quão bem essas funções são 
realizadas. Segundo Blaine e Clevand-Huang (2008), os requisitos não 
funcionais são geralmente mais difíceis de medir e rastrear do que os 
seus equivalentes funcionais. Os requisitos não funcionais tendem a 
ser alcançados em vários níveis ao longo do desenvolvimento de um 
sistema, o que gera desafios em relação às suas especificações, ao 
rastreamento e à implementação.
Neste capítulo, você vai estudar as características de um diagrama 
de contexto arquitetural e o que são arquétipos. Esse conhecimento 
será fundamental para que você consiga distinguir os componentes e 
as instâncias de uma arquitetura e compreender, de maneira objetiva, 
as linguagens utilizadas para a descrição das arquiteturas de sistemas.
Sistema no contexto arquitetural e sua 
representação
Um arquiteto de software, ao modelar um sistema, pode utilizar o diagrama 
de contexto arquitetural para apresentar como um sistema-alvo interage 
com as suas entidades externas. Para a representação do sistema por meio do 
diagrama de contexto arquitetural, é preciso entender quais são os tipos de 
entidades necessários para a elaboração da sua estrutura, abordados a seguir 
com base em Pressman e Maxim (2016).
  Sistemas superiores: utilizam o sistema-alvo como parte de algum 
processamento de nível mais alto.
  Sistemas subordinados: são utilizados pelo sistema-alvo e fornecem 
dados e informações de processamento necessários para complementar 
a função do sistema-alvo.
  Sistemas de mesmo nível (pares): interagem no mesmo nível com 
o sistema-alvo, produzindo ou consumindo as mesmas informações.
  Atores: interagem com o sistema-alvo, produzindo ou consumindo 
informações para o processamento.
Na Figura 1, é apresentado um exemplo de diagrama de contexto arquitetural, 
com as entidades externas que interagem com o sistema-alvo.
Descrição de arquitetura de sistemas2
Figura 1. Diagrama de contexto arquitetural do sistema operacional smartwatch (relógio 
inteligente).
Fonte: Adaptada de Pressman e Maxim (2016).
Com a modelagem do contexto e as entidades externas definidas, um conjunto 
de arquétipos arquiteturais pode ser identificado e especificado. Pressman e 
Maxim (2016) definem arquétipo como uma abstração que apresenta um ele-
mento do comportamento do sistema, semelhante a uma classe, representando 
uma abstração da arquitetura que seja crítica para o projeto do sistema-alvo. 
Ou seja, arquétipos são blocos básicos abstratos de um projeto de arquitetura. 
Os arquétipos representam elementos estáveis da arquitetura, podendo ser 
instanciados de diversas formas, mas se baseiam no comportamento do sistema, 
podendo ser representados usando a linguagem de modelagem unificada 
(UML, do inglês unified modeling language). Por mais que os arquétipos não 
tenham o objetivo de detalhar questões relacionadas à implementação, com um 
conjunto de arquétipos é possível modelar arquiteturalmente como o sistema 
deve ser construído, utilizando uma coleção de abstrações.
Lembre-se de que os arquétipos são a base para a arquitetura. No entanto, são as 
abstrações que devem ser detalhadas à medida que o projeto de arquitetura evolui. 
3Descrição de arquitetura de sistemas
Os pequenos retângulos sombreados no diagrama consistem nas interfaces 
pelas quais cada entidade externa se comunica com o sistema-alvo. É por 
meio delas que os dados devem fluir tanto para dentro quanto para fora do 
sistema-alvo. Faz parte do projeto de arquitetura especificar os detalhes de 
cada interface.
Componentes e instâncias da arquitetura
O domínio da aplicação é a base para o refi namento e a derivação dos com-
ponentes do sistema. Por isso, as classes que são descritas no documento de 
requisitos devem representar as entidades do domínio. Cada comportamento 
defi nido para uma função do sistema, que tenha sido modelado de forma con-
ceitual no documento de requisitos, deve ser descrito em termos de estrutura de 
dados, classes, funções, etc., defi nindo-se, assim, os componentes de sistema.
Os componentes preenchem a arquitetura de software, sendo definidos por 
Pressman e Maxim (2016) como um bloco modular de software de computador. 
Um componente pode ser um módulo que encapsula uma implementação e 
que pode ser implementado ou substituído em um sistema.
Exemplificando componentes e instâncias
Basicamente, a diferença entre componente e instância é que o componente 
defi ne um comportamento do sistema, enquanto a instância é a representação 
real desse comportamento.
Continuando com o exemplo do relógio inteligente, podemos definir um 
conjunto de componentes de alto nível que trata das seguintes funcionalidades.
  Gerenciamento de comunicação externa: responsável por controlar 
a comunicação da função de corrida com entidades externas.
  Processamento da tela de controle: coordena toda a funcionalidade 
da tela de controle. Gerenciamento de sensores: gerencia o acesso a todos os sensores 
conectados ao sistema.
  Processamento de notificações: verifica e atua sobre todas as notifi-
cações geradas por outras aplicações conectadas.
A Figura 2 apresenta o exemplo da estrutura global da arquitetura em 
formato de diagrama UML de componentes. Nela, é apresentada uma 
Descrição de arquitetura de sistemas4
arquitetura de quatro camadas, sendo a camada superior a camada de 
aplicativo, que possui os serviços específicos da aplicação. A camada logo 
abaixo é a camada de negócios, que possui os componentes específicos de 
negócios, que podem ser utilizados em vários aplicativos. A camada de 
middleware possui diferentes componentes, como interfaces para compo-
nentes OLE (object linking and embedding) — como planilhas e editores 
de diagrama —, para serviços do sistema operacional independentes da 
plataforma e para sistemas de gerenciamento de banco de dados. Já a 
camada inferior, a camada de software do sistema, contém componentes 
como interfaces para hardware específico, sistemas operacionais, bancos 
de dados, entre outros.
Figura 2. Estrutura arquitetural global para o sistema relógio inteligente com componentes 
de alto nível.
Fonte: Adaptada de Pressman e Maxim (2016).
Para cada um dos componentes do exemplo da Figura 2, na prática, deveriam ser 
definidas classes de projetos com seus respectivos atributos e métodos pertinentes.
Na Figura 3 é ilustrada uma instância da arquitetura do relógio inteligente 
para a funcionalidade de corrida.
5Descrição de arquitetura de sistemas
Figura 3. Uma instância da função corrida com elaboração de componentes.
Fonte: Adaptada de Pressman e Maxim (2016).
Assim, fica mais fácil compreender que as instâncias são representações 
reais, utilizadas em um problema específico para demonstrar que a estrutura e 
os componentes definidos estão apropriados. Elas são desenvolvidas para “pro-
var” o funcionamento de um componente em um contexto real de utilização.
Linguagens para descrição da arquitetura (ADLs)
Na engenharia de software, utilizam-se linguagens de descrição de arqui-
teturas, mais conhecidas como ADLs (architectural description language), 
para descrever e representar arquiteturas de software. Essa forma de repre-
sentação de arquiteturas auxilia a comunicação mútua e a criação de uma 
abstração transferível de um sistema. No lugar de representar arquiteturas 
por meio de desenhos e ligações, as ADLs trazem uma abordagem lin-
guística (sintaxe e semântica) para a representação formal das arquiteturas 
de software.
Conforme leciona Sommerville (2012), as ADLs possuem elementos bá-
sicos, que são os componentes e os conectores. É neles que são incluídas as 
regras e diretrizes para a criação de arquiteturas bem-formadas. Inicialmente, 
as ADLs eram utilizadas para projetar arquiteturas de software e hardware. As 
arquiteturas de software são usadas para representar e analisar arquiteturas 
Descrição de arquitetura de sistemas6
de sistema, capturando o comportamento das especificações e interações dos 
componentes. Já as arquiteturas de hardware representam os componentes de 
hardware e a sua conectividade, bem como o comportamento das arquiteturas 
dos processadores. 
ADLs, linguagens de programação, modelagem e afins
Como as ADLs diferem das linguagens de modelagem, de programação e 
afi ns? Para Mishra e Dutt (2008), inicialmente, as ADLs diferem das lingua-
gens de programação porque as linguagens de programação vinculam as 
abstrações de arquitetura a implementações pontuais específi cas, enquanto 
as ADLs eliminam ou alteram essa vinculação, de maneira intencional. Na 
prática, a arquitetura é incorporada e recuperável do código por métodos de 
engenharia reversa. 
Em relação às linguagens de modelagem (UML, por exemplo), a di-
ferença é que as linguagens de modelagem estão mais interessadas nos 
comportamentos como um todo, mais do que apenas em partes. Nesse caso, 
as ADLs acabam se concentrando nos componentes. Na prática, linguagens 
de modelagem acabam representando componentes de alto nível e auxiliam 
muito bem no momento da representação das arquiteturas. O que dificulta 
é a falta de uma abstração da descrição do conjunto de instruções de uma 
arquitetura.
As linguagens de descrição de hardware (HDL, do inglês hardware 
description language) podem ser consideradas como qualquer representação 
de linguagem de programação, de especificação ou de modelagem. No entanto, 
elas servem para criar o design e uma descrição formal de circuitos lógicos 
ou de lógica digital. 
Linguagens de programação, linguagens de modelagem e linguagens de 
descrição de hardware têm aspectos em comum com as ADLs e com as HDLs, 
como pode ser observado na Figura 4. A linguagem formal pode ser definida 
como o estudo da especificação de uma linguagem, identificando propriedades, 
características, estruturas, classificação e inter-relacionamentos. A linguagem 
de modelagem serve para expressar alguma informação ou conhecimento por 
meio da criação de regras, que definem como deve ser interpretado o signi-
ficado de cada componente da sua estrutura, como a linguagem UML. Já as 
linguagens de programação são um conjunto de regras sintáticas e semânticas 
utilizadas para definir um programa de computador, que realiza a interface 
de comunicação com um computador por meio de instruções.
7Descrição de arquitetura de sistemas
Figura 4. Relação entre as linguagens de descrição de 
hardware e as linguagens de descrição de arquiteturas.
Fonte: Adaptada de Mishra e Dutt (2008).
O ponto diferencial entre essas linguagens pode ser estipulado de acordo 
com a quantidade de informação arquitetônica que as linguagens podem 
capturar e analisar. Há linguagens que inicialmente são construídas para 
outros propósitos e, mais adiante, acabam sendo utilizadas para representar 
arquiteturas. No entanto, essas linguagens, que não nasceram como ADLs, 
tendem a perder vantagem em relação às que se originaram como ADLs.
BLAINE, J. D.; CLELAND-HUANG, J. Software quality requirements: how to balance 
competing priorities. IEEE Software, [s. l.], v. 25, n. 2, p. 22–24, 2008.
MISHRA, P.; DUTT, N. Introduction to architecture description languages. In: MISHRA, 
P.; DUTT, N. Processor description languages. San Francisco: Morgan Kaufmann, 2008.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8. 
ed. Porto Alegre: AMGH, 2016.
SOMMERVILLE, I. Engenharia de software. 9. ed. Boston: Addison Wesley, 2012.
Descrição de arquitetura de sistemas8
Leituras recomendadas
O QUE é arquitetura de software? Microsoft, [s. l.], [2019?]. Disponível em: https://msdn.
microsoft.com/pt-br/hh144976.aspx. Acesso em: 17 jun. 2019.
O QUE é um arquiteto de software? Infobase, [s. l.], [2019?]. Disponível em: http://infobase.
com.br/atividades-arquiteto-de-software/. Acesso em: 17 jun. 2019.
9Descrição de arquitetura de sistemas
DICA DO PROFESSOR
Requisitos não funcionais impactam diretamente nas decisões relacionadas à descrição da 
arquitetura dos sistemas, devendo ser levados em consideração e priorizados para que a 
arquitetura atenda de forma satisfatória aos requisitos mais críticos.
Tendo isso em vista, assista a esta Dica do Professor para conhecer esses requisitos e 
verificar como você pode projetar sua arquitetura de sistemas para melhor atendê-los.
Conteúdo interativo disponível na plataforma de ensino!
EXERCÍCIOS
1) O arquiteto, ao desenvolver um projeto, considera um conjunto de requisitos que 
motivam e justificam suas decisões. Para que o sistema seja desenvolvido, há também 
metas de qualidade a serem levadas em conta, bem como cenários de uso, padrões de 
projeto e estilos arquiteturais existentes. Nesse contexto, ao criar um projeto de 
arquitetura, deve-se considerar as entidades externas relacionadas ao sistema-alvo.
O que define essas entidades externas?
A) As entidades externas são representações gráficas de uma arquitetura de