Projeto de Arquitetura de Software

Prévia do material em texto

CAPÍTULO
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
6.1 Decisões de projeto de arquitetura 
6.2 Visões de arquitetura
6.3 Padrões de arquitetura
6.4 Arquiteturas de aplicações
Co
nt
eú
do
Projeto de arquitetura
Objetivos
O objetivo deste capítulo é introduzir os conceitos da arquitetura 
de software e do projeto de arquitetura. Depois da leitura, você: 
compreenderá por que o projeto de arquitetura de software é 
importante;
compreenderá as decisões necessárias sobre a arquitetura de sis-
tema durante o processo de projeto de arquitetura;
terá sido apresentado aos padrões de arquitetura, bem como às 
maneiras já experimentadas de organizar as arquiteturas de siste-
ma, que podem ser reusadas em projetos de sistemas;
conhecerá os padrões de arquiteturas que muitas vezes são 
usados em diferentes tipos de sistemas de aplicações, incluindo 
sistemas de processamento de transações e os sistemas de 
processamento de linguagens.
O projeto de arquitetura está preocupado com a compreensão de como um sistema deve ser organizado e com a 
estrutura geral desse sistema. No modelo do processo de desenvolvimento de software, o projeto de arquitetura 
é o primeiro estágio no processo de projeto de software, como mostra o Capítulo 2. É o elo crítico entre o projeto e a 
engenharia de requisitos, pois identifica os principais componentes estruturais de um sistema e os relacionamentos entre 
eles. O resultado do processo de projeto de arquitetura é um modelo de arquitetura que descreve como o sistema está 
organizado em um conjunto de componentes de comunicação.
Em processos ágeis, geralmente se aceita que um estágio inicial do processo de desenvolvimento se preocupe com o 
estabelecimento de uma arquitetura global do sistema. O desenvolvimento incremental de arquiteturas geralmente não 
é bem-sucedido. Embora a refatoração de compontentes em resposta às mudanças costume ser relativamente fácil, a 
refatoração de uma arquitetura é geralmente cara. 
Para ajudar na compreensão do que quero dizer com arquitetura de sistema, considere a Figura 6.1. Ela mostra um mo-
delo abstrato da arquitetura de um sistema de controle robotizado de empacotamento, que mostra os componentes que 
precisam ser desenvolvidos. Esse sistema robotizado pode embalar diferentes tipos de objeto. Ele usa um componente de 
visão para selecionar objetos em uma esteira, identificar o tipo de objeto e selecionar o tipo correto de empacotamento. 
Em seguida, o sistema retira os objetos da esteira de entrega para serem empacotados. Então, o sistema coloca os objetos 
empacotados em outra esteira. O modelo de arquitetura mostra esses componentes e os relacionamentos entre eles.
Sommerville_Cap_06.indd 103 31/05/2011 15:07:48
104 Engenharia de software
Na prática, existe uma considerável sobreposição entre os processos de engenharia de requisitos e de projeto de 
arquitetura. Idealmente, uma especificação de sistema não deve incluir todas as informações do projeto. Mas essa não é 
a realidade, exceto para sistemas muito pequenos. A decomposição de arquitetura é normalmente necessária para estru-
turar e organizar a especificação. Portanto, como parte do processo de engenharia de requisitos, você poderá propor uma 
arquitetura abstrata de sistema em que seja possível associar grupos de funções ou recursos do sistema aos componentes 
em larga escala ou subsistemas. Você pode, então, usar essa decomposição para discutir com os stakeholders os requisitos 
e recursos do sistema. 
Você pode projetar as arquiteturas de software em dois níveis de abstração, o que eu chamo de arquiteturas em peque-
na e grande escala:
1. A arquitetura em pequena escala está preocupada com a arquitetura de programas individuais. Nesse nível, esta-
mos preocupados com a maneira como um programa individual é decomposto em componentes. Este capítulo 
está mais preocupado com as arquiteturas de programas.
2. A arquitetura em grande escala preocupa-se com a arquitetura de sistemas corporativos complexos que incluem 
outros sistemas, programas e componentes de programas. Esses sistemas empresariais estão distribuídos por diver-
sos computadores, que podem pertencer e ser geridos por diferentes empresas. Eu trato da arquitetura em grande 
escala nos capítulos 18 e 19, nos quais discuto os sistemas de arquiteturas distribuídas.
A arquitetura de software é importante, pois afeta o desempenho e a robustez, bem como a capacidade de distribuição 
e de manutenibilidade de um sistema (BOSCH, 2000). Como discute Bosch, os componentes individuais implementam 
os requisitos funcionais do sistema. Os requisitos não funcionais dependem da arquitetura do sistema — a forma como 
esses componentes estão organizados e se comunicam. Em muitos sistemas, os requisitos não funcionais são também 
influenciados por componentes individuais, mas não há dúvida de que a arquitetura de sistema é a influência dominante.
Bass et al. (2003) discutem três vantagens de projetar e documentar, explicitamente, a arquitetura de software:
1. Comunicação de stakeholders. A arquitetura é uma apresentação de alto nível do sistema e pode ser usada como 
um foco de discussão por uma série de diferentes stakeholders.
2. Análise de sistema. Tornar explícita a arquitetura do sistema, em um estágio inicial de seu desenvolvimento, requer 
alguma análise. As decisões de projeto de arquitetura têm um efeito profundo sobre a possibilidade de o sistema 
atender ou não aos requisitos críticos, como desempenho, confiabilidade e manutenibilidade.
3. Reúso em larga escala. Um modelo de uma arquitetura de sistema é uma descrição compacta e gerenciável de 
como um sistema é organizado e como os componentes interoperam. A arquitetura do sistema geralmente é a 
mesma para sistemas com requisitos semelhantes e, por isso, pode apoiar o reúso de software em grande escala. 
 Figura 6.1 A arquitetura de um sistema de controle robotizado de empacotamento
Sistema de visão
Sistema 
de identificação 
de objetos
Controlador 
de braço
Controle 
de garra
Sistema 
de seleção de 
empacotamento
Sistema de 
empacotamento
Controlador 
de esteira
Sommerville_Cap_06.indd 104 31/05/2011 15:07:49
105Capítulo 6 Projeto de arquitetura
Como explico no Capítulo 16, talvez seja possível desenvolver arquiteturas de linha de produto nas quais a mesma 
arquitetura é reusada em todo um conjunto de sistemas relacionados.
Hofmeister et al. (2000) propõem uma arquitetura de software que pode servir, em primeiro lugar, como um plano de 
projeto para a negociação de requisitos de sistema, e, em segundo lugar, como um meio de estruturar as discussões com 
os clientes, desenvolvedores e gerentes. Eles também sugerem que seja uma ferramenta essencial para o gerenciamento 
da complexidade, pois esconde detalhes e permite que os projetistas se centrem nas abstrações-chave do sistema.
Em geral, as arquiteturas de sistema são modeladas por meio de diagramas de blocos simples, como na Figura 6.1. No 
diagrama, cada caixa representa um componente. Caixas dentro de caixas indicam que o componente foi decomposto 
em subcomponentes. As setas significam que os dados e/ou sinais de controle são passados de um componente a outro 
na direção das setas. Você pode ver muitos exemplos desse tipo de modelo de arquitetura no catálogo de arquitetura de 
software de Booch (BOOCH, 2009).
Os diagramas de blocos apresentam uma imagem de alto nível da estrutura do sistema, de forma que as pessoas 
de diferentes disciplinas, envolvidas no processo de desenvolvimento do sistema, possam compreender facilmente. No 
entanto, apesar de seu amplo uso, Bass et al. (2003) não gostam de diagramas de blocos informais para descrever uma 
arquitetura. Eles alegam que esses diagramas informais são pobres representações de arquitetura, que não mostram o tipo 
de relacionamentos entre os componentes do sistema nem as propriedades dos componentes visíveis externamente.
A aparente contradição entre a prática e a teoria de arquitetura surge porqueSQL.
6.9 Usando o modelo básico de um sistema de informação conforme apresentado na Figura 6.11, sugira os 
componentes que podem fazer parte de um sistema de informação que permite aos usuários visualizarem 
informações sobre os voos que chegam e partem de um aeroporto particular. 
6.10 Deveria haver uma profissão específica, de ‘arquiteto de software’, cujo papel seria trabalhar com o cliente, 
de forma independente, para projetar a arquitetura do sistema de software? Uma empresa de software in-
dependente implementaria o sistema. Quais poderiam ser as dificuldades de se estabelecer essa profissão?
REFERÊNCIAS 
BASS, L.; CLEMENTS, P.; KAZMAN, R. Software Architecture in Practice. 2. ed. Boston: Addison-Wesley, 2003.
BERCZUK, S. P.; APPLETON, B. Software Configuration Management Patterns: Effective Teamwork, Practical Integration. 
Boston: Addison-Wesley, 2002.
BOOCH, G. Handbook of software architecture. Publicação Web. Disponível em: . 2009.
Sommerville_Cap_06.indd 122 31/05/2011 15:07:59
123Capítulo 6 Projeto de arquitetura
BOSCH, J. Design and Use of Software Architectures. Harlow, Reino Unido: Addison-Wesley, 2000.
BUSCHMANN, F.; HENNEY, K.; SCHMIDT, D. C. Pattern-oriented Software Architecture. v. 4. A Pattern Language for 
Distributed Computing. Nova York: John Wiley & Sons, 2007a.
______. Pattern-oriented Software Architecture. v. 5. On Patterns and Pattern Languages. Nova York: John Wiley & 
Sons, 2007b.
BUSCHMANN, F.; MEUNIER, R.; ROHNERT, H.; SOMMERLAD, P. Pattern-oriented Software Architecture. v. 1. A System 
of Patterns. Nova York: John Wiley & Sons, 1996.
CLEMENTS, P.; BACHMANN, F.; BASS, L.; GARLAN, D.; IVERS, J.; LITTLE, R. et al. Documenting Software Architectures: 
Views and Beyond. Boston: Addison-Wesley, 2002.
COPLIEN, J. H.; HARRISON, N. B. Organizational Patterns of Agile Software Development. Englewood Cliffs, NJ: Prentice 
Hall, 2004.
GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Design Patterns: Elements of Reusable Object-Oriented Software. 
Reading, Mass.: Addison-Wesley, 1995.
GARLAN, D.; SHAW, M. An introduction to software architecture. Advances in Software Engineering and Knowledge 
Engineering, v. 1, p. 1-39, 1993.
HAROLD, E. R.; MEANS, W. S. XML in a Nutshell. Sebastopol. Califórnia: O‘Reilly, 2002. 
HOFMEISTER, C.; NORD, R.; Soni, D. Applied Software Architecture. Boston: Addison- Wesley, 2000.
HUNTER, D.; RAFTER, J.; FAWCETT, J.; VAN DER VLIST, E. Beginning XML. 4. ed. Indianapolis, Ind.: Wrox Press, 2007.
KIRCHER, M.; JAIN, P. Pattern-Oriented Software Architecture. v. 3. Patterns for Resource Management. Nova York: 
John Wiley & Sons, 2004.
KRUCHTEN, P. The 4 + 1 view model of software architecture. IEEE Software, v. 12, n. 6, p. 42-50, 1995. 
LANGE, C. F. J.; CHAUDRON, M. R. V.; MUSKENS, J. UML software description and architecture description. IEEE 
Software, v. 23, n. 2, p. 40-46, 2006.
LEWIS, P. M.; BERNSTEIN, A. J.; KIFER, M. Databases and Transaction Processing: An Application-oriented Approach. 
Boston: Addison-Wesley, 2003.
MARTIN, D.; SOMMERVILLE, I. Patterns of interaction: Linking ethnomethodology and design. ACM Trans. on 
Computer-Human Interaction, v. 11, n. 1, p. 59-89, 2004.
NII, H. P. Blackboard systems, parts 1 and 2. AI Magazine, v. 7, n. 3, 4, p. 38-53, 62-69, 1986.
SCHMIDT, D.; STAL, M.; ROHNERT, H.; BUSCHMANN, F. Pattern-Oriented Software Architecture. v. 2. Patterns for 
Concurrent and Networked Objects. Nova York: John Wiley & Sons, 2000.
SHAW, M.; GARLAN, D. Software Architecture: Perspectives on an Emerging Discipline. Englewood Cliffs, NJ: Prentice 
Hall, 1996.
USABILITY GROUP. Usability patterns. Publicação Web. Disponível em: . 1998.
Sommerville_Cap_06.indd 123 31/05/2011 15:08:00
	Sommerville_Cap_06existem duas maneiras de usar um mo-
