Desenvolver software não é uma tarefa fácil. É por esse motivo que muitos projetos de software fracassam durante seu desenvolvimento ou ao obter seus resultados. Entre esses maus resultados, encontramos os que custaram muito acima do orçamento, os incompletos e os que não solucionam os problemas como deveriam resolver.

Não é fácil alcançar um bom produto de software devido à complexidade envolvida em seu processo de desenvolvimento. Além de lidar com a complexidade inerente ao problema, devemos também nos preocupar em como o software resolve esse problema. Assim, o software deve, além de resolver o problema, resolvê-lo da forma esperada. Ou em outras palavras:

Espera-se que, além de função, o produto de software possua os atributos de qualidade esperados.

Podemos observar no Exemplo 1 que o programa funciona corretamente, mas, por não exibir o desempenho esperado, acaba sendo abandonado. Por outro lado, consertar esse programa para que seja útil é relativamente fácil. Por exemplo, se o programa não multiplica rápido o bastante, basta apenas reimplementar a função de multiplicação para que tenha um melhor desempenho.

Acontece que diminuir o tempo de resposta de uma funcionalidade no SASF, dado o tamanho do sistema, pode não ser tão simples quanto diminuir o tempo de execução de uma função matemática. O alto tempo de resposta de um serviço no SASF pode ser função de uma ou mais decisões tomadas ao longo do desenvolvimento que resultaram na sua estrutura e organização interna. Essa estrutura e organização é o que chamamos de arquitetura. Como o atendimento aos atributos de qualidade do software se deve em grande parte à sua arquitetura, surge a necessidade de estudá-la. E, por fim, é através do estudo das características e técnicas de projeto de arquitetura que poderemos projetar e desenvolver melhores produtos de software.

Desde sua primeira menção em um relatório técnico da década de 1970 intitulado Software Engineering Tecnhiques [4], diversos autores se propuseram a definir o termo arquitetura de software. Por esse motivo, ao invés de criarmos nossa própria definição do termo, faremos uso de quatro definições existentes a fim de ressaltar suas diferentes características. As três primeiras que usaremos são as definições de facto do termo. Elas foram formuladas por autores que se destacam na área desde sua introdução e são usadas atualmente pela grande maioria dos professores, alunos e praticantes da área. Por outro lado, também mostraremos a definição de jure de arquitetura de software. Ela é parte do padrão ISO/IEEE 1471-2000 [13] e teve sua criação motivada justamente para fazer com que estudantes, professores e praticantes de arquitetura de software concordem sobre o termo.

Perry e Wolf introduziram sua definição para arquitetura de software em seu artigo seminal Foundations for the Study of Software Architecture [20]. A definição que eles propõem consiste na Fórmula 1 e na explicação de seus termos:

De acordo com essa definição, a arquitetura de software é um conjunto de elementos arquiteturais que possuem alguma organização. Os elementos e sua organização são definidos por decisões tomadas para satisfazer objetivos e restrições. São destacados três tipos de elementos arquiteturais:

Já a organização dita as relações entre os elementos arquiteturais. Essas relações possuem propriedades e restringem como os elementos devem interagir de forma a satisfazer os objetivos do sistema. Adicionalmente, essas relações devem ser ponderadas de modo a indicar sua importância no processo de seleção de alternativas.

Exemplo 3

Um elemento de dados muito presente no SASF e em sistemas de informação em geral é o banco de dados. Ele é o responsável por guardar e recuperar dados no sistema.

No SASF, inicialmente, estão presentes três tipos de dados:

1. Informação textual: informações cadastrais dos usuários e informações textuais sobre os filmes;
2. Imagens: imagens que compõem a identidade visual do sistema, foto do usuário presente em seu perfil e imagens de divulgação dos filmes;
3. Vídeos: filmes completos, trailers e documentários “por trás das câmeras” disponíveis para streaming.

