Skip to content Skip to navigation Skip to collection information

OpenStax-CNX

You are here: Home » Content » Arquitetura de Software » Fundamentos de Arquitetura de Software

Navigation

Recently Viewed

This feature requires Javascript to be enabled.
 

Fundamentos de Arquitetura de Software

Module by: Guilherme Germoglio. E-mail the author

Summary: Neste capítulo, arquitetura é definida e tem seus benefícios e características expostos.

No capítulo introdutório, mencionamos que o Design de Software pode ser dividido em duas atividades: design de alto-nível ou arquitetural e design detalhado e que ambas as atividades têm um papel importante no ciclo de desenvolvimento do software. Como no objeto de estudo deste livro é Arquitetura de Software, voltamo-nos agora para a primeira atividade em questão.

Este capítulo tem como objetivo expor o leitor aos fundamentos de Arquitetura de Software ou, em outras palavras, fazer com que seja capaz de:

  • Reconhecer, entender, e comparar as diferentes definições existentes do termo arquitetura de software
  • Relacionar as diferentes definições de arquitetura de software com o padrão ISO/IEEE 1471
  • Identificar as características e benefícios proporcionados por uma boa arquitetura
  • Avaliar os benefícios de explicitamente projetar a arquitetura durante o desenvolvimento do software

Motivação para desenvolver melhores sistemas

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.

Exemplo 1

Considere um programa que realize as quatro operações: soma, subtração, multiplicação e divisão. Se o tempo de resposta de suas operações for sempre maior do que o tempo que seu usuário está disposto a esperar, esse programa não terá utilidade mesmo que sempre retorne o resultado correto.

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.

Exemplo 2

Considere agora o SASF, já apresentado no Capítulo XX. Considere também que ele se mostra incapaz de responder em menos de dois segundos às operações de aluguel de filmes. Uma vez que os usuários não estão dispostos a esperar esse tempo pela principal operação do sistema, isso resultará numa má experiência de uso, que será motivo para que seus usuários deixem de usá-lo e também deixem de pagar pelo serviço.

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.

O que é Arquitetura 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.

Definição de Arquitetura de Software por Perry e Wolf

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:

Fórmula

Arquitetura = { Elementos , Organiza ç ã o , Decis õ es } Arquitetura = { Elementos , Organiza ç ã o , Decis õ es }
(1)

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:

  • Elementos de processamento: : são elementos que usam ou transformam informação;
  • Elementos de dados: : são elementos que contêm a informação a ser usada e transformada; e
  • Elementos de conexão: : são elementos que ligam elementos de qualquer tipo entre si.

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
Figura 1 (elementos.png)

Arquitetura de Software por Garlan e Shaw

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.

Exemplo 4

A arquitetura de um sistema operacional, para atingir atributos de desempenho e portabilidade, deve se preocupar com diversos aspectos que comporão o sistema. É claro que alguns algoritmos serão também responsáveis pelo desempenho do S.O. em questão, como o responsável pela ordenação por prioridade dos processos em execução ou o de alocação de memória para um novo processo; mas a organização do sistema em camadas de abstração (abstração de hardware, sistema de arquivos e drivers, gerência de processos, API do sistema, bibliotecas e aplicações), a comunicação entre elas (uma camada só pode se comunicar com a camada seguinte, ou aplicações e bibliotecas só podem se comunicar com a API do sistema, etc.) e a sincronização (um aplicativo sugere o arquivamento de dados, mas o sistema de arquivo decidirá quando isso será feito) também impactarão no seu desempenho. Note que essa organização também tem impacto na portabilidade: quanto menos acoplado o resto das camadas for da camada de abstração de hardware, mais fácil será de realizar mudanças para que o sistema operacional esteja disponível para uma nova plataforma de hardware – idealmente, só havendo que se reimplementar essa camada.

Arquitetura de Software por Bass et al

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
Figura 2 (modulos.png)

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
Figura 3 (processos.png)

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.

Arquitetura de Software pelo Padrão ISO/IEEE 1471-2000

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.

Decompondo a definição de Arquitetura de Software

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.
Figura 4 (3-camadas.png)

Decisões arquiteturais

Uma arquitetura não deve ter suas estruturas definidas aleatoriamente, uma vez que são elas que permitem o sucesso relativo aos objetivos do sistema. Dessa maneira, é trabalho do arquiteto definir essas estruturas em meio às alternativas de design arquitetural existentes. O arquiteto deve decidir entre as alternativas, particionando o sistema em elementos e relações que possibilitarão o atendimento aos atributos de qualidade. Essas decisões são chamadas decisões arquiteturais.

Definição 2: decisão arquitetural
Uma escolha entre as alternativas de design arquitetural. Essa escolha se propõe a alcançar um ou mais atributos de qualidade do sistema, por meio da(s) estrutura(s) arquiteturais que ela envolve ou define.

Características

As decisões arquiteturais têm, basicamente, três características que devem ser consideradas: descrição, objetivos e fundamentação.

A primeira característica é bem clara. É simplesmente a descrição do que foi decidido para o sistema, seja a descrição um elemento, módulo, classe, ou serviço que existirá da arquitetura, a descrição da comunicação de um elemento da arquitetura com outro, a descrição da agregação de diversos elementos diferentes da arquitetura para formar um serviço, ou a descrição de um princípio ou mais princípios que conduzirão a evolução do sistema.