delo de arquitetura de um programa:
1. Para facilitar a discussão sobre o projeto do sistema. Uma visão de arquitetura de um sistema de alto nível é útil para 
a comunicação com os stakeholders do sistema e para o planejamento do projeto, pois não é rica em detalhes. Os 
stakeholders podem relacionar e entender uma visão abstrata do sistema e, então, discutir o sistema como um todo, 
sem se confundirem com detalhes. O modelo de arquitetura identifica os principais componentes que devem 
ser desenvolvidos para que os gerentes possam começar a designar pessoas para planejarem o desenvolvimento 
desses sistemas.
2. Como forma de documentar uma arquitetura que foi projetada. O objetivo é produzir um modelo completo de sis-
tema que mostre seus diferentes componentes, suas interfaces e conexões. O argumento para isso é que essa 
descrição detalhada da arquitetura facilita a compreensão e o desenvolvimento do sistema.
Diagramas de bloco são uma forma adequada de, durante o processo de projeto, descrever a arquitetura do sistema; 
também são uma boa maneira de apoiar a comunicação entre as pessoas envolvidas no processo. Em muitos projetos, eles 
são a única documentação de arquitetura que existe. No entanto, se a arquitetura de um sistema deve ser bem documen-
tada, é melhor usar uma notação com semântica bem definida para a descrição de arquitetura. Contudo, como discuto na 
Seção 6.2, algumas pessoas pensam que a documentação detalhada não é útil e não vale o custo de seu desenvolvimento.
6.1 Decisões de projeto de arquitetura
O projeto de arquitetura é um processo criativo no qual você projeta uma organização de sistema para satisfa-
zer aos requisitos funcionais e não funcionais de um sistema. Por ser um processo criativo, as atividades no âmbito 
do processo dependem do tipo de sistema a ser desenvolvido, a formação e experiência do arquiteto de sistema 
e os requisitos específicos para o sistema. Por isso, é útil pensar em projeto de arquitetura como uma série de de-
cisões, em vez de uma sequência de atividades. 
Durante o processo de projeto de arquitetura, os arquitetos de sistema precisam tomar uma série de decisões 
estruturais que afetam profundamente o sistema e seu processo de desenvolvimento. Com base em seus conheci-
mentos e experiência, eles precisam considerar as seguintes questões fundamentais sobre o sistema:
1. Existe uma arquitetura genérica de aplicação que pode atuar como um modelo para o sistema que está sendo 
projetado?
2. Como o sistema será distribuído por meio de um número de núcleos ou processadores?
3. Que padrões ou estilos de arquitetura podem ser usados?
4. Qual será a abordagem fundamental para se estruturar o sistema?
5. Como os componentes estruturais do sistema serão decompostos em subcomponentes?
6. Que estratégia será usada para controlar o funcionamento dos componentes do sistema?
Sommerville_Cap_06.indd 105 31/05/2011 15:07:49
106 Engenharia de software
7. Qual a melhor organização de arquitetura para satisfazer os requisitos não funcionais do sistema?
8. Como o projeto de arquitetura será avaliado?
9. Como a arquitetura do sistema deve ser documentada? 
Embora cada sistema de software seja único, sistemas no mesmo domínio de aplicação frequentemente têm 
arquiteturas similares, que refletem os conceitos fundamentais desse domínio. Por exemplo, linhas de produto de 
aplicação são as aplicações construídas em torno de uma arquitetura central com variantes que satisfazem aos 
requisitos específicos do cliente. Ao projetar uma arquitetura de sistema, você precisa decidir o que seu sistema e 
as classes de uma aplicação mais gerais têm em comum, e quanto conhecimento dessas arquiteturas de aplicação 
você pode reusar. Discuto arquiteturas genéricas de aplicação na Seção 6.4, e linhas de produtos de aplicação no 
Capítulo 16. 
Para sistemas embutidos e sistemas projetados para computadores pessoais, geralmente existe apenas um 
processador, e você não terá de projetar uma arquitetura distribuída para o sistema. No entanto, a maioria dos 
sistemas de grande porte são atualmente sistemas distribuídos em que o software é distribuído em vários compu-
tadores diferentes. A escolha da arquitetura de distribuição é uma decisão importante que afeta o desempenho e a 
confiabilidade do sistema. Esse é um tema importante em si mesmo e no Capítulo 18 eu o discuto separadamente.
A arquitetura de um sistema de software pode se basear em um determinado padrão ou estilo de arquitetura. 
Um padrão de arquitetura é uma descrição de uma organização do sistema (GARLAN e SHAW, 1993), como uma 
organização cliente-servidor ou uma arquitetura em camadas. Os padrões de arquitetura capturam a essência de 
uma arquitetura que tem sido usada em diferentes sistemas de software. Ao tomar decisões sobre a arquitetura de 
um sistema, você deve conhecer os padrões comuns, bem como saber onde eles podem ser usados e quais são 
seus pontos fortes e fracos. Na Seção 6.3, discutiremos uma série de padrões frequentemente usados.
A ideia de Garlan e Shaw, de um estilo de arquitetura (estilo e padrão passaram a significar a mesma coisa), 
abrange as questões 4 a 6 da lista anteriormente apresentada. Você precisa escolher a estrutura mais adequada, 
como cliente-servidor ou em camadas, que permitirá o cumprimento dos requisitos do sistema. Para decompor 
unidades estruturais do sistema, você precisa decidir sobre a estratégia para a decomposição de componentes 
em subcomponentes. As abordagens que você pode usar permitem a implementação de diferentes tipos de 
arquitetura. Finalmente, no processo de modelagem de controle, você toma decisões sobre como a execução de 
componentes é controlada. Você desenvolve um modelo geral dos relacionamentos de controle entre as diversas 
partes do sistema.
Devido à estreita relação entre os requisitos não funcionais e a arquitetura do software, o estilo e a estrutura 
da arquitetura particular que você escolhe para um sistema devem depender dos requisitos não funcionais do 
sistema:
1. Desempenho. Se o desempenho for um requisito crítico, a arquitetura deve ser projetada para localizar as ope-
rações críticas dentro de um pequeno número de componentes, com todos esses componentes implantados 
no mesmo computador, em vez de distribuídos pela rede. Isso pode significar o uso de alguns componentes 
relativamente grandes, em vez de pequenos de baixa granularidade, que reduzem o número de comunicações 
entre eles. Você também pode considerar a organização do sistema de run-time, que permite que o sistema 
seja replicado e executado em diferentes processadores.
2. Proteção. Se a proteção for um requisito crítico, deve ser usada uma estrutura em camadas para a arquitetura, 
com os ativos mais críticos protegidos nas camadas mais internas, com alto nível de validação de proteção 
aplicado a essas camadas.
3. Segurança. Se a segurança for um requisito crítico, a arquitetura deve ser concebida de modo que as operações 
relacionadas com a segurança estejam localizadas em um único componente ou em um pequeno número de 
componentes. Isso reduz os custos e os problemas de validação de segurança e torna possível fornecer siste-
mas de proteção relacionados que podem desligar o sistema de maneira segura em caso de falha.
4. Disponibilidade. Se a disponibilidade for um requisito crítico, a arquitetura deve ser projetada para incluir compo-
nentes redundantes, de modo que seja possível substituir e atualizar componentes sem parar o sistema. No Ca-
pítulo 13 eu descrevo a arquitetura de dois sistemas que toleram defeitos, para sistemas de alta disponibilidade.
5. Manutenção. Se a manutenção for um requisito crítico, a arquitetura do sistema deve ser projetada a partir 
de compontentes autocontidos de baixa granularidade que podem ser rapidamente alterados. Os produto-
res de dados devem ser separados dos consumidores, e as estruturas de dados compartilhados devem ser 
evitadas. 
Sommerville_Cap_06.indd 106 31/05/201115:07:49
107Capítulo 6 Projeto de arquitetura
Obviamente, há um conflito potencial entre algumas dessas arquiteturas. Por exemplo, o uso de componentes 
de grande porte melhora o desempenho, e o uso de componentes pequenos, de baixa granularidade, além de 
melhorar a manutenibilidade. Se o desempenho e a manutenibilidade forem requisitos importantes do sistema, 
então alguns compromissos devem ser encontrados. Em alguns casos, isso pode ser conseguido por meio de 
diferentes padrões ou estilos de arquitetura para diferentes partes do sistema.
Avaliar um projeto de arquitetura é difícil, pois o verdadeiro teste de uma arquitetura é quão bem o sistema 
satisfaz aos requisitos funcionais e não funcionais quando em uso. No entanto, você pode fazer alguma avaliação, 
comparando seu projeto contra arquiteturas de referência ou padrões genéricos de arquitetura. A descrição de 
Bosch (2000) das características não funcionais dos padrões de arquitetura também pode ajudar na avaliação de 
arquiteturas.
6.2 Visões da arquitetura
Na introdução deste capítulo, expliquei que os modelos de arquitetura de um sistema de software podem ser 
usados para focar a discussão sobre os requisitos de software ou de projeto. Como alternativa, podem ser usados 
para documentar um projeto para que este possa ser usado como base para um projeto e uma implementação 
mais detalhados e para a futura evolução do sistema. Nesta seção, discuto duas questões relevantes para essas 
duas opções:
1. Que visões ou perspectivas são úteis ao se projetar e documentar uma arquitetura de sistema?
2. Quais notações devem ser usadas para se descrever modelos de arquitetura?
É impossível representar todas as informações relevantes sobre a arquitetura de um sistema em um único mo-
delo de arquitetura, pois cada modelo mostra apenas uma visão ou perspectiva do sistema. Pode mostrar como 
um sistema é decomposto em módulos, como os processos de run-time interagem, ou as diferentes formas como 
são distribuídos os componentes do sistema através de uma rede. Tudo isso é útil em momentos diferentes; por-
tanto, para ambos, projeto e documentação, geralmente você precisa apresentar múltiplas visões da arquitetura 
de software.
Existem opiniões diferentes sobre para que as visões são necessárias. Kruchten (1995), em seu bem conhecido 
modelo de visão 4 + 1 de arquitetura de software, sugere que deve haver quatro visões fundamentais de arquite-
tura, relacionadas usando-se casos de uso ou cenários. As visões que ele sugere são:
1. A visão lógica, que mostra as abstrações fundamentais do sistema como objetos ou classes de objetos. Nessa 
visão, deveria ser possível relacionar os requisitos de sistema com as entidades.
2. A visão de processo, que mostra como, no tempo de execução, o sistema é composto de processos interativos. 
Essa visão é útil para fazer julgamentos sobre as características não funcionais do sistema, como desempenho 
e disponibilidade.
3. A visão de desenvolvimento, que mostra como o software é decomposto para o desenvolvimento, ou seja, 
apresenta a distribuição do software em componentes que são implementados por um único desenvolvedor 
ou por uma equipe de desenvolvimento. Essa visão é útil para gerentes de software e programadores.
4. Uma visão física, que mostra o hardware do sistema e como os componentes de software são distribuídos en-
tre os processadores. Essa visão é útil para os engenheiros de sistemas que estão planejando uma implantação 
do sistema.
Hofmeister et al. (2000) sugerem o uso de visões semelhantes, mas acrescentam a noção de uma visão conceitual. 
Essa é uma visão abstrata do sistema que pode ser a base para a decomposição de requisitos de alto nível em especi-
ficações mais detalhadas, ajuda os engenheiros a tomarem decisões sobre os componentes que podem ser reusados 
e representa uma linha de produtos (assunto discutido no Capítulo 16) ao invés de um único sistema. A Figura 6.1, que 
descreve a arquitetura de um robô de empacotamento, é um exemplo de uma visão conceitual do sistema.
Na prática, as visões conceituais são, quase sempre, desenvolvidas durante o processo de projeto e são usadas 
para apoiar a tomada de decisões de arquitetura. Elas são uma maneira de comunicar a essência de um sistema 
para os diferentes stakeholders. Durante o processo de projeto, quando diferentes aspectos do sistema são discu-
tidos, outras visões também podem ser desenvolvidas, mas não há necessidade de uma descrição completa de 
todas as perspectivas. Também pode ser possível associar os padrões de arquitetura, discutidos na próxima seção, 
com as diferentes visões de um sistema.
Sommerville_Cap_06.indd 107 31/05/2011 15:07:50
108 Engenharia de software
Existem opiniões divergentes a respeito do uso da UML para descrições de arquitetura pelos arquitetos de 
software (CLEMENTS et al., 2002). Uma pesquisa de 2006 (LANGE et al., 2006) mostrou que, quando a UML foi usa-
da, na maioria das vezes foi aplicada de forma solta e informal. Os autores desse trabalho argumentam que esse 
é um procedimento negativo. Eu não concordo com essa opinião. A UML foi projetada para descrever sistemas 
orientados a objetos e, no estágio do projeto de arquitetura, muitas vezes você quer descrever os sistemas em 
um nível maior de abstração. Classes de objetos estão muito próximas da implementação para serem úteis na 
descrição de arquitetura.
Eu não acho a UML útil durante o processo de projeto; prefiro as notações informais, mais rápidas de se escrever 
e que podem ser facilmente desenhadas em um quadro branco. A UML tem mais valor quando você está docu-
mentando uma arquitetura em detalhes ou usando o desenvolvimento dirigido a modelos, conforme discutido 
no Capítulo 5.
Vários pesquisadores têm proposto o uso de linguagens de descrição de arquitetura (ADLs, do inglês Archi-
tectural Description Languages) mais especializadas (BASS et al., 2003) para descrever as arquiteturas de sistema. 
Os elementos básicos de ADLs são componentes e conectores, que incluem regras e diretrizes para arquiteturas 
bem formadas. No entanto, devido a sua natureza especializada, especialistas de domínio e aplicação consideram 
as ADLs difíceis de entender e usar, o que torna difícil avaliar sua utilidade para engenharia de software prática. As 
ADLs projetadas para um determinado domínio (por exemplo, sistemas de automóveis) podem ser usadas como 
base para o desenvolvimento dirigido a modelos. No entanto, acredito que os modelos e as notações informais, 
como a UML, continuarão a ser a forma mais comumente usada para documentar arquiteturas de sistema.
Os usuários de métodos ágeis alegam que, na maior parte do tempo, a documentação detalhada de projeto 
não é usada. E, portanto, desenvolvê-la seria um desperdício de tempo e dinheiro. Pessoalmente, eu concordo 
com essa opinião e penso que, na maioria dos sistemas, não vale a pena desenvolver uma descrição de arqui-
tetura detalhada a partir dessas quatro visões. Você deve desenvolver visões úteis para a comunicação, e não se 
preocupar se sua documentação de arquitetura está completa ou não. No entanto, a exceção é quando você está 
desenvolvendo sistemas críticos, quando você precisa fazer uma análise detalhada da confiança do sistema. Pode 
ser necessário convencer os reguladores externos de que o sistema está de acordo com suas regras, e, então, a 
documentação completa da arquitetura pode ser necessária.
6.3 Padrões de arquitetura
A ideia de padrões como uma forma de apresentar, compartilhar e reusar o conhecimento sobre sistemas de 
software é hoje amplamente usada. O gatilho para isso foi a publicação de um livro sobre os padrões de projeto 
orientado a objetos (GAMMA et al., 1995), o que levou ao desenvolvimento de outros tipos de padrões, como 
padrões para o projeto organizacional (COPLIEN e HARRISON, 2004), padrões de usabilidade (USABILITY GROUP, 
1998), interação (MARTIN e SOMMERVILLE, 2004), gerenciamento de configuração (BERCZUK e APPLETON, 2002), e 
assim por diante.Os padrões de arquitetura foram propostos na década de 1990 sob o nome de ‘estilos de arquite-
tura’ (SHAW e GARLAN, 1996), com uma série de cinco volumes de manuais sobre a arquitetura de software orien-
tada a padrões, publicados entre 1996 e 2007 (BUSCHMANN et al., 1996; BUSCHMANN et al., 2007a; BUSCHMANN 
et al., 2007b; KIRCHERE e JAIN, 2004; SCHMIDT et al., 2000).
Nesta seção, apresento os padrões de arquitetura e descrevo brevemente alguns padrões comumente usados 
em diferentes tipos de sistemas. Para obter mais informações a respeito dos padrões e seu uso, você deve consultar 
manuais de padrões publicados.
Você pode pensar em um padrão de arquitetura como uma descrição abstrata, estilizada, de boas práticas 
experimentadas e testadas em diferentes sistemas e ambientes. Assim, um padrão de arquitetura deve descrever 
uma organização de sistema bem-sucedida em sistemas anteriores. Deve incluir informações de quando o uso 
desse padrão é adequado, e seus pontos fortes e fracos. 
Por exemplo, a Tabela 6.1 descreve o conhecido padrão MVC (modelo-visão-controlador, do inglês Model-View-
-Controller). Esse padrão é a base do gerenciamento de interação em muitos sistemas baseados em Web. A descrição 
estilizada de padrão inclui o nome do padrão, uma breve descrição (com um modelo gráfico associado), e um exem-
plo do tipo de sistema em que o padrão é usado (novamente, talvez com um modelo gráfico). Você também deve 
incluir informações sobre quando o padrão deve ser usado e suas vantagens e desvantagens. Modelos gráficos da 
arquitetura associados com o padrão MVC são mostrados nas figuras 6.2 e 6.3. Estes modelos apresentam a arquite-
Sommerville_Cap_06.indd 108 31/05/2011 15:07:50
109Capítulo 6 Projeto de arquitetura
tura a partir de diferentes visões — a Figura 6.2 é uma visão conceitual, e a Figura 6.3 mostra uma possível arquitetura 
run-time, quando esse padrão é usado para gerenciamento de interações em um sistema baseado em Web.
Em uma pequena seção de um capítulo geral, é impossível descrever todos os padrões genéricos que podem 
ser usados no desenvolvimento de software. Em vez disso, apresento alguns exemplos de padrões amplamente 
usados e que capturam os bons princípios de projeto de arquitetura. No site do livro, há mais exemplos de padrões 
genéricos de arquitetura.
 6.3.1 Arquitetura em camadas
