Engenharia
Nesta seção você encontra artigos voltados para testes, processo,
modelos, documentação, entre outros
Definição de arquiteturas de referência
Exemplos e processos para projetar arquiteturas de referência
Edson A. Oliveira Junior
edson@din.uem.br
Professor de Engenharia de Software na Uni-
versidade Estadual de Maringá (UEM). Doutor
em Ciência da Computação pelo Instituto de
Ciências Matemáticas e de Computação (ICMC)
da Universidade de São Paulo (USP). Principais
temas de pesquisa: linha de processo de softwa-
re, linha de produto de software, arquitetura de
software e avaliação, métricas, engenharia de
software experimental, modelos e metamode-
los UML. Possui as certificações Java: SCJA, SCJP,
SCJD, SCWCD e SCBCD.
Ana Paula Allian
ana.allian@gmail.com
Aluna de Mestrado em Ciências da Computação
pela Universidade Estadual de Maringá. Bolsista
da Coordenação de Aperfeiçoamento de Pessoal
de Nível Superior (CAPES) na área de Sistema da
Informação. Trabalhando especificamente com
Arquiteturas de Referência e Gerenciamento de
Variabilidade. Possui Especialização em Desen-
volvimento de Sistemas Web pela Universidade
Estadual de Maringá (UEM).
Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia
A
s exigências em aumentar a
funcionalidade, qualidade e
manter um padrão de software,
além de reduzir custos, levou a comu-
nidade de engenharia de software a
investigar e propor uma infraestrutura
central conhecida como arquitetura de
referência.
Arquitetura de Referência (AR) é um
tipo especial de arquitetura de software
e refere-se a uma arquitetura que englo-
ba o conhecimento sobre como projetar
arquiteturas de software concretas dos
sistemas de um determinado domínio
de aplicação. Tal arquitetura deve con-
siderar as regras de negócio, estilos ou
padrões arquiteturais que abordam os
atributos de qualidade da AR. Além
Edição 75 - Engenharia de Software Magazine 47
Fique por dentro:
Neste artigo será apresentado uma visão ge-
ral sobre arquitetura de referência, um tipo
especial de arquitetura de software que en-
globa o conhecimento sobre como projetar
arquiteturas de concretas dos sistemas de um
determinado domínio de aplicação, abrangen-
do terminologias relacionadas à arquitetura
de referência, bem como definições, conceitos,
objetivos, benefícios e limitações. Além disso,
serão apresentados dois exemplos de processo
que podem ser utilizados para apoiar o desen-
volvimento de arquiteturas de referência. O
entendimento deste tema é útil uma vez que
estas arquiteturas permitem a reutilização de
conhecimento e experiência de projetos o que
fornece mais qualidade e agilidade no processo
de desenvolvimento.
disso, deve abranger as melhores prá-
ticas de desenvolvimento de software,
por exemplo, decisões de arquitetura,
restrições de domínio, legislação e nor-
mas, além dos elementos de software
que suportam o desenvolvimento de
sistemas para esse domínio.
Neste artigo apresentaremos uma visão
geral sobre arquiteturas de referência,
47
abrangendo terminologias relacionadas à área de pesquisa de
arquitetura de software com objetivo de elucidar as definições
de termos relacionados a ela. Também serão abordados seus
principais conceitos, objetivos, definições, benefícios e limita-
ções. Além disso, discutiremos as diferenças existentes entre
arquiteturas de referência e arquitetura de linha de produto
de software. Também serão apresentados alguns exemplos
de arquiteturas de referência consolidas no mercado. Por
conseguinte, abordaremos dois processos para se projetar
arquiteturas de referência.
Terminologias
Antes de aprofundarmos o conhecimento sobre arquitetura
de referência, é importante compreender claramente outros
conceitos que envolvem a área de arquitetura de software.
Os termos mais utilizados nessa área são: arquitetura de
software, padrão arquitetural, estilo arquitetural e modelo
de referência.
A arquitetura de software, também chamada de arquitetura
concreta, tem sido uma área de pesquisa fundamental em
engenharia de software, devido ao seu profundo impacto
sobre a produtividade e qualidade de software. Uma arqui-
tetura de software é a estrutura (ou estruturas) do sistema
que compreendem os elementos de software, as propriedades
externamente visíveis desses elementos e os relacionamentos
entre eles. Apesar de promover um conjunto de boas práticas
de desenvolvimento de software análogo à arquitetura de
referência, há diferenças entre esses dois conceitos que devem
ser mencionadas:
• Arquiteturas de referência são definidas em um alto nível de
abstração se comparado com arquiteturas de software devido
à sua natureza mais geral;
• Arquitetura de software possui um grupo definido das
partes interessadas no projeto, enquanto que na arquitetura de
referência essa definição não é clara devido à composição de
grupos heterogêneos de partes interessadas que pode evoluir
em diferentes empresas;
• Arquitetura de referência tem de resolver mais atributos
de qualidade arquiteturais comparados a uma arquitetura
de software. Há também requisitos não funcionais que são
importantes apenas para arquiteturas de referência tais como
a aplicabilidade ou viabilidade da arquitetura;
• Arquitetura de software consiste em um grupo de especi-
ficações que direcionam o desenvolvimento individual dos
módulos de software pertencentes a um sistema.
Padrão arquitetural e estilo arquitetural são conceitos análo-
gos e correspondem a uma descrição dos elementos e dos tipos
de relacionamentos juntamente com um conjunto de restrições
sobre como eles podem ser utilizados. Tal conceito é mais
abrangente, pois define um conjunto de restrições quanto à
forma e a estrutura de uma família de arquiteturas de software.
Além disso, ele é construído abrangendo experiências bem-
sucedidas de profissionais de desenvolvimento de software
que aplicam esses padrões em novos projetos.
48 Engenharia de Software Magazine Copyright
- Medição de- Software
Proibidonocopiar
CMMIou
e MPS.BR
48
Alguns padrões representam soluções conhecidas para os
problemas de desempenho, outros para sistemas de alta segu-
rança, outros têm sido utilizados com sucesso em sistemas de
alta disponibilidade. Exemplos de padrão/estilo arquitetural
são: i) Estilo cliente-servidor: separa o sistema em duas apli-
cações em que o cliente faz solicitações ao servidor; ii) Estilo
arquitetura em camadas: distribui os interesses da aplicação em
grupos empilhados que são as camadas; iii) Estilo de arquitetura
baseada em componentes: o projeto da aplicação é decomposto
em componentes reutilizáveis, tanto funcionais ou lógicos, que
expõem interfaces de comunicação bem definidas.
Diferentemente de uma arquitetura de referência, um padrão
arquitetural apenas descreve a organização e funcionamento
dos componentes do sistema, mas não descreve a finalidade de
um sistema. Por outro lado, o foco da arquitetura de referência
está na definição das funcionalidades necessárias de um dado
domínio (definido no modelo de referência correspondente) e a
sua interação com o ambiente de domínio. Portanto, os padrões
arquiteturais são independentes do domínio da aplicação e
são concebidos para abordarem certos atributos de qualidades
(desempenho, interoperabilidade).
Modelo de referência é uma divisão do sistema em fun-
cionalidades que juntas cooperam entre se para resolver um
problema. Tais funcionalidades são produtos de experiência
da equipe técnica e de negócio. Um modelo de referência
não está diretamente ligado a normas, tecnologias ou outros
detalhes de práticas de implementação, mas procura oferecer
uma semântica comum que pode ser usada de forma não
ambígua por diferentes implementações. Por outro lado, uma
arquitetura de referência abrange o conhecimento sobre como
projetar arquiteturas concretas, portanto ela deve abordar as
regras de negócio, padrões/estilos arquiteturais, melhores
práticas de desenvolvimento de software e elementos de
software que apoiam o desenvolvimento de sistemas para
determinado domínio.
Modelo de referência, padrões/estilos arquiteturais e arqui-
teturas de referência não são arquiteturas, mas conceitos úteis
que capturam elementos de uma arquitetura. Tais conceitos
são resultados de decisões de projetos anteriores, conforme
visualizado na Figura 1.
Figura 1. Relação entre modelo de referência, padrões de arquitetura,
arquiteturas de referência e arquiteturas de software
Arquitetura de Referência
Arquitetura de referência é considerada um padrão pré-
definido projetado para um determinado contexto de negócio.
Tal conceito faz uso de artefatos muitas vezes concebidos em
projetos anteriores. Para isso, ela deve possuir conhecimento
distribuir. Todos os direitos reservados para DevMedia