Exemplo 10

[Decisão Arquitetural 001] A arquitetura do SASF é dividida em três camadas lógicas: apresentação, lógica de negócio e persistência de dados. A camada de apresentação se comunica apenas com a lógica de negócio e apenas a lógica de negócio de comunica com a camada de persistência de dados.

Toda decisão é feita com um ou vários objetivos. Assim, a segunda característica trata de explicitar qual o objetivo de dada decisão, normalmente, permitindo ou restringido um conjunto de atributos de qualidade do sistema. Vale notar que, para atender aos atributos de qualidade do sistema (que podem ser muitos), uma arquitetura poderá possuir dezenas ou mesmo centenas de decisões arquiteturais.

Exemplo 11

(continuação da [Decisão Arquitetural 001]) Objetivo: Essa divisão diminui o acoplamento entre os elementos internos da arquitetura, facilitando o desenvolvimento e a manutenção. 4

Por fim, uma decisão arquitetural só pode ter sido alcançada em meio a alternativas com algum embasamento ou fundamentação. Então, cabe ao arquiteto explicitar por que tal decisão foi tomada, seja por ser um padrão conhecido na indústria, seja por conhecimento prévio de como satisfazer os objetivos em questão, ou pela atual decisão ter mostrado os melhores resultados em meio a uma avaliação prévia das alternativas.

Exemplo 12

(continuação da [Decisão Arquitetural 001]) Motivação: Projetar os elementos internos do sistema de modo que cada um pertença a apenas uma camada lógica ajuda a aumentar a coesão e diminuir o acoplamento. A coesão aumenta, pois cada elemento será desenvolvido com o objetivo de ser parte da apresentação, da lógica ou da persistência do sistema. Dessa maneira, cada elemento terá sua responsabilidade bem definida, mesmo que em alto nível. Como a comunicação entre as camadas é pré-definida, a de seus elementos também é: elementos da camada de apresentação não se comunicarão com elementos da camada de persistência, por exemplo. Assim, o acoplamento entre elementos internos será análogo ao acoplamento entre camadas. Com o baixo acoplamento, o desenvolvimento e a manutenção dos elementos também é facilitado, seja por possibilitar o desenvolvimento independente, seja por mudanças em um elemento terem menor impacto nos outros.

Rastreabilidade

Vale notar que decisões definem que elementos comporão o sistema. No exemplo anterior, podemos observar que a decisão define elementos como plug-ins, pontos de extensão, etc. Assim, por relacionarem atributos de qualidade (ou requisitos) a elementos arquiteturais, as decisões contidas numa arquitetura facilitam o chamado rastreamento de requisitos.

Definição 3: rastreamento de requisitos
É o processo/capacidade de ligar requisitos do sistema a estruturas arquiteturais.

A possibilidade de se rastrear requisitos na arquitetura é uma característica importante porque facilita o entendimento e a manutenção do sistema representado pela arquitetura. O entendimento do sistema é facilitado porque uma arquitetura permite que um interessado qualquer navegue pelos elementos que compõem o sistema em dois sentidos: tanto do nível mais abstrato do sistema para seus níveis mais concretos, ou seja, dos requisitos para os elementos arquiteturais, como módulos, bibliotecas, serviços, ou classes; quanto dos níveis concretos da arquitetura para os níveis mais abstratos, ou seja, dos elementos arquiteturais para os requisitos do sistema.

O entendimento do sistema é facilitado porque uma arquitetura permite que um interessado qualquer navegue pelos elementos que compõem o sistema em dois sentidos: tanto do nível mais abstrato do sistema para seus elementos mais concretos, ou seja, dos requisitos para as estruturas arquiteturais, como módulos, bibliotecas, serviços, ou classes, quanto dos elementos concretos da arquitetura para os níveis mais abstratos, ou seja, das estruturas arquiteturais para os requisitos do sistema.

Exemplo 13

Se observarmos a arquitetura do SASF e procurarmos pelas decisões responsáveis por facilitar a manutenção do sistema, encontraremos entre elas a decisão do Exemplo 12. Essa decisão sugere uma divisão do sistema em camadas lógicas, mas também influencia na divisão em pacotes, serviços ou mesmo processos. Assim, a satisfação do requisito de manutenibilidade está diretamente ligada à correta divisão das partes do sistema em apresentação, lógica de negócio e persistência.

Da mesma maneira, se partirmos das partes que formam as camadas de apresentação, lógica de negócio e persistência, observaremos que elas estão ligadas à divisão do sistema (e à decisão arquitetural) que se propõe a atender a requisitos de manutenibilidade.

Além de permitir a navegação, um aspecto que merece ser ressaltado é que se os requisitos do sistema forem eventualmente ordenados por importância para o sucesso do sistema, os elementos arquiteturais também possuirão diferentes níveis de importância. Essa ordenação, então, significará diferentes níveis de investimento, seja em tempo ou dinheiro, na construção dos elementos arquiteturais para o sucesso do sistema.

Adicionalmente, a manutenção do sistema é facilitada de uma forma análoga ao seu entendimento. Se algum requisito é atendido insatisfatoriamente, por meio da arquitetura é possível descobrir quais elementos do sistema estão envolvidos na insatisfação desses requisitos. Da mesma maneira, a arquitetura possibilita descobrir quais requisitos serão afetados por um dado elemento arquitetural caso esse sofra uma mudança ou manutenção.