As noções de separação e independência são fundamentais para o projeto de arquitetura, porque permitem 
que alterações sejam localizadas. O padrão MVC, apresentado na Tabela 6.1, separa os elementos de um sistema, 
permitindo mudá-los de forma independente. Por exemplo, pode-se adicionar uma nova visão ou alterar uma exi-
bição existente sem quaisquer alterações nos dados subjacentes do modelo. O padrão de arquitetura em camadas 
é outra maneira de conseguir a separação e independência. Esse padrão está na Tabela 6.2. Aqui, a funcionalidade 
do sistema é organizada em camadas separadas, e cada camada só depende dos recursos e serviços oferecidos 
pela camada imediatamente abaixo dela.
 Figura 6.2 A organização do MVC
Controlador
Visão
Modelo
Seleção 
de visão
Mudança 
de estado
Notificação 
de mudança
Consulta 
de estado
Eventos 
de usuário
Mapeia ações de usuário 
para atualizar modelo
Seleciona visões
Modelos renders
Solicita atualização 
de modelo
Envia eventos de usuário 
para controlador
Encapsula estado 
de aplicação 
Notifica visão 
de mudanças de estado
 Tabela 6.1 O padrão modelo-visão-controlador (MVC)
Nome MVC (Modelo-Visão-Controlador)
Descrição Separa a apresentação e a interação dos dados do sistema. O sistema é estruturado em três componentes lógicos que 
interagem entre si. O componente Modelo gerencia o sistema de dados e as operações associadas a esses dados. O 
componente Visão define e gerencia como os dados são apresentados ao usuário. O componente Controlador gerencia 
a interação do usuário (por exemplo, teclas, cliques do mouse etc.) e passa essas interações para a Visão e o Modelo. Veja 
a Figura 6.2.
Exemplo A Figura 6.3 mostra a arquitetura de um sistema aplicativo baseado na Internet, organizado pelo uso do padrão MVC.
Quando é usado É usado quando existem várias maneiras de se visualizar e interagir com dados. Também quando são desconhecidos os 
futuros requisitos de interação e apresentação de dados.
Vantagens Permite que os dados sejam alterados de forma independente de sua representação, e vice-versa. Apoia a apresentação 
dos mesmos dados de maneiras diferentes, com as alterações feitas em uma representação aparecendo em todas elas.
Desvantagens Quando o modelo de dados e as interações são simples, pode envolver código adicional e complexidade de código. 
Sommerville_Cap_06.indd 109 31/05/2011 15:07:50
110 Engenharia de software
Essa abordagem em camadas apoia o desenvolvimento incremental de sistemas. Quando uma camada é de-
senvolvida, alguns dos serviços prestados por ela podem ser disponibilizados para os usuários. A arquitetura tam-
bém é mutável e portável. Enquanto sua interface for inalterada, uma camada pode ser substituída por outra equi-
valente. Além disso, quando a camada de interfaces muda ou tem novos recursos adicionados, apenas a camada 
adjacente é afetada. Como sistemas em camadas localizam dependências das máquinas em camadas internas, isso 
facilita o fornecimento de implementações de multiplataformas de um sistema de aplicação. Apenas as camadas 
internas dependentes da máquina precisam ser reimplementadas para levar em conta os recursos de um sistema 
operacional diferente ou banco de dados.
A Figura 6.4 é um exemplo de uma arquitetura em camadas, com quatro camadas. A camada mais baixa inclui 
software de apoio ao sistema — geralmente, apoio de banco de dados e de sistema operacional. A próxima ca-
mada é a camada de aplicação, que inclui os componentes relacionados com a funcionalidade da aplicação e os 
 Figura 6.3 Arquitetura de aplicações Web usando o padrão MVC