Por isso, consideramos um elemento de dados para cada tipo. Assim, temos o banco de dados responsável por informações textuais, o banco de dados responsável por imagens e o banco de dados responsável por vídeos. Essa separação de responsabilidades permite que a implementação de cada elemento de dados disponha de serviços diferenciados ou mesmo tire proveito da natureza de seus dados para atender a algum atributo de qualidade (desempenho, escalabilidade, etc.). Dessa maneira, o elemento responsável por texto pode ser otimizado para busca por palavras-chave, enquanto o responsável por vídeos pode ser otimizado para recuperar grandes massas de dados a cada requisição. Por outro lado, também faz sentido dividir logicamente os elementos de dados em: elemento de dados de usuários e de dados de filmes. Vale notar que essa divisão é ortogonal à divisão em elementos de texto, imagens e vídeos e, portanto, o elemento de dados de usuários pode ser composto por um elemento de dados textuais e outro elemento de dados de imagens, da mesma maneira que o elemento de dados de filmes pode conter o elemento de dados textuais, de imagens e de vídeos.

Como exemplo de elemento de processamento, citamos a lógica de negócio do SASF. Ela contém as regras de negócio que compõem o SASF. Note que podemos ainda dividir esse elemento de processamento em elementos mais especializados: o elemento de processamento responsável por criar, editar, recuperar e remover usuários, o responsável por criar, editar, recuperar e remover informações de filmes, o responsável pelo aluguel de filmes e o responsável por controlar a sessão de streaming, entre outros. Essa divisão, assim como a divisão dos elementos de dados, pode ser feita em prol do atendimento aos atributos de qualidade 1.

No entanto, um elemento não é capaz de criar, editar, recuperar ou remover usuários sem se comunicar com os dados dos usuários. Da mesma maneira, o elemento responsável por manipular as informações dos filmes deve se comunicar com os elementos que guardam os dados dos filmes. Ou ainda, para controlar a sessão de streaming, o responsável deve obter o filme do elemento de dados que contém os filmes completos. Essa comunicação é feita pelos diversos elementos de conexão do SASF. Entre eles, podemos citar: o driver JDBC 2, que permite a comunicação com o banco de dados responsável pelos usuários; o protocolo FTP, para transferência de vídeos; o protocolo HTTP, para transferências a partir do banco de imagens; ou o REST 3, que é uma especialização do HTTP e é usado para comunicação entre elementos de processamento. A Figura 1 ilustra alguns elementos que formam a arquitetura do SASF.

Figura 1: Alguns elementos de processamento, de dados e de conexão do SASF

Além de terem uma visão mais concreta sobre arquitetura que Perry e Wolf, Garlan e Shaw são mais explícitos quando mencionam o propósito de se aplicar conhecimentos de arquitetura num sistema de software. Para eles, arquitetura de software se torna necessária quando o tamanho e a complexidade dos sistemas de software crescem. Assim, o problema de se construir sistemas vai além da escolha dos algoritmos e estruturas de dados certos. Esse problema envolverá também decisões sobre as estruturas que formarão o sistema, a estrutura global de controle será usada, protocolos de comunicação, sincronização e acesso a dados, atribuição de funcionalidade a elementos do sistema, ou ainda sobre distribuição física dos elementos do sistema. Além disso, o problema envolverá decisões que impactarão no comportamento do sistema em termos de escala e desempenho, entre outros atributos de qualidade [11].

A visão sobre arquitetura de software de Garlan e Shaw se torna importante por conter três aspectos. O primeiro é por eles serem explícitos em quando devemos aplicar conhecimentos de arquitetura de software – quando lidamos com grandes sistemas. O segundo é por serem claros na separação de tarefas entre design detalhado e design arquitetural – o primeiro se preocupa com algoritmos e estruturas de dados, enquanto o segundo se preocupa com os elementos e organização do sistema como um todo, sendo em relação à estrutura do sistema, controle, comunicação, ou implantação. E, por fim, é por eles citarem que o processo de design da arquitetura precisa se preocupar com atributos de qualidade do sistema – alcançar escalabilidade ou desempenho, por exemplo.

Como veremos a seguir, a definição de Bass et al é bastante similar à encontrada no padrão ISO/IEEE 1471-2000. No entanto, sua especificidade sobre quais propriedades dos elementos arquiteturais devem ser consideradas a faz ser mencionada:

A arquitetura de um programa ou de sistemas computacionais é a estrutura ou estruturas do sistema, a qual é composta de elementos de software, as propriedades externamente visíveis desses elementos, e os relacionamentos entre eles. [2]