e informação adquirida. Além disso, uma AR alcança a com-
preensão de domínios específicos bem reconhecidos, promo-
vendo a reutilização de experiências em projetos e facilitando
o desenvolvimento, padronização, qualidade e evolução de
sistemas de software.
Em síntese, uma AR deve abranger três conceitos principais:
• Elementos técnicos: fornece soluções em tecnologia abran-
gendo os padrões de projeto e padrões arquiteturais;
• Modelo de negócio: abrange os modelos de negócio e ciclo de
vida do projeto, além de guiar as decisões no domínio técnico;
• Necessidade dos clientes: as orientações são fornecidas por
processos e considerações do domínio empresarial, cliente e
usuário.
A Figura 2 mostra a união da arquitetura de negócio, ar-
quitetura técnica e de contexto do cliente representando uma
arquitetura de referência. O único denominador comum são
os requisitos onde as características (Features) e funções são
modelados de forma independente no produto.
Figura 2. Modelo de negócios, Elementos técnicos e Necessidade dos
clientes formam juntos a Arquitetura de Referência
Portanto, AR é uma arquitetura generalizada com base nas
melhores práticas e pode ser aplicada a várias soluções como
no meio automotivo, aviação e robótica. Um exemplo de AR
é um compilador. Há uma noção geral dos elementos básicos
de um compilador (por exemplo, front-end, back-end, tabela de
símbolos), o que devem fazer, e como eles estão interligados.
Se algum arquiteto de softwares for idealizar um novo compi-
lador não irá começar do zero, mas sim com uma arquitetura
básica de referência em mente.
Um dos objetivos da AR é capturar o conhecimento implícito
para simplificar o desenvolvimento de novos produtos. Uma
das vantagens é a de facilitar a reutilização e, assim, obter
maior economia por meio da redução de ciclos de tempo, cus-
to e risco, além de um aumento da qualidade. O controle de
qualidade é realizado por meio da verificação de conformidade
dos sistemas em desenvolvimento para AR. Esta verificação de
conformidade pode ser realizada semiautomática e continu-
amente, automatizando passos importantes como a extração
da arquitetura do aplicativo real, a ligação de funções da AR
Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia
ENgENhARiA
para os elementos de uma arquitetura de aplicação específica,
bem como a avaliação das regras de AR para uma arquitetura
de aplicativo. Além disso, outra vantagem está no potencial de
aumento da interoperabilidade, tanto dentro das corporações,
bem como dentro das indústrias e domínios.
Diferenças entre Arquitetura de LPS e Arquitetura de
Referência
Arquitetura de Referência e Arquitetura de Linha de Produto
de Software (ALPS) são conceitos frequentemente considerados
equivalentes, pois ambos têm como objetivo melhorar o desen-
volvimento do sistema de software por meio da padronização das
arquiteturas de um conjunto de sistemas de software. Apesar das
semelhanças entre AR e ALPS existem diferenças importantes
entre esses dois conceitos que devem ser mencionadas. A Figura
3 e os itens a seguir apresentam as diferenças entre elas:
• ALPS geralmente se aplica a um conjunto de produtos
dentro de uma organização ou empresa e pode ser baseada
em uma AR;
• ALPS são AR, mas nem todas as ARs são ALPS;
• ALPS pertence ao núcleo de artefatos de uma linha de produ-
to e, por ser um artefato, ela dita “o que o projeto é”, enquanto que
as ARs ditam os padrões e princípios para a implementação,
ou seja, “o que o projeto deve ser”;
• ALPS são mais especializadas, com foco, por vezes, em um
subconjunto específico de sistemas de um domínio de software
com fornecimento de soluções padronizadas para uma família
menor de sistemas e preocupados com as variabilidades entre
os produtos;
• ARs estão, em geral, em um nível mais alto de abstração em
comparação com ALPS.
Pode-se observar que a ALPS é produzida no núcleo de artefa-
tos na engenharia de domínio e também envolve as atividades
de gerenciamento que engloba as atividades que representam
variabilidades em artefatos de software. Entretanto, uma AR
possui um nível de abstração maior, envolvendo conceitos,
terminologias e conhecimento relacionados ao projeto arqui-
tetural e melhores práticas. A relação entre esses dois conceitos
é que temos uma AR e uma possível instância dessa AR pode
ser uma ALPS como também pode ser uma arquitetura de
software normal. Consequentemente, uma ALPS pode ser
uma instância da AR e quando se instancia uma ALPS, as
variabilidades são resolvidas e como resultado obtêm-se uma
arquitetura de um produto.
Benefícios e limitações das Arquiteturas de Referência
Apesar de muitas vantagens em se utilizar uma AR como, por
exemplo, facilitar o reuso em projetos de software, há também
algumas desvantagens que devem ser consideradas antes de
iniciar uma atividade tão abrangente como projetar uma AR.
Benefícios
A arquitetura de referência ajuda a garantir que os usuá-
rios finais e desenvolvedores possuam mais confiança na
Edição 75 - Engenharia de Software Magazine 49
49
tecnologia desenvolvida por meio da reutiliza-
ção de experiência em projetos. Esse e outros
benefícios da arquitetura de referência podem
ser vistos a seguir:
• Reduz o risco de implantação, pois conta com
soluções conhecidas e testadas;
• Simplifica a tomada de decisão;
• Fornece modelos mais consistentes;
• Aumenta a confiança da equipe de de-
senvolvimento por contar com soluções
comprovadas;
• Reduz as lacunas culturais entre as organi-
zações, pois une a experiência e conhecimento
de diferentes seguimentos em um modelo
comum;
• Fornece orientação para várias organizações
que evoluem ou criam novas arquiteturas;
• Aumento da interoperabilidade, tanto den-
tro das corporações, assim como dentro das
indústrias e domínios.