Browser
Controlador
Formulário 
para mostrar
Solicitação 
de atualização
Notificação 
de mudança Solicitação 
de refrescamento
Eventos 
do usuário
Processamento de 
solicitação HTTP
Lógica específica 
de aplicação
Validação de dados
Página dinâmica 
Geração
Gerenciamento 
de formulários
Lógica de negócios
Banco de dados
Visão
Modelo
 Tabela 6.2 O padrão de arquitetura em camadas
Nome Arquitetura em camadas
Descrição Organiza o sistema em camadas com a funcionalidade relacionada associada a cada camada. Uma camada 
fornece serviços à camada acima dela; assim, os níveis mais baixos de camadas representam os principais 
serviços suscetíveis de serem usados em todo o sistema. Veja a Figura 6.4.
Exemplo Um modelo em camadas de um sistema para compartilhar documentos com direitos autorais, em 
bibliotecas diferentes, como mostrado na Figura 6.5.
Quando é usado É usado na construção de novos recursos em cima de sistemas existentes; quando o desenvolvimento está 
espalhado por várias equipes, com a responsabilidade de cada equipe em uma camada de funcionalidade; 
quando há um requisito de proteção multinível.
Vantagens Desde que a interface seja mantida, permite a substituição de camadas inteiras. Recursos redundantes (por 
exemplo, autenticação) podem ser fornecidos em cada camada para aumentar a confiança do sistema.
Desvantagens Na prática, costuma ser difícil proporcionar uma clara separação entre as camadas, e uma camada de 
alto nível pode ter de interagir diretamente com camadas de baixo nível, em vez de através da camada 
imediatamente abaixo dela. O desempenho pode ser um problema por causa dos múltiplos níveis de 
interpretação de uma solicitação de serviço, uma vez que são processados em cada camada.
Sommerville_Cap_06.indd 110 31/05/2011 15:07:51
111Capítulo 6 Projeto de arquitetura
componentes utilitários que são usados por outros componentes da aplicação. A terceira camada está preocupada 
com o gerenciamento de interface de usuário e fornecimento de autenticação e autorização de usuário, coma 
camada superior fornecendo recursos de interface com o usuário. Certamente, o número de camadas é arbitrário. 
Qualquer camada na Figura 6.4 pode ser dividida em mais camadas.
A Figura 6.5 é um exemplo de como esse padrão de arquitetura em camadas pode ser aplicado a um sistema 
de biblioteca chamado LIBSYS, que permite controlar o acesso eletrônico de um grupo de bibliotecas universitárias 
aos materiais com direitos autorais. Esse sistema tem arquitetura de cinco camadas, na qual a camada inferior são 
os bancos de dados individuais de cada biblioteca. 
Você pode ver um exemplo do padrão de arquitetura em camadas na Figura 6.12 (Seção 6.4). Ela mostra a or-
ganização do sistema de saúde mental (MHC-PMS) que discuti nos capítulos anteriores.
 6.3.2 Arquitetura de repositório
A arquitetura em camadas e padrões MVC são exemplos de padrões nos quais a visão apresentada é a organi-
zação conceitual de um sistema. Meu próximo exemplo — o padrão Repositório (Tabela 6.3) — descreve como 
um conjunto de componentes que interagem podem compartilhar dados.
 Figura 6.4 Uma arquitetura genérica em camadas 
Interface de usuário
Lógica de negócio principal/funcionalidade de aplicação 
Recursos de sistema
Apoio de sistema (SO, banco de dados etc.)
Gerenciamento de interface de usuário 
Autenticação e autorização
 Figura 6.5 A arquitetura do sistema LIBSYS