Exemplo 14

Se uma modificação na camada de apresentação só pode ser feita se a camada de persistência também for modificada, isso pode significar que a decisão arquitetural do Exemplo 12 não está sendo seguida corretamente. Portanto, o requisito de manutenibilidade também não está sendo atendido corretamente e essa divergência da arquitetura deve ser corrigida o quanto antes.

Evolução

Devido às suas características, se torna fácil perceber que o registro das decisões arquiteturais na forma de um documento – o documento arquitetural – agrega valor ao ciclo de vida do software, uma vez que facilita o processo de rastreamento de requisitos. Adicionalmente, se algum tipo de registro histórico das decisões arquiteturais existir, o processo de rastreamento pode também ser realizado para as diversas versões do sistema, facilitando assim o entendimento da evolução do mesmo.

Além de descreverem estruturas arquiteturais, as decisões também descrevem princípios que conduzirão a evolução do sistema. Isso significa que uma decisão não necessariamente descreverá módulos, classes, ou serviços, mas também poderá descrever regras que deverão ser seguidas ao longo do desenvolvimento do sistema. A seguir, citamos e exemplificamos alguns tipos de regras a serem descritas pelas decisões arquiteturais.

  • Regras para adição de funcionalidade ao sistema.
    Exemplo 15

    Uma nova funcionalidade do SASF não poderá adicionar uma carga maior que mil requisições por segundo ao banco de dados de usuários, considerando a média atual de dez mil usuários simultâneos no sistema.

    Exemplo 16

    Uma nova funcionalidade de um editor de imagens só será adicionada implementando o ponto de extensão ProcessImagePlugin. Esse ponto de extensão permite obter a imagem que está aberta no workspace do usuário e seus atributos, além de permitir a exibição de uma caixa de diálogo que permitirá ao usuário entrar com parâmetros que servirão para a execução do plug-in. O retorno dessa nova funcionalidade sempre será uma imagem (processada ou não). A nova funcionalidade, para ser adicionada, deve conter um arquivo de configuração em texto sem formatação que conterá o atributo extension-class que indicará o caminho para a classe da nova funcionalidade que implementa ProcessImagePlugin.

    Exemplo 17

    Uma nova funcionalidade do sistema de edição de texto não poderá modificar a GUI de forma que adicione mais do que um botão na área de trabalho em sua configuração padrão.

  • Regras para remoção ou desativação de funcionalidades, seja durante o desenvolvimento, implantação, ou execução do sistema.
    Exemplo 18

    No SASF, a remoção de um serviço do módulo responsável pelo streaming para outros dispositivos será feita em duas etapas. Na primeira etapa, o serviço será marcado como deprecated, retornando assim, além da resposta padrão, uma flag avisando que na próxima versão ele será descontinuado. Será ainda disponibilizada uma solução que contorne a ausência desse serviço (serviços alternativos, por exemplo). Na segunda etapa, que deverá acontecer no mínimo 1 mês depois da primeira etapa, o serviço será desativado, retornando uma mensagem padrão de erro avisando que o serviço deixou de existir.

    Exemplo 19

    Caso o consumo de recursos computacionais do SASF ultrapasse 80% do total, alguns de seus serviços podem ser completamente ou parcialmente desativados. Um serviço que pode ser desativado temporariamente sem que os usuários percebam é o motor de sugestão de filmes. Como cada usuário está acostumado a ter sua lista de sugestões atualizada apenas “de tempos em tempos”, mas não tem certeza qual é o real intervalo entre cada atualização, se dada atualização demorar alguns minutos ou horas a mais para acontecer, dificilmente o atraso será notado. Em casos extremos, devido ao seu grande consumo de recursos, o serviço de streaming de vídeo também pode ser desativado. No entanto, essa decisão deve também levar em conta o alto grau de insatisfação de usuários que causará e que, fatalmente, poderá ser convertida em perda de faturamento. Uma alternativa é desativar a transmissão de vídeo para apenas algumas opções de resolução. Assim, o grau de insatisfação será menor, uma vez que apenas uma parte dos usuários não será atendida pelo serviço de streaming.

  • Regras para modificação ou manutenção de funcionalidades.
    Exemplo 20

    Não haverá modificação do Web Service que realiza busca e aluguel de filmes no SASF que é disponibilizado para uso por serviços externos. Se for realmente necessária a modificação, dois Web Services ficarão disponíveis: o antigo, completamente suportado, e o novo, que passará a ser adotado por novos sistemas a partir da data de seu lançamento. O antigo só será desativado depois da adoção do novo serviço ser feita por todos os serviços externos.

  • Regras de atendimento a atributos de qualidade.
    Exemplo 21

    No Exemplo 19, a disponibilidade de parte das funcionalidades, i.e., construção da lista de sugestões de filmes ou transmissão de vídeos, é mais importante do que a indisponibilidade de todas as funções: caso o uso dos recursos computacionais alcance 100%, usuários começarão a não ser atendidos de forma descontrolada. Assim, prefere-se que uma menor parte dos usuários não seja atendida, apenas os que desejam assistir a filmes em alta definição, do que a maior parte, que são os que desejam alugar filmes ou assisti-los em definição padrão.

    Exemplo 22

    A disponibilização de uma nova funcionalidade no SASF será feita em etapas para 10%, 25%, 50%, 100% desses usuários. Dessa maneira, será possível avaliar o comportamento da nova função no sistema sob carga real. Além disso, a desativação da funcionalidade poderá ser feita através de uma flag de controle, permitindo o retorno às funcionalidades anteriores do sistema em caso de sobrecarga dos recursos por parte da nova funcionalidade.

    Exemplo 23

    Antes da implantação de uma nova versão de um serviço de infraestrutura, digamos, um novo banco de dados, a carga gerada pelos usuários da versão antiga será espelhada para a nova versão. Assim, será possível avaliar seu comportamento com uma carga real e, portanto, saber o que esperar quando o novo banco de dados substituir a versão em produção.