Outros motivos para se utilizar arquiteturas Figura 3. Diferenças entre Arquitetura de Referência e Arquitetura de LPS.
de referência são:
• Fazendo uso de AR é possível iniciar o desenvolvimento de
aplicações desde o primeiro dia seguindo decisões de arqui-
tetura já tomadas;
• Uma AR indica as diretrizes a serem seguidas pelos desen-
volvedores de aplicativos;
• Uma AR reduz a complexidade no desenvolvimento de apli-
cações porque parte das funcionalidades já estão resolvidas;
• Uma AR aumenta o controle sobre aplicações por meio da
sua homogeneidade. Isso gera uma redução do custo de ma-
nutenção das aplicações;
• Uma AR ajuda a melhorar os processos de negócio de uma
organização.
Limitações
Apesar das vantagens citadas, deve-se considerar alguns
aspectos que podem se tornar um risco em projetos de arqui-
tetura de referência:
• Uma AR implica em um treinamento adicional para a equipe
envolvida no projeto aumentado a curva de aprendizado;
• Aplicações dependem dos módulos reutilizáveis da AR. Se
for necessário fazer mudanças em tais módulos, desenvolve-
dores terão de aguardar até que a alteração seja concluída;
• O uso de um RA implica em seguir suas orientações durante
o desenvolvimento de aplicativos e adotar seu projeto arquite-
tural. Se as necessidades de negócio exigirem um tipo diferente
de aplicação, a AR limitaria essa flexibilidade.
Exemplos de Arquitetura de Referência
Diferentes domínios já encapsularam experiências e conheci-
mento de projetos em arquiteturas de referência com o objetivo
de padronizar, divulgar e reutilizar essas experiências em no-
vos projetos. Bons exemplos são AUTOSAR (AUTomotive Open
System Architecture), para o domínio automóvel, “Continua”
para sistemas de saúde pessoal, e UniversAAL, para Ambient
Assisted Living (AAL). Em particular, essas arquiteturas têm
sido desenvolvidas por consórcios que envolvem grandes
parceiros industriais tais como, fabricantes, fornecedores e
pesquisadores.
AUTOSAR
Automotive Open System Architecture (AUTOSAR) é uma arqui-
tetura de referência criada para definir regras para o desenvolvi-
mento de hardware, software e comunicação entre os módulos
automotivos, objetivando o reuso destes desenvolvimentos entre
montadoras. O AUTOSAR é uma cooperação mundial entre as
montadoras, fornecedores e outras empresas do ramo.
AUTOSAR é distinta em aplicação e peças de software
básicas que se comunicam entre si por meio de um midd-
leware de ambiente de tempo real Runtime Environment (RTE).
Os seus componentes encapsulam e caracterizam o software
e permitem uma troca de dados apenas por meio de interfaces
bem definidas.
A Figura 4 apresenta a arquitetura AUTOSAR. Todos os
módulos eletrônicos internos são conectados por meio do AU-
TOSAR Runtime Environment RTE. Este ambiente é um centro
de troca de informações entre os componentes de software.
O RTE possui uma interface que precisa ser customizada para
cada componente:
• Application Layer: a camada de aplicação está fora do escopo
do AUTOSAR e corresponde à aplicação do cliente;
• AUTOSAR Runtime Environment (RTE): fornece serviços
de comunicação para os componentes de software AUTOSAR
e/ou para os componentes do sensor do atuador do sistema
AUTOSAR;

