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
2 Descrição de arquitetura de sistemas

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 sistemas 3

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.
4 Descriçã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 refinamento 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
definido 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., definindo-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
define 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 sistemas 5

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.
6 Descriçã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 sistemas 7

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
afins? 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íficas, 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.
8 Descriçã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 sistemas 9

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.