No Capítulo XX, Documentação da Arquitetura, voltaremos às decisões arquiteturais, onde aprenderemos a categorizá-las e documentá-las.

Atributos de qualidade

Uma das principais preocupações da arquitetura é o atendimento aos atributos de qualidade do sistema. Atributos de qualidade, como já introduzidos no capítulo anterior, são a maneira como o sistema executará suas funcionalidades. Esses atributos são impostos pelos diversos interessados no sistema e podem ser classificados em três tipos: atributos do produto, atributos organizacionais, e atributos externos.

Atributos de qualidade do produto são aqueles que ditam como o sistema vai se comportar. Exemplos clássicos desse tipo de atributo de qualidade são escalabilidade, desempenho, disponibilidade, nível de entendimento ou mesmo portabilidade. Podemos observar requisitos de escalabilidade no Exemplo 24 e requisitos de portabilidade no Exemplo 25.

Exemplo 24

Sistemas de redes sociais costumam ter uma grande massa de usuários. Como, a partir do lançamento de um sistema desse tipo, sua massa de usuários cresce bastante, é desejável que o crescimento do consumo de recursos em relação ao crescimento do número de usuários não seja muito acentuado – de forma que a escala seja viável para a gerência do sistema. Para atender esse requisito, a arquitetura deve ser muito bem pensada em termos de consumo de recursos por usuário, tirando proveito de diversas técnicas como caching, processamento assíncrono, replicação, entre outras.

Exemplo 25

Um requisito desejável em um jogo de videogame é que ele esteja disponível para diversas plataformas de entretenimento. Como diferentes plataformas têm diferentes especificações ou ainda usam diferentes tipos de hardware, atingir a portabilidade pode não ser trivial. Entre as técnicas de portabilidade, a mais usada acaba sendo a abstração dos aspectos específicos à plataforma – principalmente o hardware, mais especificamente primitivas de desenho em tela ou armazenamento em disco – da lógica do jogo. Assim, toda ou boa parte da camada lógica é reusada, enquanto as camadas de níveis mais baixos de abstração são portadas para as diferentes plataformas.

Já atributos de qualidade organizacionais, por outro lado, são consequência de políticas ou procedimentos organizacionais. Em outras palavras, o sistema deve respeitar padrões ou regras impostas por uma ou mais organizações envolvidas para atender a esses requisitos.

Exemplo 26

Se um sistema que servirá de infraestrutura será produzido para uma organização ou empresa que já possui diversos sistemas que implementam o padrão Web Service Distributed Management (Gerência Distribuída de Web Services), a adoção desse padrão na arquitetura do novo sistema é um requisito a ser atendido, por ser imposto pela organização em questão. A adoção desse padrão implica na disponibilização via Web Service de serviços de ativação, consulta e desativação do sistema ou parte dele, que terá impacto na arquitetura do sistema como um todo.

Por fim, restam os chamados atributos de qualidade externos, que não são impostos pelo processo de desenvolvimento nem pelo projeto do sistema. Neles se encaixam leis impostas sobre software ou requisitos de interoperabilidade entre sistemas.

Exemplo 27

Para o SASF atrair usuários de outros sistemas (p. ex., redes sociais), percebeu-se que ele deve ser capaz de agregar o perfil do usuário existente nos outros sistemas. Esse tipo de agregação (que permitiria não só a visualização dos perfis compartilhados entre os diversos serviços, mas também sua edição), impactará profundamente na arquitetura do sistema, uma vez que será necessário organizar dados locais e dados compartilhados por terceiros, além de manter todos os dados sincronizados ao longo do tempo e das eventuais modificações.

Medindo atributos de qualidade

É importante notar que para se definir o sucesso do software em relação aos atributos de qualidade, precisamos medir o quanto o sistema satisfaz esses atributos. Em primeiro momento, essa medição de sucesso parece simples: “basta considerar o valor esperado do atributo de qualidade, digamos, `o sistema deve estar disponível 99,999% do tempo'; medir se ele atinge os valores esperados, `num período de 1 ano, o sistema esteve parado por 1 hora'; e, por fim, atestar seu sucesso ou fracasso: `1 hora equivale a 0,0114% e, portanto, o sistema não atendeu ao requisito de disponibilidade.”' No entanto, não é fácil estabelecer métricas quantitativas para atributos de qualidade como testabilidade, usabilidade, ou manutenibilidade são bem mais difíceis de estabelecer métricas quantitativas e, portanto, não é fácil atestar o sucesso em relação a esses atributos.

Relacionando atributos de qualidade