50 Engenharia de Software Magazine Copyright

- Medição de- Software
Proibidonocopiar
CMMIou
e MPS.BR
distribuir. Todos os direitos reservados para DevMedia
50

• Services Layer (System Services, Memory-Services e
COM Services): fornece serviços básicos para os módulos de
software da aplicação, tais como: operação de funcionalidades
do sistema; serviços de comunicação; gerenciamento de redes
de veículos; serviços de memória; serviços de diagnóstico;
gerenciamento de estado da ECU (Electronic Control Units);
• ECU Abstraction Layer: a camada abstrata da unidade de
controle eletrônico fornece interfaces para os drivers na camada
Microcontroller Abstraction Layer e componentes de drivers para
os dispositivos externos. Isso é feito por meio de uma API de
acesso a periféricos e dispositivos independentemente da sua
localização física e conectividade;
• Microcontroller Abstraction Layer: a camada de abstração
de microcontrolador é a camada mais baixa do software básico.
É composta por controladores internos com acesso direto aos
periféricos internos do microchip e dispositivos externos de
memória mapeada;
• Microcontroller: é a camada do microcontrolador do sistema
AUTOSAR;
• Complex Drivers: é a camada que dispõe dos drivers com-
plexos do sistema AUTOSAR.
Figura 4. Arquitetura de Referência AUTOSAR
A vantagem da AUTOSAR está em sua flexibilidade. Ela pode
transferir funções entre módulos se necessário, para garantir
a customização em diferentes empresas gerando diversas
características e tipos de veículos variados.
Continua
Continua Health Alliance é uma organização sem fins lucrativos
que une organizações prestadoras de cuidados a saúde e em-
presas de tecnologia. O objetivo desta colaboração é a melhoria
da qualidade da saúde pessoal por meio de desenvolvimento
de padrões de projeto e ferramentas de testes para acelerar a
implantação de dispositivos interoperáveis ligados à saúde
pessoal. Além disso, desenvolve sistemas de gestão da saúde,
melhorando os resultados clínicos e a qualidade de vida.
A arquitetura de referência do Continua é uma arquitetura
end-to-end (E2E) e está representada na Figura 5.
A arquite
cionalidad
e quatro in
Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia
ENgENhARiA
para uma topologia de referência. As interfaces de rede
estão no centro dos objetivos de interoperabilidade do Con-
tinua e são o ponto crucial das metas de teste e certificação
para garantir que os produtos de diferentes fornecedores
trabalhem juntos. O nível mais alto do Continua identifica
as seguintes interfaces:
• Personal Area Network (PAN): é a interface para a comunicação
em torno de uma pessoa;
• Local Area Network (LAN): interface para comunicação em
um local ou instalação;
• Wide Area Network (WAN): interface para comunicação em
casa/escritório/prestadores de serviços, e;
• Health Reporting Network (HRN): interface de rede para gerar
os relatórios de serviços à saúde aos sistemas corporativos tais
como hospitais, prestadores de serviços de telesaúde.
Figura 5. Arquitetura de Referência do Continua
UniversAAL
UniversAAL é uma plataforma universal aberta e uma espe-
cificação de referência para ambiente de vida assistida Ambient
Assisted Living. Esta especificação fornece uma abordagem
padronizada tornando-se técnica e economicamente viável
para desenvolver soluções AAL.
A Figura 6 apresenta a plataforma UniversAAL que consiste
em três partes principais que são: Runtime Support, Development
Support e Community Support.
Runtime Support consiste em um ambiente de software que
fornece serviços de núcleo AAL para a execução de aplicações
AAL e também é um ambiente de software que disponibili-
za assistência aos serviços para a execução das aplicações.
É composto por:
• Execution Environment (API, OS and Hardware): é o
nível mais baixo do ambiente Runtime Support e fornece uma
interface comum para abstrair recursos, por exemplo, sensores
que enviam dados através da plataforma universAAL. Essa
camada lida com a heterogeneidade de componentes e facilita
a integração e comunicação entre eles;
• Generic Platform Services: software que adiciona funcio-
s de serviços genéricos ao UniversAAL;
atform Services: são softwares que proporcionam
idades em nível empresarial ao UniversAAL.
Edição 75 - Engenharia de Software Magazine 51
51
 Development Support inclui documenta-