Como já observado por Gorton [10], essa definição é explícita quanto ao papel da abstração na arquitetura (quando fala de propriedades externamente visíveis), e também quanto ao papel das múltiplas visões arquiteturais (estruturas do sistema). Devemos também mencionar o uso do termo “elementos de software” como as peças fundamentais da arquitetura. Na edição anterior dessa definição [3], seus autores usavam “componentes de software” ao invés de “elementos de software”. Essa mudança foi feita para deixar a definição mais geral, principalmente pelo termo “componente de software” ter um sentido específico na área de Engenharia de Software baseada em Componentes.

Exemplo 5

Podemos observar a arquitetura do SASF através de uma visão de partes funcionais ( Figura 2):

1. módulo responsável pelo cadastro de usuários,
2. módulo responsável pelo cadastro de filmes,
3. módulo responsável pelo aluguel de filmes,
4. módulo responsável pela transmissão de filmes,
5. módulo responsável pela sugestão de filmes, etc.

Esses módulos proveem serviços e informações a outras partes do sistema: por exemplo, uma operação de aluguel ou de transmissão de filmes deve atualizar o histórico presente na conta do usuário. Isso ocorre porque o módulo de sugestão usará periodicamente esse histórico a fim de gerar listas de filmes de acordo com as preferências do usuário.

Figura 2: Módulos funcionais do SASF

Mas essa não é a única maneira de observarmos o sistema. Podemos também ver o sistema como um conjunto de processos executando e se comunicando em máquinas diferentes, como observado na Figura 3. O navegador do usuário, que pode ser considerado parte do sistema e que está executando em uma máquina, se comunica usando o protocolo HTTPS com um servidor de aplicações, que está executando em outra máquina e que contém parte da lógica do negócio (e os módulos de cadastro, autenticação, e atualização do usuário, entre outros). O servidor de aplicações, por sua vez, se comunica de forma diferente com cada um dos sistemas de armazenamento presentes. Ele usa JDBC para obter dados de usuários, FTP para obter vídeos e HTTP para obter imagens. Já o motor de sugestão é visto como outro processo executando numa máquina diferente do servidor de aplicação. Esse processo, de tempos em tempos, lê, processa e atualiza informações do banco de usuários a fim de gerar a lista de filmes sugeridos. Ele também usa JDBC para se comunicar com o banco de usuários.

Figura 3: Processos presentes no SASF

Na visão em que dividimos o sistema em partes funcionais, podemos perceber aspectos do software como a composição entre elementos ou pontos de reuso. Já na visão em que dividimos o sistema em processos, podemos observar outros aspectos, como propriedades de comunicação e de interação entre as partes do sistema. Por exemplo, na primeira visão, os cadastros de filmes e de usuários podem compor um módulo maior responsável por todos os cadastros. Já na segunda visão, percebemos que a comunicação entre o navegador e o servidor de aplicações é síncrona, enquanto a comunicação entre o motor de sugestão e o banco de dados é assíncrona em relação às ações dos usuários.

O propósito da criação do padrão ISO/IEEE 1471-2000 [13] foi o de ajudar no consenso entre autores, estudantes e profissionais sobre o que é e para que serve arquitetura de software. Assim, esse padrão não só define arquitetura de software, mas também introduz um arcabouço conceitual para descrição arquitetural. Sua definição de arquitetura de software, a qual nós adotaremos ao longo do livro, é a seguinte:

Definição 1: arquitetura de software

Arquitetura é a organização fundamental de um sistema incorporada em seus componentes, seus relacionamentos com o ambiente, e os princípios que conduzem seu design e evolução.

Podemos perceber que a definição acima é consistente com as anteriores por também mencionar que arquitetura compreende estrutura (ou elementos ou componentes), relações, e decisões (ou princípios). No entanto, ela vai além adicionando mais uma preocupação à arquitetura: conduzir a evolução do software.