Além de serem difíceis de medir, atributos de qualidade se relacionam entre si de forma que um pode permitir, ajudar ou mesmo dificultar o atendimento de outros. Essas relações entre atributos acontecem mesmo que eles sejam de tipos diferentes.

No Exemplo 28, notamos que o atributo de qualidade desempenho está afetando os níveis de testabilidade e entendimento do sistema.

Exemplo 28

Uma forma de aumentar o desempenho do sistema é diminuir os níveis de indireção usados na comunicação entre dois elementos quaisquer no SASF. Um caso simples seria fazer com que algumas chamadas presentes na camada de apresentação usassem diretamente a camada de persistência, sem usar a lógica de negócio. Essa medida tornaria as chamadas da apresentação mais rápidas, uma vez que menos chamadas remotas seriam executadas. No entanto, quando diminuímos as camadas de abstração entre dois elementos inicialmente distintos, aumentamos o acoplamento entre eles e, portanto, dificultamos seu entendimento ou mesmo sua testabilidade.

Já no exemplo a seguir, o atributo de segurança afeta dois atributos distintos: o desempenho e a usabilidade do sistema.

Exemplo 29

Uma forma de aumentar a segurança de um sistema operacional é requerer autorização do usuário para a realização de certas operações. No entanto, o processo de verificação do usuário (além de todos os elementos e abstrações do sistema relacionados à segurança: unidade certificadora, unidade verificadora, listas de controle de acesso, entre outros.) deteriorará o desempenho da aplicação, dado que consumirá recursos que poderiam ser destinados à operação em si - não a um aspecto dito não-funcional dela. Além disso, o sistema vai ficar menos usável, uma vez que pedirá uma verificação, seja senha, impressão digital, ou certificado, para cada operação sensível a ser executada.

O principal motivo que faz com que atributos de qualidade conflitem é por eles serem impostos por mais de um interessado no software. Assim, como preocupações de diferentes interessados podem conflitar, os atributos de qualidade também conflitarão. Assim, cabe à arquitetura resolver, ponderar, ou ao menos mediar esses conflitos, considerando assim os diversos trade-offs envolvidos para se alcançar os objetivos do software. O exemplo seguinte mostra atributos de desempenho e portabilidade conflitando.

Exemplo 30

Um cliente de um jogo para celular requisitou que o jogo tivesse um bom desempenho nos diversos aparelhos disponíveis no mercado. No entanto, o gerente de projeto sugere que o tempo gasto para portar o software de um aparelho para outro seja mínimo, uma vez que o prazo do projeto em questão é curto. Podemos então observar dois requisitos conflitantes: desempenho e portabilidade.

Esse conflito ocorre porque as técnicas para alcançar ambos os requisitos são divergentes. Para alcançar portabilidade, normalmente é necessário o uso de diversas camadas de abstração, principalmente de hardware. No entanto, a adição dessas camadas de abstração significa uma perda em desempenho, uma vez que aumentará o número de chamadas necessárias para se realizar qualquer operação. E isso se torna ainda mais significativo no caso dos aparelhos celulares, que podem ser limitados em termos de recursos computacionais como processador ou memória.

Assim, a arquitetura do sistema terá que ponderar entre as técnicas disponíveis de modo que atenda em parte cada requisito e, assim, ambos os interessados fiquem satisfeitos.

Dois outros atributos de qualidade que normalmente conflitam são os atributos usabilidade e segurança, como veremos no exemplo a seguir. Nesse caso, ambos os atributos foram requisitados pelo mesmo interessado, o usuário, e, mesmo assim, se tornaram conflitantes.

Exemplo 31

Quando usando um sistema operacional, um mesmo usuário procura atributos de segurança e usabilidade para suas operações. Para segurança, ele deseja que suas operações no sistema ou seus resultados não sejam afetados por ações de outros usuários. Esse atributo, que na arquitetura implicará em soluções de autenticação, verificação, listas de permissões, etc., imporá que as tarefas realizadas por qualquer usuário eventualmente terão sua autenticidade e permissão verificadas. Essa interrupção para realizar as devidas autorizações deteriora o atendimento do atributo de usabilidade, uma vez que o usuário terá suas atividades interrompidas por algo que não gera resultado para ele.

Veremos mais sobre atributos de qualidade de software, suas relações, como alcançá-los, e seus interessados no Capítulo Y.

Visões da Arquitetura

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.

Exemplo 32

Considerando a arquitetura do SASF, vejamos as preocupações de dois interessados diferentes: o implementador e o responsável pela disponibilidade do sistema em produção. O implementador está preocupado com módulos, classes e algoritmos que ele e seu time terão que construir, como e com quais subsistemas esses módulos irão se comunicar ou ainda quais restrições de comunicação foram impostas em seu design. Já o responsável pela disponibilidade está preocupado em como o SASF está distribuído entre as máquinas, que funcionalidades serão afetadas caso um conjunto específico de máquinas deixe de funcionar, ou como será possível realizar a troca de um servidor sem afetar o tempo de início de uma transmissão de vídeo.

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.

O Documento de Arquitetura

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.

Benefícios