Interface de browser
Índice da biblioteca
Busca 
distribuída
Recuperação 
de documentos
Gerente 
de direitos Contabilidade
BD1 BD2 BD3 BD4 BDn
Login 
LIBSYS 
Formulários e 
gerente de consulta
Gerente 
de impressão
Sommerville_Cap_06.indd 111 31/05/2011 15:07:52
112 Engenharia de software
A maioria dos sistemas que usam grandes quantidades de dados é organizada em torno de um banco de dados 
ou repositório compartilhado. Esse modelo é, portanto, adequado para aplicações nas quais os dados são gerados 
por um componente e usados por outro. Exemplos desse tipo de sistema incluem sistemas de comando e controle, 
sistemas de informações gerenciais, sistemas de CAD e ambientes interativos de desenvolvimento de software.
A Figura 6.6 é uma ilustração de uma situação na qual um repositório pode ser usado. Esse diagrama mostra 
um IDE que inclui diversas ferramentas para apoiarem o desenvolvimento dirigido a modelos. O repositório, nesse 
caso, pode ser um ambiente controlado de versões (veja o Capítulo 25) que mantém o controle das alterações de 
software e permite a reversão para versões anteriores.
A organização de ferramentas em torno de um repositório constitui uma maneira eficiente de compartilhar 
grandes quantidades de dados. Não há necessidade de transmitir dados explicitamente de um componente para 
outro. No entanto, os componentes devem operar em torno de um modelo aprovado de repositório de dados. 
Inevitavelmente, esse é um compromisso entre as necessidades específicas de cada ferramenta, e pode ser difícil 
ou impossível integrar novos componentes se seus modelos de dados não se adequam ao esquema acordado. 
Na prática, pode ser difícil distribuir o repositório por meio de uma série de máquinas. Embora seja possível a dis-
tribuição de um repositório logicamente centralizado, pode haver problemas com a redundância e inconsistência 
de dados.
No exemplo mostrado na Figura 6.6, o repositório é passivo e o controle é de responsabilidade dos componen-
tes que usam o repositório. Uma abordagem alternativa, derivada de sistemas de inteligência artificial, usa um mo-
 Tabela 6.3 O padrão repositório
Nome Repositório
Descrição Todos os dados em um sistema são gerenciados em um repositório central, acessível a todos os 
componentes do sistema. Os componentes não interagem diretamente, apenas por meio do repositório.
Exemplo A Figura 6.6 é um exemplo de um IDE em que os componentes usam um repositório de informações sobre 
projetos de sistema. Cada ferramenta de software gera informações que ficam disponíveis para uso por 
outras ferramentas.
Quando é usado Você deve usar esse padrão quando tem um sistema no qual grandes volumes de informações são gerados 
e precisam ser armazenados por um longo tempo. Você também pode usá-lo em sistemas dirigidos a 
dados, nos quais a inclusão dos dados no repositório dispara uma ação ou ferramenta.
Vantagens Os componentes podem ser independentes — eles não precisam saber da existência de outros 
componentes. As alterações feitas a um componente podem propagar-se para todos os outros. Todos os 
dados podem ser gerenciados de forma consistente (por exemplo, backups feitos ao mesmo tempo), pois 
tudo está em um só lugar.
Desvantagens O repositório é um ponto único de falha, assim, problemas no repositório podem afetar todo o sistema. 
Pode haver ineficiências na organização de toda a comunicação através do repositório. Distribuir o 
repositório através de vários computadores pode ser difícil.
 Figura 6.6 Uma arquitetura de repositório para um IDE
Repositório 
do projeto
Tradutor 
de projeto 
Editores 
UML
Geradores 
de código
Analisador 
de projeto
Gerador 
de relatório
Editores 
Java
Editor 
Python
 
Sommerville_Cap_06.indd 112 31/05/2011 15:07:52
113Capítulo 6 Projeto de arquitetura
delo ‘quadro-negro’ que aciona os componentes do modelo quando dados específicos se tornam disponíveis. Isso é 
apropriado quando a forma de repositório de dados não é tão bem estruturada. As decisões sobre qual ferramenta 
ativar só podem ser feitas quando os dados são analisados. Esse modelo foi introduzido por Nii (1986). Bosch (2000) 
incluiu uma boa discussão sobre como esse estilo se relaciona com atributos de qualidade do sistema.
 6.3.3 Arquitetura cliente-servidor
O padrão repositório está preocupado com a estrutura estática de um sistema e não mostra sua organização 
de tempo de execução. Meu próximo exemplo ilustra uma organização muito usada para sistemas distribuídos, em 
tempo de execução. O padrão cliente-servidor é descrito na Tabela 6.4.
Um sistema que segue o padrão cliente-servidor é organizado como um conjunto de serviços e servidores 
associados e clientes que acessam e usam os serviços. Os principais componentes desse modelo são:
1. Um conjunto de servidores que oferecem serviços a outros componentes. Exemplos de servidores incluem: 
servidores de impressão que oferecem serviços de impressão; servidores de arquivos que oferecem serviços de 
gerenciamento de arquivos; e um servidor de compilação, que oferece serviços de compilação de linguagens 
de programação.
2. Um conjunto de clientes que podem chamar os serviços oferecidos pelos servidores. Em geral, haverá várias 
instâncias de um programa cliente executando simultaneamente em computadores diferentes.
3. Uma rede que permite aos clientes acessar esses serviços. A maioria dos sistemas cliente-servidor é implemen-
tada como sistemas distribuídos, conectados através de protocolos de Internet.
Arquiteturas cliente-servidor são normalmente consideradas arquiteturas de sistemas distribuídos, mas o mo-
delo lógico de serviços independentes rodando em servidores separados pode ser implementado em um único 
computador. Novamente, um benefício importante é a separação e a independência. Serviços e servidores podem 
ser modificados sem afetar outras partes do sistema.
Os clientes podem ter de saber os nomes dos servidores disponíveis e os serviços que eles fornecem. No entan-
to, os servidores não precisam conhecer a identidade dos clientes ou quantos clientes estão acessando seus servi-
ços. Os clientes acessam os serviços fornecidos por um servidor por meio de chamadas de procedimento remoto 
usando um protocolo de solicitação-resposta, tal como o protocolo HTTP usado na Internet. Essencialmente, um 
cliente faz uma solicitação a um servidor e espera até receber uma resposta.
A Figura 6.7 é um exemplo de um sistema baseado no modelo cliente-servidor. Esse é um sistema multiusuário 
baseado na Internet para fornecimento de uma biblioteca de filmes e fotos. Nesse sistema, vários servidores geren-
ciam e apresentamos diferentes tipos de mídia. Os quadros de vídeo precisam ser transmitidos de forma rápida e 
em sincronia, mas em resolução relativamente baixa. Eles podem ser comprimidos em um arquivo, de modo que 
o servidor de vídeo possa lidar com a compressão e descompressão de vídeo em diferentes formatos. As fotos, 
porém, devem permanecer em uma resolução alta; por isso, é conveniente mantê-las em um servidor separado.
 Tabela 6.4 O padrão cliente-servidor
Nome Cliente-servidor
Descrição Em uma arquitetura cliente-servidor, a funcionalidade do sistema está organizada em serviços — cada serviço é 
prestado por um servidor. Os clientes são os usuários desses serviços e acessam os servidores para fazer uso deles.
Exemplo A Figura 6.7 é um exemplo de uma biblioteca de filmes e vídeos/DVDs, organizados como um sistema cliente-servidor.
Quando é usado É usado quando os dados em um banco de dados compartilhado precisam ser acessados a partir de uma série de locais. 
Como os servidores podem ser replicados, também pode ser usado quando a carga em um sistema é variável.
Vantagens A principal vantagem desse modelo é que os servidores podem ser distribuídos através de uma rede. A funcionalidade 
geral (por exemplo, um serviço de impressão) pode estar disponível para todos os clientes e não precisa ser implementada 
por todos os serviços.
Desvantagens Cada serviço é um ponto único de falha suscetível a ataques de negação de serviço ou de falha do servidor. O desempenho, 
bem como o sistema, pode ser imprevisível, pois depende da rede. Pode haver problemas de gerenciamento se os 
servidores forem propriedade de diferentes organizações.
Sommerville_Cap_06.indd 113 31/05/2011 15:07:52
114 Engenharia de software
O catálogo deve ser capaz de lidar com uma variedade de consultas e fornecer links para o sistema de infor-
mação da Internet que incluam dados sobre os filmes e videoclipes, além de um sistema de comércio eletrônico 
que apoie a venda das fotografias, filmes e videoclipes. O programa do cliente é, simplesmente, uma interface de 
usuário integrada, construída usando-se um browser da Internet para acesso a esses serviços.
A principal vantagem do modelo cliente-servidor é que se trata de uma arquitetura distribuída. O uso efetivo 
pode ser feito por sistemas em rede com muitos processadores distribuídos. É fácil adicionar um novo servidor e 
integrá-lo com o resto do sistema ou atualizar os servidores de forma transparente, sem afetar outras partes do 
sistema. No Capítulo 18, discuto as arquiteturas distribuídas, incluindo arquiteturas cliente-servidor e arquiteturas 
de objetos distribuídos.
 6.3.4 Arquitetura de duto e filtro
Meu último exemplo de um padrão de arquitetura é o padrão duto e filtro. Esse é um modelo de organização 
em tempo de execução de um sistema no qual as transformações funcionais processam suas entradas e produzem 
saídas. Os dados fluem de um para o outro e transformam-se enquanto se movem através da sequência. Cada 
etapa do processamento é implementada como uma transformação. Os dados de entrada fluem por meio dessas 
transformações até serem convertidos em saídas. As transformações podem executar sequencialmente ou em 
paralelo. Os dados podem ser processados por cada item de transformação ou em um único lote.
 Figura 6.7 Uma arquitetura cliente-servidor para uma biblioteca de filmes