Evolução de software é o fenômeno de mudança que ocorre no software ao longo dos anos e das múltiplas versões, desde seu início até o completo abandono do sistema. Essa mudança não está só relacionada com a adição e remoção de funcionalidades, mas também está relacionada com a manutenção do código ao longo do ciclo de vida do software. Essa manutenção pode melhorar ou deteriorar tanto atributos externos de qualidade do software, os quais são percebidos pelos usuários (e.g., desempenho, tolerância a falhas, disponibilidade), quanto atributos internos de qualidade do software, os quais são percebidos pelos envolvidos no desenvolvimento (e.g., testabilidade, legibilidade, reusabilidade).

Uma vez que um dos principais objetivos de se projetar uma arquitetura é o de atingir a qualidade desejada pelos interessados no sistema, se torna claro o papel da arquitetura em conduzir a evolução do software, uma vez que ela conterá decisões que contribuirão para a preservação da qualidade do sistema durante seu ciclo de vida.

Antes de entrarmos em detalhes sobre os diversos aspectos de arquitetura de software, devemos entrar em consenso sobre o termo “componente de software”. Em Engenharia de Software, “componentes” têm vários significados divergentes. Um significado, de acordo com o Standard Computer Dictionary [14], é que um componente é uma das partes que compõem o sistema. Dessa maneira, “componente” pode ser substituído por “módulo”, “unidade”, ou mesmo “elemento” de software. É esse o significado de “componente” usado no padrão ISO/IEEE 1471-2000 e que será usado ao longo deste livro.

Por outro lado, um componente também pode ter o significado como o descrito por Kai Qian, em Component-Oriented Programming [1]: “um pedaço de código autocontido e autoimplantável com uma funcionalidade bem definida e que pode ser agregado com outros componentes através de sua interface.” Esse outro significado é estritamente ligado à Engenharia de Software baseada em Componentes e não será usado a não ser que sejamos explícitos sobre ele.

O padrão ISO/IEEE 1471-2000 também define outros termos fundamentais para o entendimento de arquitetura de software, em especial visões (views). Esse termo será brevemente descrito na Seção "Visões da Arquitetura" e então detalhado no Capítulo XX.

A arquitetura de software é mais bem entendida através de suas partes. Considerando as definições expostas acima, podemos ressaltar seus dois principais aspectos, que serão os meios para alcançar os atributos de qualidade: elementos e decisões arquiteturais. Detalharemos cada aspecto a seguir.

Elementos arquiteturais

A arquitetura de um sistema deve definir os elementos que formarão o software. Tais elementos definem como o software é particionado em pedaços menores e, assim, definem como o software é entendido. Elementos arquiteturais são divididos em dois tipos: elementos estáticos e elementos dinâmicos.

Os elementos estáticos de um sistema de software definem as partes do sistema e qual sua organização. Esse tipo de elemento reflete o sistema durante o design e é constituído de elementos de software (e.g., módulos, classes, pacotes, procedimentos, ou ainda serviços autocontidos), elementos de dados (e.g., entidades e tabelas de bancos de dados, arquivos de dados, ou classes de dados), e elementos de hardware (e.g., computadores em que o sistema vai executar, ou outros tipos de hardware que o sistema usará: roteadores, cabos, ou impressoras).

Elementos estáticos não consistem apenas das partes estáticas do sistema, mas também como eles se relacionam entre si. Associações, composições, e outros tipos de relações entre elementos de software, de dados, e de hardware formam o aspecto estático que compõe a arquitetura do sistema. O exemplo a seguir ilustra elementos estáticos de um sistema de software.

Exemplo 6

Voltando ao SASF, observar sua arquitetura sob uma ótica estática expõe seus elementos estáticos. Em tempo de design, alguns elementos estáticos são cada pacote, módulo ou conjunto de classes responsáveis por cada função do sistema. Alguns desses elementos são os responsáveis por: criação, edição, remoção e recuperação de usuários e filmes, aluguel de filmes, autenticação e autorização dos usuários, entre outros.

Por outro lado, elementos dinâmicos definem o comportamento do sistema. Esse tipo de elemento reflete o sistema durante a execução e nele estão incluídos processos, módulos, protocolos, ou classes que realizam comportamento. Elementos dinâmicos também descrevem como o sistema reage a estímulos internos e externos, como mostrado no exemplo a seguir.

Exemplo 7