Um documento de arquitetura não é nada mais que um documento que descreve a arquitetura do sistema e, portanto, descreve elementos, relações, e decisões arquiteturais do sistema em questão. Assim, os benefícios de se documentar a arquitetura se tornam análogos aos benefícios proporcionados pela própria arquitetura. No entanto, pelo documento de arquitetura ser um artefato concreto, ele poderá ser reproduzido, reusado, comunicado e analisado contra o código gerado a partir da arquitetura em questão.

Em resumo, a documentação da arquitetura proporcionará os seguintes benefícios:

  • Ajudará na introdução de novos membros ao time de desenvolvimento do sistema, uma vez que é um documento que abstrai o sistema a diferentes visões que representam diferentes preocupações;

    Exemplo 33

    Um novo desenvolvedor acabou de ser contratado e passou a integrar o time de desenvolvimento de um sistema que já soma 250 mil linhas de código. Para esse desenvolvedor se familiarizar com o sistema, não é uma boa idéia para ele mergulhar no código de cabeça, mas entender por partes como as coisas funcionam. Esses diversos níveis de abstração até chegar ao código propriamente dito devem estar disponíveis na arquitetura do sistema, que se mostrará um bom ponto de partida para o entendimento do sistema.

  • Servirá de ponte para a comunicação entre os diversos interessados do sistema. Uma vez que a arquitetura é projetada para satisfazer diversos interessados, sua documentação também o será. O documento de arquitetura servirá de arcabouço conceitual para comunicação entre diferentes interessados no sistema, uma vez que define seus elementos e relações que o compõem.

    Exemplo 34

    Usando a arquitetura para mapear custos às funcionalidades que o sistema proverá, o gerente pode justificar ao financiador do projeto a necessidade de se adquirir uma licença para um banco de dados específico. Ou ainda citar quais as consequências caso essa licença não seja adquirida: a funcionalidade provida pelo banco deverá ser então implementada pelo time de desenvolvimento, que precisará de dois meses para tanto. Essa possibilidade de “navegar” pelo sistema e pelas diversas visões, seja a de gerente, seja a de financiador, ou de desenvolvedor, é facilitada pelo documento de arquitetura.

  • Servirá como modelo do sistema para a análise. Uma vez que é uma representação manipulável do sistema, a documentação poderá ser analisada, desde que contenha informação suficiente para tanto.

    Exemplo 35

    A arquitetura do SASF, dividido em três camadas (apresentação, lógica de negócio e persistência), descreve que cada camada estará executando em máquinas diferentes. É certo que a descrição de cada camada possui informações de quantas máquinas serão necessárias para determinada carga de usuários, como máquinas da mesma camada se comunicarão e também como elas se comunicarão com máquinas de diferentes camadas. Assim, com essas informações, é possível algum tipo de análise e estimativa do custo do sistema em produção (e.g., número de CPUs por hora, banda passante entre as máquinas, ou banda passante disponível para os usuários), inclusive com base no crescimento do número de usuários, mesmo que o sistema ainda não tenha sido construído.

  • Dificultará uma especificação imprecisa. Quando o arquiteto projeta a arquitetura, mas não a materializa em um documento, pode haver pontos de discordância que eventualmente não serão avaliados por, simplesmente, não estarem explícitos.

    Exemplo 36

    Num sistema de controle de vôo, onde vidas estão em risco, o documento da arquitetura é também um contrato. Ele é avaliado por cada interessado em questão, que deve consentir com a forma de como serão realizadas as funções do sistema e como serão medidos seus atributos de qualidade de forma a garantir o sucesso do sistema antes mesmo que esse seja construído.

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
Figura 5 (visaoestatica.png)

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.
Figura 6 (visaodinamica.png)

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.

Por que documentar a arquitetura de software?

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.

Exemplo 39

Pensemos num pequeno sistema que servirá para a organização de uma modesta locadora de filmes. Ele será capaz de cadastrar, recuperar, atualizar e remover filmes, cadastrar, recuperar, atualizar e remover DVDs de filmes, cadastrar, recuperar, atualizar e remover clientes, realizar locações, devoluções e reservas.

Se a execução desse sistema estiver restrita apenas a uma única loja física, seus requisitos serão simples o suficiente para nem precisarmos de uma documentação abrangente (ou mesmo precisar de qualquer documentação!): ele será desktop, terá apenas um usuário atuando sobre o sistema, sua carga, por ter apenas um usuário, será baixíssima, além dos dados armazenados no sistema, que por maior que seja a loja, não chegará a limites intratáveis por um sistema simples. Podemos observar que um sistema com esses requisitos pode ser desenvolvido e mantido até por um programador menos experiente.

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.

Exemplo 40

O sistema de locadora agora tem que servir para mais duas filiais. Assim, o sistema deve estar rodando nas três lojas e deve existir um cadastro único de novos filmes, novos DVDs e novos clientes, e tanto a locação quanto a devolução podem ser feitas em qualquer loja da rede de locadoras. O sistema se torna multiusuário, por agora mais de um balconista usá-lo ao mesmo tempo, e distribuído, por ter que manter seu estado consistente entre as diversas lojas físicas existentes. Surgem agora preocupações de desempenho, tolerância a falhas e backup e consistência de dados. Outras dúvidas também surgem: Será um banco de dados central para as três lojas? Será um banco distribuído? Se for central, o que fazer caso não seja possível se comunicar com ele? Se for distribuído, como manter a consistência entre os dados? Um balconista de uma loja pode acessar o sistema de outra loja? O que um balconista de uma loja tem permissão para fazer na instância do sistema executando em outra loja? A reserva de um filme está restrita a uma loja física, ou será válida para todas? E assim por diante.