Servidor 
de catálogos
Catálogo 
de biblioteca
Servidor 
de vídeos
Arquivo 
de filmes
Servidor 
de fotos
Arquivo de fotos
Servidor 
Web
Informações sobre 
vídeos e fotos
Cliente 1 Cliente 2 Cliente 3 Cliente 4
Internet
 Tabela 6.5 O padrão duto e filtro 
Nome Duto e filtro
Descrição O processamento dos dados em um sistema está organizado de modo que cada componente de processamento 
(filtro) seja discreto e realize um tipo de transformação de dados. Os dados fluem (como em um duto) de um 
componente para outro para processamento.
Exemplo A Figura 6.8 é um exemplo de um sistema de duto e filtro usado para o processamento das faturas.
Quando é usado Comumente, é usado em aplicações de processamento de dados (tanto as baseadas em lotes como as baseadas em 
transações) em que as entradas são processadas em etapas separadas para gerarem saídas relacionadas.
Vantagens O reúso da transformação é de fácil compreensão e suporte. Estilo de workflow corresponde à estrutura de muitos 
processos de negócios. Evolução por adição de transformações é simples. Pode ser implementado tanto como um 
sistema sequencial quanto concorrente.
Desvantagens O formato para transferência de dados tem de ser acordado entre as transformações de comunicação. Cada 
transformação deve analisar suas entradas e gerar as saídas para um formato acordado. Isso aumenta o overhead do 
sistema e pode significar a impossibilidade de reúso de transformações funcionais que usam estruturas incompatíveis 
de dados.
Sommerville_Cap_06.indd 114 31/05/2011 15:07:53
115Capítulo 6 Projeto de arquitetura
O nome ‘duto e filtro’ vem do sistema original Unix, em que foi possível vincular os processos usando ‘dutos’. 
Estes passam um fluxo de texto de um processo para outro. Os sistemas que obedecem a esse modelo podem 
ser implementados por meio da combinação de comandos Unix, usando dutos e recursos de controle do shell do 
Unix. O termo ‘filtro’ é usado porque uma transformação ‘filtra’ os dados que ele pode processar a partir de seu fluxo 
de dados de entrada (veja a Tabela 6.5).
Variantes desse padrão têm sido usadas desde que os computadores começaram a ser usados para o processa-
mento automático de dados. Quando as transformações são sequenciais com dados transformados em lotes, esse 
modelo de arquitetura de duto e filtro torna-se um modelo sequencial, uma arquitetura comum para sistemas de 
processamento de dados (por exemplo, um sistema de faturamento). A arquitetura de um sistema embutido pode 
também ser organizada como um duto de processo, com cada processo em execução concorrente. No Capítulo 
20, eu discuto o uso desse padrão em sistemas embutidos. 
Um exemplo desse tipo de arquitetura de sistema, usado em um aplicativo de processamento em lote, é 
mostrado na Figura 6.8. Uma organização emitiu faturas para os clientes. Uma vez por semana, os pagamentos 
realizados são reconciliados com as faturas. Para cada pedido pago, um recibo é emitido. Para as faturas que não 
foram pagas dentro do prazo de pagamento permitido, é emitido um lembrete.
É difícil escrever os sistemas interativos usando o modelo de duto e filtro, por causa da necessidade de pro-
cessamento dos fluxos de dados. Embora entradas e saídas de texto simples possam ser modeladas dessa forma, 
interfaces gráficas de usuário têm formatos E/S mais complexos e uma estratégia de controle baseada em eventos 
como cliques do mouse ou seleções de menus. É difícil traduzir isso de forma compatível com o modelo de duto.
6.4 Arquiteturas de aplicações
Sistemas de aplicação são destinados a atender uma necessidade organizacional ou de negócio. Todas as em-
presas têm muito em comum — elas precisam contratar pessoas, emitir faturas, manter a contabilidade, e assim 
por diante. As empresas que operam no mesmo setor usam aplicações específicas comuns. Portanto, assim como 
funções de negócios em geral, todas as empresas de telefonia precisam de sistemas para conectar chamadas, 
gerenciar sua rede, emitir faturas para os clientes etc. Assim, os sistemas de aplicação usados por essas empresas 
também têm muito em comum.
Essas semelhanças levaram ao desenvolvimento de arquiteturas de software que descrevem a estrutura e or-
ganização dos diferentes tipos de sistemas de software. Arquiteturas de aplicação encapsulam as principais ca-
racterísticas de uma classe de sistemas. Por exemplo, em sistemas de tempo real, pode haver modelos genéricos 
de arquitetura de diferentes tipos de sistemas, como sistemas de coleta de dados ou sistemas de monitoração. 
Embora instâncias desses sistemas difiram em detalhes, a estrutura comum de arquitetura pode ser reusadano 
desenvolvimento de novos sistemas do mesmo tipo.
A arquitetura de aplicação pode ser reimplementada no desenvolvimento de novos sistemas, mas, para siste-
mas de muitas empresas, o reúso de aplicações é possível sem a reimplementação. Vemos isso no crescimento da 
Enterprise Resource Planning (ERP) de empresas como SAP e Oracle, e pacotes de software verticais (COTS) para 
aplicações especializadas em diferentes áreas de negócio. Nesses sistemas, um sistema genérico é configurado e 
adaptado para criar uma aplicação específica de negócio.
 Figura 6.8 Um exemplo da arquitetura duto e filtro
Ler faturas 
emitidas 
Identificar 
pagamentos
Emitir recibos
Encontrar 
pagamentos 
devidos
Recibos
Emitir lembretes 
de pagamento
Lembretes
Faturas Pagamentos
Sommerville_Cap_06.indd 115 31/05/2011 15:07:54
116 Engenharia de software
Por exemplo, um sistema de gerenciamento da cadeia de suprimentos pode ser adaptado para diferentes tipos 
de fornecedores, produtos e disposições contratuais. 
Como um projeto de software, você pode usar modelos de arquiteturas de aplicações de inúmeras maneiras:
1. Como ponto de partida para o processo de projeto de arquitetura. Se você não estiver familiarizado com o tipo de 
aplicação que está desenvolvendo, pode basear seu projeto inicial em uma arquitetura genérica de aplicação. 
Naturalmente, ela precisará ser especializada para o sistema específico a ser desenvolvido, mas é um bom 
ponto de partida para o projeto.
2. Como um checklist de projeto. Se você desenvolveu um projeto de arquitetura para um sistema aplicativo, é 
possível compará-lo com a arquitetura de aplicação genérica. Você pode verificar se seu projeto é compatível 
com a arquitetura genérica.
3. Como forma de organizar o trabalho da equipe de desenvolvimento. As arquiteturas de aplicação identificam ca-
racterísticas estruturais estáveis das arquiteturas do sistema, e, em muitos casos, é possível desenvolvê-las em 
paralelo. Você pode distribuir o trabalho aos membros da equipe para implementação dos diferentes compo-
nentes dentro da arquitetura.
4. Como uma forma de avaliar os componentes para reúso. Se você tem componentes que possam ser reusados, 
você pode compará-los com as estruturas genéricas para ver se existem componentes comparáveis na arqui-
tetura da aplicação.
5. Como um vocabulário para falar sobre os tipos de aplicações. Se você está discutindo uma aplicação específica 
ou tentando comparar as aplicações do mesmo tipo, então pode usar os conceitos identificados na arquitetura 
genérica para falar sobre as aplicações. 
Existem muitos tipos de sistema de aplicação e, em alguns casos, eles podem parecer muito diferentes uns dos 
outros. No entanto, muitas dessas aplicações superficialmente diferentes têm, na verdade, muito em comum, e, 
portanto, podem ser representadas por uma arquitetura abstrata única de aplicação. Ilustro isso aqui, descrevendo 
as seguintes arquiteturas de dois tipos de aplicação:
1. Aplicações de processamento de transações. São aplicações centradas em banco de dados que processam os 
pedidos do usuário para obterem informações e atualizarem as informações em um banco de dados. Consis-
tem no tipo mais comum de sistemas interativos de negócios. Elas são organizadas de tal forma que as ações 
do usuário não podem interferir umas com as outras e a integridade do banco de dados é mantida. Essa classe 
de sistema inclui sistemas bancários interativos, sistemas de comércio eletrônico, sistemas de informação e 
sistemas de reservas.
2. Sistemas de processamento de linguagens. São sistemas nos quais as intenções do usuário são expressas em uma 
linguagem formal (como Java). O sistema de processamento de linguagem processa essa linguagem em um 
formato interno e interpreta essa representação interna. Os mais conhecidos sistemas de processamento de 
linguagens são os compiladores, que traduzem programas em linguagem de alto nível em código de máquina. 
No entanto, os sistemas de processamento de linguagens também são usados para interpretar linguagens de 
comando para bancos de dados e sistemas de informação, bem como linguagens de marcação como XML 
(HAROLD e MEANS, 2002; HUNTER et al., 2007).
Escolhi esses tipos particulares de sistema, pois um grande número de sistemas de negócios baseados em 
Internet são sistemas de processamento de transações, e todo o desenvolvimento de software baseia-se em siste-
mas de processamento de linguagens.
 6.4.1 Sistemas de processamento de transações