ção, ferramentas e um repositório on-line
de vários recursos de desenvolvimento. É
composto por:
• Developers Depot: é um repositório onde a
comunidade de desenvolvedores AAL pode
navegar, baixar e publicar novos serviços;
• Developers Tools: um ambiente de de-
senvolvimento integrado proporcionando
editores UML e de código adaptados à
UniversAAL;
• Reference Architecture e Guidelines:
conjunto de modelos que definem o domínio
AAL e são usados para apoiar o desenvolvi-
mento da plataforma e os serviços.
Figura 6. Arquitetura de Referência do UniversAAL
Community Support inclui treinamento e
uma ferramenta online que fornece serviços
e aplicativos AAL. Consiste dos seguintes componentes:
• uStore: permite aos provedores de serviços especificarem
serviços AAL completos;
• Example Services: são os exemplos de serviços prestados;
• Training material: material de treinamento focado nos as-
pectos técnicos do UniversAAL;
• Roadmaps: definição de roteiros e fornecimento de recomen-
dações da arquitetura de referência UniversAAL.
Processos para Construção de Arquiteturas de Referências
Nesta seção abordaremos dois processos que apoiam o
desenvolvimento de arquiteturas de referência. O primeiro
processo, conhecido por ProSA-RA, sistematiza os passos
para construção de uma AR para que se alcance um produto
de qualidade. O segundo processo fornece um ciclo para o
desenvolvimento de uma arquitetura de referência.
Processo ProSA-RA
O desenvolvimento de Arquiteturas de Referências não é algo
trivial e por isso exige conhecimento do domínio e processos
sistemáticos para consolidar uma proposta de AR de quali-
dade. O ProSA-RA é um processo iterativo que sistematiza
os passos para construir, representar e avaliar arquitetura de
referência (AR).
O ProSA-RA, conforme ilustrado na Figura 7, é dividido em
quatro etapas:
• Etapa 1. Investigação das fontes de informações: obtidas
de pessoas, sistemas de softwares, publicações de revistas,
livros, outros modelos de referência, ontologias de domínio,
etc. As informações adquiridas devem envolver os proces-
sos e atividades que podem ser suportados por sistemas de
software do domínio a ser desenvolvido. Deve-se, portanto,
obter conhecimento abrangente sobre o domínio. A Figura 8
apresenta uma visão conceitual de captura de conhecimento
e informação do domínio de ferramentas de gerenciamento
de variabilidade (GV) para o projeto de AR. Observe que um
conjunto de ferramentas de GV pode ser utilizado para fornecer
informações ao projeto de uma AR. Tal AR serve como base
para desenvolver novas ferramentas de GV;
• Etapa 2. Estabelecimento dos requisitos arquiteturais: com
base nas fontes selecionadas, três conjuntos de elementos são
identificados. Em primeiro lugar, o conjunto de requisitos
de sistemas de software de domínio são identificados e, com
base nesses requisitos, o conjunto de requisitos da AR é então
estipulado. Em seguida, o conjunto de conceitos que devem ser
considerados nessa arquitetura de referência é estabelecido;
• Etapa 3. Projeto arquitetural: nesta etapa a descrição ar-
quitetural é construída utilizando os estilos e os padrões de
arquitetura, bem como uma combinação destes e de outros
estilos, provavelmente identificados no Passo 1. Estes estilos
e padrões são a base sobre a qual os conceitos previamente
identificados são organizados. Textos e diagramas UML podem
ser utilizados para representação da AR em diferentes visões
arquiteturais como: visão estrutural, visão de implantação,
visão de tempo de execução, etc.;
• Etapa 4. Avaliação Arquitetural: verificar a descrição da
arquitetura junto às partes interessadas com o objetivo de
detectar defeitos na descrição da arquitetura. Pode-se utilizar
checklist e frameworks de avaliação disponíveis no mercado.
É fundamental a definição do escopo, que pode ser realizado
com base no conjunto de sistemas que se destinam a ser pro-
duzidos a partir da arquitetura de referência.
Segundo Processo
A Arquitetura de Referência captura experiências anteriores,
por exemplo, mineração ou generalização de arquiteturas exis-
tentes que estejam documentadas utilizando algum framework
arquitetural. Além disso, a arquitetura de referência depende
da visão baseada nas necessidades (futuras) de clientes e de
negócios. Estas necessidades são exploradas e analisadas para
serem transformados em requisitos futuros para o portfólio
de produtos.
A Figura 9 mostra esse fluxo de conceitos comprovados e
problemas conhecidos a partir de arquiteturas existentes e