Assim, podemos perceber que uma simples visão de decomposição de classes deixa de ser o único artefato necessário para entender o sistema. Precisamos agora de um artefato que represente os estados do sistema durante a execução, seja em condições normais de operação (e.g., como funciona o procedimento de reserva de filmes entre as lojas da rede de locadoras) , ou seja quando surgem problemas (e.g., o link de comunicação entre as lojas caiu), apenas para exemplificar algumas poucas preocupações.

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.

Exemplo 41

A organização interna do SASF mudará ainda mais em relação aos Exemplo 39 e Exemplo 40. As decisões que antes permitiam que o sistema rodasse para as três lojas numa mesma cidade não serão mais válidas quando falamos de diversos pontos de distribuição espalhados pelo país.

Dessa maneira, observamos que as decisões de desempenho, disponibilidade dos dados, e políticas de acesso mudam e, como aumentam também em quantidade, se torna mais evidente a necessidade do registro dessas decisões em algum tipo de documento para consulta, resolução de discussões e verificação de conformidade.

Adicionalmente, num sistema como o SASF, o número de interessados aumenta: desde o usuário que deve entender quais tipos de locação e reserva estão disponíveis, passando pelos responsáveis pelo suporte ao usuário, os responsáveis pela disponibilidade dos diversos subsistemas (aluguel, streaming, dados, backup, etc.), gerente de marketing, time de desenvolvimento, gerente de projeto, gerente da empresa. Aumentando assim a responsabilidade de se obter um sistema capaz de satisfazer a todos eles.

Cada um terá um conjunto diferente de preocupações sobre o sistema. Seja o responsável por manter o sistema no ar, que precisa saber quantos recursos estão sendo consumidos a cada momento; seja o time de implementação, que precisa descobrir como adicionar uma nova funcionalidade sem quebrar as anteriores; seja o gerente do projeto, que deve decidir por contratar mais desenvolvedores para implementação ou comprar soluções prontas.

Cada um desses estará preocupado também com qualidades diferentes do sistema: o responsável pela disponibilidade do sistema quer saber como o sistema escala se a base de usuários duplicar; já o time de implementação está preocupado em deixar o sistema mais testável para que a implementação da nova funcionalidade seja mais fácil; e, por outro lado, o gerente quer saber o desenvolvimento do sistema é possível com um time de desenvolvedores menor que o atual.

Essas preocupações serão endereçadas pelo documento de arquitetura do SASF, que contém diversas visões direcionadas às diversas preocupações dos interessados. Uma visão de implementação interessará ao responsável pela disponibilidade, assim como uma visão de decomposição interessará ao time de desenvolvimento, assim como uma visão de implementação interessará ao gerente do projeto, fazendo então que o documento de arquitetura possua diversas visões e se torne um documento complexo.

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.

Resumo

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:

  • entenda e exemplifique os principais conceitos relacionados à arquitetura de software; e
  • entenda e exemplifique as principais características e benefícios proporcionados pela arquitetura de software no processo de desenvolvimento.

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.

Referências

Histórico da área

Apesar da ênfase em Arquitetura de Software como disciplina ter acontecido apenas durante a década de 1990 com autores a exemplo de Perry e Wolf [20] e Garlan e Shaw [12], podemos encontrar trabalhos das décadas de 1960 e 1970 que já citam algumas técnicas e benefícios da área. Entre eles, encontramos Dijkstra [6], Parnas [18] e outros. Mais informações sobre o histórico da disciplina podem ser vistas em The Past, Present, and Future for Software Architecture, de Kruchten, Obbink e Stafford [15].

Evolução de software

A evolução de Software é bem estudada no livro editado por Mens e Demeyer, Software Evolution [17] e nos trabalhos de Parnas [19], van Gurp e Bosch [23] e Eick et al [7]. Mais informações sobre a Big Ball of Mud podem ser encontradas em Foote e Yoder [9].

Elementos de uma arquitetura

A divisão dos elementos arquiteturais em estáticos e dinâmicos é feita originalmente por Rozanski e Woods em Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives [21]. Já a discussão sobre classificação dos atributos de qualidade pode ser encontrada no livro Software Engineering, de Sommerville [22]. Por fim, podemos citar algumas referências importantes sobre visões arquiteturais: The 4+1 View Model of Architecture de Kruchten [16], Documenting Software Architectures: Views and Beyond Clements de Clements et al [5] e o padrão ISO/IEEE 1471-2000 [13].

Footnotes

  1. Trataremos melhor desse assunto no capítulo sobre atributos de qualidade
  2. Java Database Connectivity. http://java.sun.com/javase/technologies/database/
  3. REpresentational State Transfer [8]
  4. TODO: Adicionar os drivers dessa decisão: o Requisito(s) Não-Funcional(is) XX presente(s) no Apêndice. Exemplo de requisito: [RNF 01] Ter mais de uma interface gráfica.