Sistemas de processamento de transações (TP, do inglês transaction processing) são projetados para processar 
os pedidos de informação do usuário de um banco de dados ou pedidos para atualizar um banco de dados (LEWIS 
et al., 2003). Tecnicamente, uma transação é uma sequência de operações tratadas como uma única unidade (uma 
unidade atômica). Todas as operações em uma transação devem ser concluídas antes da mudança de banco de 
dados se tornar permanente. Isso garante que a falha de operações dentro da transação não gere inconsistências 
no banco de dados.
Do ponto de vista do usuário, uma transação é uma sequência de ações coerentes que satisfazem uma meta, 
como ‘encontrar os tempos de voo de Londres para Paris’. Se a transação de usuário não necessita de alteração no 
banco de dados, então pode não ser necessário empacotar essa transação como uma transação técnica de banco 
de dados.
Sommerville_Cap_06.indd 116 31/05/2011 15:07:54
117Capítulo 6 Projeto de arquitetura
Um exemplo de uma transação é um pedido de um cliente para retirar dinheiro de uma conta bancária usando um 
caixa eletrônico (ATM — Automated Teller Machine). Trata-se de obter detalhes da conta do cliente, verificando o saldo 
e modificando-o com a retirada de uma quantia, e enviar comandos ao ATM para a entrega do dinheiro. Até que todas 
essas etapas sejam concluídas, a transação é incompleta e o banco de dados de contas do cliente não é alterado.
Sistemas de processamento de transações são normalmente interativos, em que os usuários fazem solicita-
ções assíncronas por serviço. A Figura 6.9 ilustra a estrutura conceitual da arquitetura de aplicações TP. Primeiro, 
um usuário faz uma solicitação ao sistema por meio de um componente de E/S de processamento. O pedido é 
processado por alguma lógica específica de aplicação. Uma transação é criada e passada para um gerenciador de 
transações, que geralmente é embutido no sistema de gerenciamento de banco de dados. Depois que o geren-
ciador de transações garantiu que a transação seja devidamente completada, ele sinaliza para a aplicação que o 
processamento terminou.
Os sistemas de processamento de transações podem ser organizados com uma arquitetura de ‘duto e filtro’ 
com componentes do sistema responsável pelas entradas, processamento e saídas. Por exemplo, considere um 
sistema bancário que permite aos clientes consultar suas contas e sacar dinheiro em caixas eletrônicos. O sistema 
é composto de dois componentes de software que se colaboram, o software de caixa eletrônico e o de processa-
mento de conta no servidor do banco de dados. Os componentes de entrada e saída são implementados como 
software no caixa eletrônico, e o componente de processamento é parte do servidor do banco de dados. A Figura 
6.10 mostra a arquitetura desse sistema, ilustrando as funções dos compontentes de entrada, processo e saída.
 6.4.2 Os sistemas de informação
Todos os sistemas que envolvem a interação com bancos de dados compartilhados podem ser considerados 
sistemas de informação baseados em transações. Um sistema de informação permite acesso controlado a uma 
grande base de informações, como um catálogo de biblioteca, um horário de voo ou os registros de pacientes em 
um hospital. Cada vez mais, sistemas de informação são sistemas baseados na Internet, acessados por meio de um 
browser.
A Figura 6.11 é um modelo geral de um sistema de informação. O sistema é modelado usando-se uma aborda-
gem em camadas (discutida na Seção 6.3), na qual a camadasuperior apoia a interface do usuário, e a inferior é o 
banco de dados do sistema. A camada de comunicação de usuário lida com todas as entradas e saídas da interface 
de usuário, e a camada de recuperação de informação inclui uma lógica específica de aplicação para acessar e 
atualizar o banco de dados. Como veremos mais tarde, as camadas desse modelo podem mapear diretamente os 
servidores em um sistema baseado na Internet.
Como exemplo de uma instanciação do modelo em camadas, a Figura 6.12 mostra a arquitetura do MHC-PMS. 
Lembre-se de que esse sistema mantém e gerencia dados de pacientes que estão consultando médicos espe-
cialistas sobre problemas de saúde mental. Acrescentei detalhes em cada camada do modelo, identificando os 
componentes que oferecem apoio a comunicações de usuário e recuperação e acesso de informação:
1. A camada superior é responsável pela implementação da interface de usuário. Nesse caso, a interface foi im-
plementada usando-se um browser.
2. A segunda camada fornece a funcionalidade de interface de usuário que é entregue por meio do browser. Ela 
inclui componentes que permitem aos usuários fazerem o login no sistema e componentes de verificação 
que asseguram que as operações usadas pelos usuários sejam permitidas para seu papel. Essa camada inclui 
formulários e componentes de gerenciamento de menu que apresentam informações aos usuários, além dos 
componentes de validação de dados que verificam a consistência das informações.
 Figura 6.9 A estrutura de aplicações de processamento de transações
Processamento 
E/S
Lógica 
da aplicação
Gerente 
de transação Banco de dados
Sommerville_Cap_06.indd 117 31/05/2011 15:07:54
118 Engenharia de software
3. A terceira camada define a funcionalidade do sistema e fornece componentes que implementam a proteção do 
sistema, criação e atualização de informações de pacientes, importação e exportação dos dados de pacientes a 
partir de outros bancos de dados, além dos geradores de relatório que criam relatórios de gerenciamento.
 Figura 6.10 A arquitetura de software de um sistema de ATM
Entrada Processo Saída
ATM Banco de dados ATM
Imprimir 
detalhes
Devolver o cartão
Entregar dinheiro
Consultar a conta
Atualizar a conta
Obter ID da 
conta do cliente 
Validar cartão
Selecionar serviço
 Figura 6.11 Arquitetura de sistema de informação em camadas
Interface de usuário
Recuperação e modificação de informação
Banco de dados de gerenciamento 
de transações
Comunicações 
de usuário
Autenticação 
e autorização
 Figura 6.12 A arquitetura do MHC-PMS
Browser Web 
Geração 
de relatórios
Gerenciamento de transações
Banco de dados de pacientes
Login Gerenciador de 
formulários e menus
Validação 
de dados
Verificação 
do papel
Gerencia 
de proteção
Gerenciador 
de informações 
sobre pacientes
Importação
e exportação
de dados
Sommerville_Cap_06.indd 118 31/05/2011 15:07:56
119Capítulo 6 Projeto de arquitetura
4. Finalmente, a camada mais baixa, construída usando um sistema de gerenciamento de banco de dados comer-
cial, fornece gerenciamento de transações e repósitório persistente de dados.
Normalmente, sistemas de informação e de gerenciamento de recursos são baseados na Web, nos quais as 
interfaces de usuário são implementadas usando-se um browser. Por exemplo, sistemas de comércio eletrônico 
são sistemas de gerenciamento de recursos baseados na Internet que aceitam pedidos eletrônicos de bens ou 
serviços e, em seguida, providenciam a entrega desses bens ou serviços ao cliente. Em um sistema de comércio 
eletrônico, a camada específica de aplicação inclui funcionalidade adicional que apoia um ‘carrinho de compras’, 
no qual os usuários podem colocar uma série de itens em transações separadas, e em seguida, pagar por todos 
juntos em uma única transação.
Nesses sistemas, a organização dos servidores geralmente reflete o modelo genérico de quatro camadas apre-
sentado na Figura 6.11. Esses sistemas são frequentemente implementados como arquiteturas/cliente/servidor 
multicamadas, conforme discutido no Capítulo 18:
1. O servidor Web é responsável por todas as comunicações de usuário, com a interface de usuário implementada 
usando um browser;
2. O servidor de aplicações é responsável por implementar a lógica específica de aplicação, bem como o reposi-
tório de informações e pedidos de recuperação;
3. O servidor do banco de dados move as informações para e a partir do banco de dados, e lida com o gerencia-
mento de transações.
Usar vários servidores permite que se tenha alto desempenho e faz com que seja possível lidar com centenas 
de transações por minuto. À medida que a demanda aumenta, os servidores podem ser adicionados em cada nível 
para lidar com o processamento extra envolvido.
 6.4.3 Sistemas de processamento de linguagens
Os sistemas de processamento de linguagens traduzem uma linguagem natural ou artificial em outra re-
presentação dessa linguagem. Para linguagens de programação, também podem executar o código resultante. 
Em engenharia de software, compiladores traduzem uma linguagem artificial de programação em código de 
máquina. Outros sistemas de processamento de linguagens podem traduzir uma descrição XML de dados em 
comandos, para consultar um banco de dados ou uma representação XML alternativa. Sistemas de processa-
mento da linguagem natural podem traduzir uma linguagem natural para outra, por exemplo, o francês para o 
norueguês.
Na Figura 6.13, é ilustrada uma possível arquitetura para um sistema de processamento de linguagem para 
uma linguagem de programação. As instruções da linguagem-fonte definem o programa a ser executado, e um 
tradutor converte as instruções para uma máquina abstrata. Essas instruções são, então, interpretadas por outro 
 Figura 6.13 A arquitetura de um sistema de processamento de linguagem 