Ainda na arquitetura do SASF, podemos também observar o sistema sob uma ótica dinâmica. Essa exibe seus elementos dinâmicos, a exemplo dos diversos processos executando nas diversas máquinas que compõem o sistema. Esses processos pertencem aos servidores de aplicação, aos serviços de armazenamento, ou mesmo aos navegadores dos usuários.

Elementos Arquiteturais e Atributos do Sistema

Note que quando examinamos os elementos arquiteturais de um sistema, tanto os estáticos quanto os dinâmicos, devemos também prestar atenção nas relações que os ligam. Essas relações são importantes, pois especificam a comunicação e o controle da informação e do comportamento que formam o sistema. Assim, as relações definem diversos aspectos do sistema, por exemplo, quais dados do objeto da classe A são visíveis pelos objetos da classe B; ou quantas leituras concorrentes são feitas no elemento C; ou ainda como o elemento D é autorizado a escrever dados no elemento E. Dessa maneira, essas relações têm efeito sobre atributos de qualidade do sistema, sejam os percebidos pelos usuários, ou os percebidos pelos desenvolvedores. Os exemplos seguintes mostram casos de como relações entre elementos arquiteturais afetam atributos de qualidade.

Exemplo 8

Se dividirmos a arquitetura do SASF em três camadas (apresentação, lógica de negócio, e persistência), a camada de persistência pode ser um recurso compartilhado por diversas instâncias da lógica de negócio. Se temos diversas instâncias da lógica de negócio, mesmo que algumas saiam do ar, as restantes proverão disponibilidade ao sistema, desde que a camada de persistência (e.g., o banco de dados) não falhe. Além disso, o compartilhamento do banco de dados pode significar também o acesso concorrente ao mesmo. Assim, quando uma instância da lógica de negócio lhe faz uma requisição, essa requisição lhe será respondida mesmo que outras instâncias estejam fazendo o mesmo (obviamente, isso só ocorre se alguma instância da lógica de negócio não esteja realizando alguma requisição que precise de acesso exclusivo aos dados).

Exemplo 9

A separação do sistema em três camadas ( Figura 4) pode também facilitar a manutenção. Se, além de adotar essa divisão, a camada de apresentação apenas se comunicar com a lógica de negócio, mas não com a de persistência, mudanças na camada de persistência afetarão apenas a camada de negócio. Portanto, caso seja necessário mudar o fornecedor da camada de persistência, a assinatura dos métodos disponíveis, ou mesmo o protocolo de comunicação, apenas a lógica de negócio será afetada por essas mudanças, uma vez que não existe acoplamento entre a apresentação e a persistência.

Figura 4: Ilustração da divisão de uma arquitetura em três camadas.

Como consequência da existência dos diversos interessados nos objetivos alcançados pelo software, a arquitetura também possuirá diversos interessados. No entanto, uma vez que os interessados no sistema têm diferentes preocupações e níveis de conhecimento, a arquitetura não deve ser exposta da mesma maneira para interessados diferentes. Para resolver esse problema, surge o conceito de visões arquiteturais.

Podemos observar que há preocupações bem diferentes entre os dois interessados e assim perceber que dimensões bem diferentes da arquitetura são necessárias para satisfazê-los. Para o primeiro, a arquitetura deve mostrar que módulos lógicos (pacotes, classes, bibliotecas) compõem o sistema, além das relações de comunicação e restrição entre eles. Já para o segundo, a arquitetura deve mostrar como o sistema está dividido fisicamente, quais partes do sistema estão executando em quais computadores, quais os links físicos entre esses computadores, etc.

Uma visão arquitetural é uma representação da informação (ou parte dela) contida na arquitetura de forma que se adéque às necessidades de um ou mais interessados. Ela facilita o entendimento da arquitetura por parte do interessado, uma vez que vai filtrar e formatar a informação de acordo com as necessidades e preocupações do interessado em questão.

Definição 4: visão arquitetural

É a representação do sistema ou de parte dele da perspectiva de um conjunto de interesses relacionados.