References

  1. Andy, and Qian, Kai. (2005, March). Component-Oriented Programming. Wiley-Interscience.
  2. Bass, Len and Clements, Paul and Kazman, Rick. (2003, April). Software Architecture in Practice, Second Edition. Addison-Wesley Professional.
  3. Bass, Len and Clements, Paul and Kazman, Rick. (1998). Software Architecture in Practice. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc.
  4. Buxton, J. N. and Randell, B. (1970, April). Software Engineering Techniques. Technical report. Rome, Italy: NATO Science Committee.
  5. Clements, Paul and Bachmann, Felix and Bass, Len and Garlan, David and Ivers, James and Little, Reed and Nord, Robert and Stafford, Judith. (2002, September). Documenting Software Architectures: Views and Beyond. Addison-Wesley Professional.
  6. Dijkstra, Edsger W. (1968). The structure of the THE-multiprogramming system. Commun. ACM, 11(5), 341–346.
  7. Eick, S. G. and Graves, T. L. and Karr, A. F. and Marron, J. S. and Mockus, A. (2001). Does code decay? Assessing the evidence from change management data. Software Engineering, IEEE Transactions on, 27(1), 1–12.
  8. Fielding, Roy T. (2000). Architectural Styles and the Design of Network-based Software Architectures. Ph. D. Thesis. University of California, Irvine.
  9. Foote, Brian and Yoder, Joseph W. (2000). Big Ball of Mud. In Pattern Languages of Program Design. (Vol. 4, p. 654–692). Addison Wesley.
  10. Gorton, Ian. (2006, June). Essential Software Architecture. Springer.
  11. Garlan, David and Shaw, Mary. (1994). An Introduction to Software Architecture. Technical report. Pittsburgh, PA, USA
  12. Garlan, David and Shaw, Mary. (1994, January). An Introduction to Software Architecture. (CMU-CS-94-166). Technical report. Pittsburgh, PA 15213-3890: Carnegie Mellon University.
  13. IEEE, and ISO/IEC,. (2007, July). Systems and Software Engineering - Recommended Practice for Architectural Description of Software-Intensive Systems. ISO/IEC 42010 IEEE Std 1471-2000 First edition 2007-07-15, c1–24.
  14. (1991). IEEE Standard Computer Dictionary: Compilation of IEEE Standard Computer Glossaries. Institute of Electrical and Electronics Engineers Inc., The.
  15. Kruchten, P. and Obbink, H. and Stafford, J. (2006). The Past, Present, and Future for Software Architecture. Software, IEEE, 23(2), 22–30.
  16. Kruchten, P. B. (1995). The 4+1 View Model of architecture. Software, IEEE, 12(6), 42–50.
  17. (2008, March). Software Evolution. Springer.
  18. Parnas, D. L. (1979). On the criteria to be used in decomposing systems into modules. Classics in Software Engineering, 139–150.
  19. Parnas, David L. (1994). Software aging. In ICSE '94: Proceedings of the 16th international conference on Software engineering. (p. 279–287). Los Alamitos, CA, USA: IEEE Computer Society Press.
  20. Perry, Dewayne E. and Wolf, Alexander L. (1992, October). Foundations for The Study of Software Architecture. SIGSOFT Software Engineering Notes, 17(4), 40–52.
  21. Rozanski, Nick and Woods, Eóin. (2005, April). Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives. Addison-Wesley Professional.
  22. Sommerville, Ian. (2004, May). Software Engineering (7th Edition) (International Computer Science Series). Addison Wesley.
  23. van Gurp, Jilles and Bosch, Jan. (2002, March). Design erosion: problems and causes. Journal of Systems and Software, 61(2), 105–119.

Collection Navigation

Content actions

Download:

Collection as:

PDF | EPUB (?)

What is an EPUB file?

EPUB is an electronic book format that can be read on a variety of mobile devices.

Downloading to a reading device

For detailed instructions on how to download this content's EPUB to your specific device, click the "(?)" link.

| More downloads ...

Module as:

PDF | More downloads ...

Add:

Collection to:

My Favorites (?)

'My Favorites' is a special kind of lens which you can use to bookmark modules and collections. 'My Favorites' can only be seen by you, and collections saved in 'My Favorites' can remember the last module you were on. You need an account to use 'My Favorites'.

| A lens I own (?)

Definition of a lens

Lenses

A lens is a custom view of the content in the repository. You can think of it as a fancy kind of list that will let you see content through the eyes of organizations and people you trust.

What is in a lens?

Lens makers point to materials (modules and collections), creating a guide that includes their own comments and descriptive tags about the content.

Who can create a lens?

Any individual member, a community, or a respected organization.

What are tags? tag icon

Tags are descriptors added by lens makers to help label content, attaching a vocabulary that is meaningful in the context of the lens.

| External bookmarks

Module to:

My Favorites (?)

'My Favorites' is a special kind of lens which you can use to bookmark modules and collections. 'My Favorites' can only be seen by you, and collections saved in 'My Favorites' can remember the last module you were on. You need an account to use 'My Favorites'.

| A lens I own (?)

Definition of a lens

Lenses

A lens is a custom view of the content in the repository. You can think of it as a fancy kind of list that will let you see content through the eyes of organizations and people you trust.

What is in a lens?

Lens makers point to materials (modules and collections), creating a guide that includes their own comments and descriptive tags about the content.

Who can create a lens?

Any individual member, a community, or a respected organization.

What are tags? tag icon

Tags are descriptors added by lens makers to help label content, attaching a vocabulary that is meaningful in the context of the lens.

| External bookmarks