Instruções da 
linguagem-fonte
Dados Resultados
Tradutor
Interpretador
Instruções 
abstratas m/c
Verificar sintaxe
Verificar semântica 
Gerar
Buscar
Executar
Sommerville_Cap_06.indd 119 31/05/2011 15:07:57
120 Engenharia de software
componente, que busca as instruções para a execução e as executa usando (se necessário) os dados do ambiente. 
A saída do processo é o resultado da interpretação das instruções sobre os dados de entrada.
Claro que, para muitos compiladores, o interpretador é uma unidade de hardware que processa as instruções 
de máquina, e a máquina abstrata é um processador real. No entanto, para linguagens tipadas dinamicamente, 
como Python, o interpretador pode ser um componente de software.
Os compiladores de linguagem de programação que são parte de um ambiente de programação mais geral 
têm uma arquitetura genérica (Figura 6.14) que inclui os seguintes componentes:
1. Um analisador léxico, que toma os tokens da linguagem de entrada e os converte em um formato interno.
2. Uma tabela de símbolos, que contém informações sobre os nomes das entidades (variáveis, nomes de classes, 
nomes de objetos etc.) usadas no texto que está sendo traduzido.
3. Um analisador sintático, que verifica a sintaxe da linguagem a ser traduzida. Ele usa uma gramática definida da 
linguagem e constrói uma árvore de sintaxe.
4. Uma árvore de sintaxe, que é uma estrutura interna que representa o programa a ser compilado.
5. Um analisador semântico, que usa informações da árvore de sintaxe e a tabela de símbolos para verificar a 
correção semântica do texto na linguagem de entrada.
6. Um gerador de código que ‘anda’ na árvore de sintaxe e gera códigos de máquina abstrata.
Também podem ser incluídos outros componentes que analisam e transformam a árvore de sintaxe para me-
lhorar a eficiência e eliminar a redundância do código de máquina gerado. Em outros tipos de sistema de pro-
cessamento de linguagem, como um tradutor de linguagem natural, haverá componentes adicionais, como um 
dicionário, e o código gerado é a entrada de texto traduzido para outra linguagem.
Existem padrões de arquitetura alternativos que podem ser usados em um sistemade processamento da lin-
guagem (GARLAN e SHAW, 1993). Os compiladores podem ser implementados usando um composto de um re-
positório e um modelo de duto e filtro. Em uma arquitetura de compilador, a tabela de símbolos é um repositório 
de dados compartilhados. As fases da análise léxica, sintática e semântica estão organizadas em sequência, como 
mostra a Figura 6.14, e comunicam-se por meio da tabela de símbolos compartilhados.
Esse modelo de duto e filtro de compilação de linguagem é eficaz em ambientes em lotes nos quais os pro-
gramas são compilados e executados sem interação do usuário — por exemplo, na tradução de um documento 
XML para outro. É menos efetivo quando um compilador é integrado com outras ferramentas de processamento 
de linguagem, como um sistema de edição estruturado, um depurador interativo ou um prettyprinter (formatador 
de impressão) de programa. Nessa situação, as mudanças de um componente precisam refletir imediatamente em 
outros componentes. Portanto, é melhor organizar o sistema em torno de um repositório, como se vê na Figura 6.15.
Essa figura ilustra como um sistema de processamento de linguagem pode ser parte de um conjunto integra-
do de ferramentas de apoio à programação. Nesse exemplo, a tabela de símbolos e a árvore de sintaxe funcionam 
como um repositório central de informações. Ferramentas ou fragmentos de ferramentas comunicam-se por meio 
dele. Outras informações que às vezes são embutidas em ferramentas, como a definição da gramática e a definição 
do formato de saída para o programa, foram retiradas das ferramentas e colocadas no repositório. Portanto, um 
editor dirigido à sintaxe pode verificar se a sintaxe de um programa está correta, uma vez que está sendo digitado 
e um prettyprinter pode criar listagens de programa em um formato que seja fácil de ler.
 Figura 6.14 Arquitetura do compilador em duto e filtro
Análise 
léxica
Análise 
sintática
Análise 
semântica
Geração 
de código
Tabela 
de símbolos
Árvore de sintaxe
Sommerville_Cap_06.indd 120 31/05/2011 15:07:57
121Capítulo 6 Projeto de arquitetura
PONTOS IMPORTANTES
Uma arquitetura de software é uma descrição de como um sistema de software é organizado. As propriedades 
de um sistema, como desempenho, proteção e disponibilidade, são influenciadas pela arquitetura adotada.
As decisões de projeto de arquitetura incluem decisões sobre o tipo de aplicação, a distribuição do sistema, 
os estilos da arquitetura a serem utilizados e as formas como a arquitetura deve ser documentada e avaliada.
As arquiteturas podem ser documentadas a partir de diferentes perspectivas ou visões. As possíveis visões 
incluem uma visão conceitual, uma visão lógica, uma visão de processo, uma visão de desenvolvimento e uma 
visão física.
Os padrões da arquitetura são um meio de reusar o conhecimento sobre as arquiteturas genéricas de sistemas. 
Eles descrevem a arquitetura, explicam quando elas podem ser usadas e discutem suas vantagens e desvantagens.
Entre os padrões de arquitetura comumente usados estão: Modelo-Visão-Controlador, Arquitetura em cama-
das, Repositório, Cliente-servidor e Duto e filtro.
Modelos genéricos de arquiteturas de sistemas de aplicação ajudam-nos a compreender o funcionamento das 
aplicações, comparar aplicações do mesmo tipo, validar projetos de sistemas de aplicação e avaliar os compo-
nentes para reúso em larga escala.
Sistemas de processamento de transações são sistemas interativos que permitem que as informações em um 
banco de dados sejam acessadas remotamente e modificadas por vários usuários. Os sistemas de informação e 
de gerenciamento de recursos são exemplos de sistemas de processamento de transações.
Sistemas de processamento de linguagens são usados para traduzir textos de uma linguaguem para outra e 
para realizar as instruções especificadas em uma linguagem de entrada. Eles incluem um tradutor e uma má-
quina abstrata que executa a linguagem gerada.
LEITURA COMPLEMENTAR
Software Architecture: Perspectives on an Emerging Discipline. Esse foi o primeiro livro sobre arquitetura de software, 
apresenta uma boa discussão sobre diferentes estilos de arquitetura. (SHAW, M.; GARLAN, D. Software Architecture: 
Perspectives on an Emerging Discipline. Prentice Hall, 1996.)
Software Architecture in Practice, 2nd ed. Essa é uma discussão prática sobre arquiteturas de software que não 
exagera nos benefícios do projeto de arquitetura. O livro fornece uma lógica clara de negócio, explicando por que 
as arquiteturas são importantes. (BASS, L.; CLEMENTS, P.; KAZMAN, R. Software Architecture in Practice. 2. ed. Addison-
-Wesley, 2003.)
 Figura 6.15 Uma arquitetura de repositório para um sistema de processamento de linguagem
Analisador 
de sintaxe
Analisador 
léxico
Analisador 
de semântica
Árvore de 
sintaxe 
abstrata
Definição 
de gramática
Tabela 
de símbolos
Definição 
de saídas
Pretty-
printer
Editor
Otimizador
Gerador 
de código
Repositório
Sommerville_Cap_06.indd 121 31/05/2011 15:07:59
122 Engenharia de software
The Golden Age of Software Architecture. Esse trabalho avalia o desenvolvimento da arquitetura de software 
desde seu início, na década de 1980, até seu uso atual. Contém pouco conteúdo técnico, mas apresenta um inte-
ressante panorama histórico. (SHAW, M.; CLEMENTS, P. The Golden Age of Software Architecture. IEEE Software, v. 21, 
n. 2, mar.-abr. 2006.) Disponível em: .
Handbook of Software Architecture. Esse é um trabalho em andamento realizado por Grady Booch, um dos 
primeiros evangelizadores da arquitetura de software. Ele vem documentando as arquiteturas de vários sistemas 
de software para que você possa ver a realidade em vez de abstrações acadêmicas. Disponível em: , e destina-se a aparecer como um livro.
EXERCÍCIOS
6.1 Ao descrever um sistema, explique por que você pode precisar projetar sua arquitetura antes de a especifi-
cação de requisitos estar completa.
6.2 Você foi convidado para preparar e entregar uma apresentação para um gerente não técnico, a fim de jus-
tificar a contratação de um arquiteto de sistemas para um novo projeto. Escreva uma lista de aspectos que 
definam os pontos principais de sua apresentação. Naturalmente, você deve explicar o que se entende por 
arquitetura de sistema.
6.3 Explique por que podem surgir conflitos ao se projetar uma arquitetura na qual tanto os requisitos quanto a 
disponibilidade e a proteção sejam os mais importantes requisitos não funcionais. 
6.4 Desenhe diagramas mostrando uma visão conceitual e uma visão de processo das arquiteturas dos sistemas 
a seguir: 
Um sistema automatizado de emissão de bilhetes, usado por passageiros em uma estação ferroviária. 
Um sistema de videoconferência controlado por computador, que permite que áudio, vídeo e dados de 
computador sejam visíveis para vários participantes ao mesmo tempo. 
Um robô limpador de chão que se destina a limpar os espaços relativamente livres, como corredores. O 
robô deve ser capaz de perceber paredes e outras obstruções.
6.5 Explique por que, ao projetar a arquitetura de um sistema de grande porte, você normalmente usa vários pa-
drões de arquitetura. Além das informações sobre os padrões discutidos neste capítulo, quais informações 
adicionais podem ser úteis no projeto de sistemas de grande porte?
6.6 Sugira uma arquitetura para um sistema (tal qual o iTunes) que sirva para vender e distribuir música na Inter-
net. Que padrões são a base para essa arquitetura? 
6.7 Explique como você usaria o modelo de referência de ambientes CASE (disponíveis no site do livro na Internet) 
para comparar as IDEs oferecidas por diferentes fornecedores de uma linguagem de programação como a Java.
6.8 Usando o modelo genérico de um sistema de processamento de linguagem aqui apresentado, projete a ar-
quitetura de um sistema que aceita comandos de linguagem natural e traduz esses comandos em consultas 
de bancos de dados em uma linguagem como