Não podemos esquecer que o próprio arquiteto também pode tirar proveito desse conceito durante o processo de design da arquitetura. Quando um arquiteto faz design, ele usa o conceito de visões arquiteturais para assim endereçar as diferentes preocupações do sistema por vez. Dessa maneira, ele divide o problema de design em problemas menores e, consequentemente, menos complexos: ele endereça cada atributo de qualidade – cada aspecto do sistema – que serão alcançados por essa arquitetura. Atacando uma visão por vez, o arquiteto pode, por exemplo: primeiro definir as partições lógicas, ou seja, os módulos funcionais que comporão o sistema – e assim considerar uma visão lógica do sistema; definir as partições dinâmicas do sistema, ou seja, quais processos, threads e protocolos estarão presentes no sistema – considerar uma visão de dinâmica; definir as partições do ponto de vista de implementação, ou seja, que classes, pacotes e bibliotecas comporão o sistema – considerar uma visão de desenvolvimento; e, por fim, definir onde as partes dinâmicas executarão, ou seja, onde e em quais máquinas os diversos “executáveis” do software estarão implantados, além de como eles vão se comunicar – considerar uma visão de implantação do sistema.

Considerando o que mencionamos até agora sobre arquitetura de software, percebemos que ela provê diversos benefícios: proporciona atendimento de atributos de qualidade, ajuda na comunicação entre os interessados no sistema e guia a evolução do sistema. No entanto, até agora, só falamos da arquitetura como algo abstrato. Ou seja, apenas falamos dela como uma propriedade imposta ou emergente de um sistema, mas não falamos em como documentá-la, nem fomos específicos quanto aos benefícios proporcionados por sua documentação.

Dificuldades

No entanto, documentar a arquitetura é tão ou mais difícil que criá-la. Os principais motivos são três: o documento reflete a complexidade da arquitetura, que geralmente é alta; o documento reflete o tamanho da arquitetura, que o torna custoso para construir e ser lido; e o documento, por seu tamanho e complexidade, é difícil de manter consistente com o sistema que ele descreve.

A complexidade do documento surge principalmente da necessidade de mostrar de diferentes maneiras os diferentes aspectos da arquitetura, ou seja, da necessidade de mostrar as diferentes visões da arquitetura. Cada visão possui uma forma de melhor ser representada e também deve estar consistente com as outras visões.

Exemplo 37

Na documentação da arquitetura do SASF podemos observar, entre outras, duas visões diferentes: uma visão que mostra aspectos dinâmicos e outra que mostra o sistema estaticamente.

A visão estática mostra os principais módulos funcionais do software e, na Figura 5, foi representada por um diagrama de classes em Unified Modeling Language (UML) contendo os módulos funcionais e sua descrição. Entre esses módulos funcionais, podemos encontrar o responsável pelo cadastro de usuários, o responsável pelo cadastro de filmes, o responsável por sugerir novos filmes a usuários, e o responsável pelo streaming de filmes.

Figura 5: Uma visão estática da arquitetura do SASF

Já a visão dinâmica da arquitetura se preocupa em mostrar os módulos que possuem comportamento dinâmico no sistema. Aqui, eles foram representados por um diagrama de sequência, também em UML, que mostra seu comportamento e suas interações com outros módulos ( Figura 6). Obviamente, os módulos usados nessa visão devem ter correspondentes na visão estática.

Figura 6: Uma visão dinâmica da arquitetura do SASF, mostrando o comportamento de alguns módulos durante o processo de transmissão de um filme.

Documentos grandes levam tempo para serem construídos. Além disso, documentos grandes, na prática, não são usados a não ser que proporcionem para o desenvolvimento um benefício maior que o custo de lê-lo. Essa realidade pode ser traduzida em duas fases. Na primeira, é feito um grande esforço para se construir o documento de arquitetura. Ainda nessa fase, o documento é completo e consistente com o sistema, além de ter o potencial para prover os benefícios de uma arquitetura bem documentada. No entanto, a segunda fase consiste no processo de desatualização do conteúdo do documento, que ocorre por falha no processo ou pelo alto custo de se manter o documento consistente, e que tem por consequência a inutilização do documento de arquitetura e o possível aumento da entropia no sistema.

O problema da inconsistência da arquitetura com o código acontece porque, em muitos processos de desenvolvimento, arquitetura evolui ao longo do tempo, seja uma evolução planejada ou não. Uma evolução não-planejada pode acontecer da forma descrita no exemplo a seguir.

Exemplo 38