52 Engenharia de Software Magazine Copyright

- Medição de- Software
Proibidonocopiar
CMMIou
e MPS.BR
distribuir. Todos os direitos reservados para DevMedia
52

visões derivadas das necessidades dos
clientes/ negócio. Observa-se que no
ciclo a arquitetura de referência deve
evoluir continuamente e deve ser ativa-
mente mantida e refatorada.
Este artigo apresentou uma visão
geral de arquiteturas de referência que
abrangem conhecimento sobre como
Figura 7. Etapas do Processo ProSA-RA
Figura 8. Visão conceitual para aquisição de conhecimento para o desenvolvimento de AR
Figura 9. Entradas de uma Arquitetura de Referência
Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia
projetar arquiteturas de software de
um determinado domínio de aplicação.
Pode-se observar que uma arquitetura
de referência deve abranger conceitos
relacionados a modelos de referência
e padrões arquiteturais somados à
necessidade dos clientes. Portanto, ela
deve abordar as regras de negócio,
Edição 75 - Engenharia de Software Magazine 53
ENgENhARiA
estilos arquiteturais, melhores práticas
e elementos de software que suportam
o domínio.
Entre as vantagens citadas sobre arqui-
tetura de referência está a reutilização de
conhecimento e experiência de projetos o
que fornece mais qualidade e agilidade
no processo de desenvolvimento. Há
várias iniciativas de arquiteturas de
referência em diferentes domínios como
robótica, setor automotivo, saúde e se-
gurança. Basicamente, uma arquitetura
de referência deve ser compreensível,
atualizada e de fácil manutenção.
Links:
Bass, L., Clements, P. & Kazman, R., 2003.
Software Architecture in Practice. 2 ed. s.l.:
Addison Wesley.
Cloutier, R. et al., 2010. The Concept of Re-
ference Architectures. Systems Engineering,
13(1), p. 14–27.
Martínez-fernández, S., Ayala, C. P., Franch, X. &
Marques, H. M., 2013. REARM: A Reuse-Based Eco-
nomic Model for Software Reference Architectures.
Safe and Secure Software Reuse, 7925(Lecture
Notes in Computer Science), pp. 97-112.
Nakagawa, E. Y. et al., 2014. Consolidating a
process for the design, representation, and eva-
luation of reference architectures. Proceedings
of the 2014 IEEE/IFIP Conference on Software
Architecture, Washington, DC, USA, p. 143–152.
OliveiraJr, E. & Allian, A. P., 2015. Do Reference
Architectures can Contribute to Standardizing
Variability Management Tools? Proceedings of
the 1st International Workshop on Exploring
Component-based Techniques for Constructing
Reference Architectures (CobRA), Montreal
Canadá, May, pp. 9-12.
Você gostou deste artigo?
Dê seu voto em
www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!
53