Lembrando da arquitetura do SASF, que foi dividida em três camadas: apresentação, lógica de negócio e persistência, uma das decisões impostas dita que a camada de apresentação só pode se comunicar com a lógica de negócio. No entanto, um desenvolvedor, medindo que a exibição da interface está demorando porque o carregamento das imagens necessárias está lento, resolve modificar a interface para que proceda da seguinte maneira. O pedido das imagens é feito diretamente à camada de persistência, contornando assim o overhead da camada lógica para tanto. Uma vez que ele nota que o desempenho da exibição da interface com o usuário agora está satisfatório, ele adiciona essa mudança ao código.

Acontece que, com isso, ele adicionou uma mudança também na arquitetura do sistema. A partir daí, há comunicação entre o módulo de interface e de persistência, fazendo assim que a documentação da arquitetura esteja inconsistente em relação ao código do sistema.

Como já foi mencionado no padrão ISO/IEEE 1471-2000, a arquitetura de um sistema existe independentemente dela ter sido documentada ou planejada. No entanto, em pequenos sistemas, pensar, planejar, documentar e manter a arquitetura pode não ser necessário: um conjunto de classes e pacotes ou de módulos com suas relações e evolução minimamente pensados (ou uma Big Ball of Mud) pode atender aos requisitos funcionais e os atributos de qualidade do sistema. Normalmente, isso acontece quando os requisitos não são difíceis de serem atendidos. Assim, todos os interessados ficam satisfeitos – que podem não ser muitos ou conflitantes – e o sistema atinge o sucesso esperado.

Em casos assim, realmente, os custos de planejar, documentar e manter a arquitetura seriam maiores que os benefícios proporcionados por ela.

No entanto, quando os sistemas crescem, pensar em arquitetura – nos atributos de qualidade e nas múltiplas visões e interessados envolvidos –, e documentá-la se tornam necessários. Observaremos essa necessidade nos dois exemplos seguintes: apesar de serem exemplos de sistemas funcionalmente semelhantes ao do exemplo anterior, eles têm requisitos não-funcionais que impõem a necessidade de uma arquitetura bem pensada e documentada.

Podemos notar que todas essas perguntas afetarão como o sistema estará organizado internamente, mas não afetarão suas funcionalidades, que continuarão sendo as do exemplo anterior. Inferimos também que a arquitetura desse sistema e sua documentação serão mais complexas que a do Exemplo 39.

No entanto, no caso do SASF, percebemos que a arquitetura pode se complicar ainda mais, mesmo considerando quase as mesmas funcionalidades. Uma arquitetura ainda mais complexa necessita de uma documentação ainda mais completa para ajudar no desenvolvimento e manutenção desse sistema de software.

O mais importante a se observar nesse exemplo (e no estudo do SASF) é que o design e a documentação da arquitetura não são atividades fáceis nem baratas. O arquiteto escolhido para resolver esse problema deve (1) conhecer os interessados, (2) conhecer os atributos de qualidade impostos ao sistema por esses interessados, (3) conhecer as relações e trade-offs entre interessados e atributos de qualidade, (4) conhecer técnicas, padrões e ferramentas que permitam o atendimento aos atributos, e (5) documentar a solução do problema, de forma que os interessados entendam e tirem proveito do documento gerado.

O objetivo deste livro é fazer com que o leitor seja capaz de endereçar todos os aspectos da arquitetura citados anteriormente, podendo realizar algumas das diversas funções realizadas por um arquiteto de software. Dessa maneira, o objetivo deste capítulo foi dar uma visão geral do conhecimento necessário para tanto, fundamentando-o com alguns exemplos e definições. Assim, esperamos que o leitor, a partir de agora:

Já no próximo capítulo, conheceremos os principais interessados que devem ser contemplados pela arquitetura, além de suas características e relações. No capítulo seguinte, entenderemos melhor os atributos de qualidade impostos por esses interessados, além de apresentarmos algumas técnicas para atender esses atributos. Em seguida, teremos um capítulo focado em padrões arquiteturais, uma vez que o uso de padrões no design da arquitetura é uma técnica essencial ao arquiteto. Por fim, no último capítulo, aprenderemos a documentar a solução que atenderá aos interessados e atributos do sistema.