Tag: dev

Página 76

Características Operacionais da Arquitetura

As características operacionais da arquitetura envolvem capacidades como desempenho, escalabilidade, elasticidade, disponibilidade e confiabilidade. O Quadro 4-1 lista algumas delas.

Quadro 4-1. Características operacionais comuns da arquitetura Termo Definição DisponibilidadePor quanto tempo o sistema precisa ficar disponível (se for 24/7, é preciso ter etapas para permitir que o sistema fique ativo rápido no caso de qualquer falha).

ContinuidadeCapacidade de recuperação de desastres.

DesempenhoInclui teste de estresse, análise de pico, análise da frequência das funções usadas, capacidade requerida e tempos de resposta. Por vezes, a aceitação do desempenho requer um exercício próprio, levando meses para concluir.

Recuperabilida de Requisitos de continuidade do negócio (por exemplo, no caso de desastres, com que rapidez o sistema precisa ficar online de novo?). Isso afetará a estratégia de backup e os requisitos para o hardware duplicado.

Confiabilidade/ segurança Avalia se o sistema precisa ser à prova de falhas ou se tem uma missão crítica no modo como afeta a vida das pessoas. Se ele falha, custará muito dinheiro para a empresa?

Robustez A capacidade de lidar com condições de erro e limites durante a execução, caso a conexão de internet caia ou se há falta de energia ou falha no hardware.

EscalabilidadeA capacidade de o sistema rodar e operar quando o número de usuários ou requisições aumenta.

As características operacionais da arquitetura têm uma sopreposição significativa com as preocupações de operações e DevOps, formando a interseção dessas questões em muitos projetos de software.

Características Estruturais da Arquitetura

Os arquitetos devem se preocupar com a estrutura do código. Em muitos casos, o arquiteto tem uma responsabilidade única ou compartilhada pelas questões de qualidade do código, como boa modularidade, acoplamento controlado entre os componentes, código legível e muitas outras avaliações internas da qualidade. O Quadro 4-2 lista algumas características estruturais da arquitetura.

Quadro 4-2. Características estruturais da arquitetura Termo Definição Configuração A capacidade dos usuários finais de mudar com facilidade os aspectos de configuração do software (com interfaces úteis).

Extensão Como é importante ligar as novas partes da funcionalidade.

Instabilidade Facilidade de instalação do sistema em todas as plataformas necessárias.

Aproveitamento/ reutilização Capacidade de aproveitar os componentes comuns em vários produtos.

Localização Suporte para vários idiomas nas telas de entrada/consulta nos campos de dados; nos relatórios, requisitos de caracteres multibytes e unidades de medidas ou moedas.

Manutenção Quão facilmente aplica as alterações e melhora o sistema?

Portabilidade O sistema precisa rodar em mais de uma plataforma? (Por exemplo, o front-end precisa rodar no Oracle e no banco de dados SAP?) Suporte De qual nível de suporte técnico a aplicação precisa? Qual nível de registro e outras facilidades são requeridos para depurar os erros no sistema?

Atualização A capacidade de atualizar com facilidade/rapidez uma versão prévia dessa aplicação/solução para uma versão mais nova nos servidores e nos clientes.

Características Transversais da Arquitetura

Página 77

Embora muitas características da arquitetura se classifiquem em categorias fáceis de reconhecer, muitas estão fora ou desafiam a categorização, formando importantes restrições de design e considerações. O Quadro 4-3 descreve algumas.

Quadro 4-3. Características Transversais da Arquitetura Termo Definição AcessibilidadeAcesso a todos os usuários, inclusive com deficiências, como daltonismo e perda auditiva.

Armazenamen to Os dados precisarão ser armazenados ou excluídos após um período de tempo? (Por exemplo, as contas do cliente serão excluídas após três meses ou marcadas como obsoletas e armazenadas em um banco de dados secundário para futuro acesso.) AutenticaçãoRequisitos de segurança para assegurar que os usuários são quem dizem ser.

AutorizaçãoRequisitos de segurança para assegurar que os usuários possam acessar apenas certas funções na aplicação (por caso de uso, subsistema, página web, regra comercial, nível do campo etc.).

LegalidadeCom quais restrições legais o sistema opera (proteção de dados, Sarbanes Oxley, GDPR etc.)? Quais direitos de reserva a empresa requer? Alguma regulação no modo como a aplicação será criada ou implantada?

PrivacidadeA capacidade de ocultar as transações dos funcionários internos da empresa (transações criptografadas para que até os DBAs e os arquitetos de rede não possam vê-las).

Segurança Os dados precisam ser criptografados no banco de dados? Criptografados para a comunicação de rede entre os sistemas internos? Qual tipo de autenticação precisa existir para o acesso remoto do usuário?

Suporte De qual nível de suporte técnico a aplicação precisa? Qual nível de registro e outras facilidades são necessários para depurar os erros no sistema?

Usabilidade/ viabilidade O nível de treinamento requerido para os usuários atingirem seus objetivos com a aplicação/solução. Os requisitos de utilização precisam ser tratados com a mesma seriedade de qualquer outra questão arquitetural.

Qualquer lista de características da arquitetura será necessariamente incompleta; qualquer software pode inventar características importantes com base em fatores únicos (veja “Como na Itália” para ter um exemplo).

Como na Itália Uma das colegas de Neal conta uma história sobre a natureza única das características da arquitetura. Ela trabalhou para um cliente cuja missão requeria uma arquitetura centralizada. Contudo, para cada design proposto, a primeira pergunta do cliente era “Mas o que acontece se perdemos a Itália?” Anos atrás, devido a uma interrupção da comunicação anormal, a matriz perdeu contato com as filiais italianas e foi traumático para a organização. Assim, uma exigência severa de todas as futuras arquiteturas insistia no que a equipe acabou chamando de Como na Itália (Italyility), que todos sabiam significar uma combinação única de disponibilidade, recuperabilidade e resiliência.

E mais, muitos termos anteriores são imprecisos e ambíguos, às vezes por causa de uma nuança sutil ou falta de definições objetivas. Por exemplo, interoperabilidade e compatibilidade podem parecer equivalentes, o que será verdade para alguns sistemas. Porém, diferem porque interoperabilidade implica a facilidade de integração com outros sistemas, que por sua vez implica em APIs publicadas e documentadas. Já a compatibilidade se preocupa mais com os padrões do setor e do domínio. Outro exemplo é o aprendizado. Uma definição seria a facilidade de os usuários aprenderem a usar o software e outra seria o nível no qual o sistema pode aprender automaticamente sobre seu ambiente para se tornar autoconfigurado ou autootimizado usando algoritmos de aprendizado de máquina.

Muitas definições se sobrepõem. Por exemplo, considere a disponibilidade e a confiabilidade, que parecem se sobrepor em quase todos os casos. Considere ainda os protocolos de internet UDP e TCP. O UDP está disponível no IP, mas não é confiável: os pacotes podem chegar fora de ordem, e o destinatário pode ter que pedir novamente os pacotes que faltam.

Página 78

Não existe uma lista completa de padrões. A Organização Internacional para Padronização (ISO) publica uma lista organizada por capacidades, sobrepondo muitas que listamos, mas estabelecendo principalmente uma lista de categorias incompleta. Veja a seguir algumas definições ISO:

Eficiência do desempenho Medida do desempenho relativo à quantidade de recursos usados sob condições conhecidas. Isso inclui o comportamento temporal (medida da resposta, tempos de processamento e/ou taxas de transferência), utilização do recurso (quantidades e tipos de recursos usados) e capacidade (o grau no qual os limites máximos estabelecidas são excedidos).

Compatibilidade O grau no qual um produto, um sistema ou um componente pode trocar informações com outros produtos, sistemas ou componentes e/ou realizar suas funções requeridas compartilhando o mesmo ambiente de hardware ou software. Inclui a coexistência (pode realizar suas funções requeridas com eficiência compartilhando um ambiente em comum e recursos com outros produtos) e interoperabilidade (o grau no qual dois ou mais sistemas podem trocar e utilizar informações).

Usabilidade Os usuários podem usar o sistema com eficiência e satisfação com sua finalidade pretendida. Inclui o reconhecimento da adequação (os usuários podem reconhecer se o software é adequado para suas necessidades), aprendizado (com que facilidade os usuários podem aprender a usar o software), proteção contra erros do usuário (proteção contra usuários que cometem erros) e acessibilidade (disponibilizar o software para pessoas com a maior variedade de características e capacidades).

Confiabilidade O grau no qual um sistema funciona sob condições específicas por certo período de tempo. Essa característica inclui subcategorias como maturidade (o software atende às necessidades de confiabilidade em uma operação normal), disponibilidade (o software é operacional e acessível), tolerância a falhas (o software opera como o pretendido, apesar de falhas no hardware ou no software) e recuperabilidade (o software pode se recuperar da falha recuperando qualquer dado afetado e restabelecendo o estado desejado do sistema).

Segurança O grau no qual o software protege as informações e os dados para que as pessoas, os produtos ou os sistemas tenham o grau de acesso dos dados adequado a seus tipos e níveis de autorização. Essas características incluem confidencialidade (os dados são acessíveis apenas por pessoas autorizadas), integridade (o software impede o acesso não autorizado ou a modificação do software ou dos dados), não repúdio (as ações ou os eventos podem comprovar que ocorreram), responsabilização (as ações de um usuário podem ser rastreadas) e autenticidade (comprovar a identidade de um usuário).

Manutenibilidade Representa o grau da eficiência com a qual os desenvolvedores podem modificar o software para melhorá-lo, corrigi-lo ou adaptá-lo às mudanças no ambiente e/ou nos

Página 79

requisitos. Essa característica inclui modularidade (o grau no qual o software é composto por componentes distintos), reusabilidade (o grau no qual os desenvolvedores podem usar um recurso em mais de um sistema ou ao criar outros recursos), análise (com que facilidade os desenvolvedores podem coletar métricas concretas sobre o software), modificação (o grau no qual os desenvolvedores podem modificar o software sem introduzir defeitos ou diminuir a qualidade do produto existente) e testabilidade (com que facilidade os desenvolvedores e outras pessoas podem testar o software).

Portabilidade O grau no qual os desenvolvedores podem transferir um sistema, um produto ou um componente de um hardware, um software ou outro ambiente operacional ou de uso para outro. Essa característica inclui as características secundárias de adaptação (os desenvolvedores podem adaptar com eficiência o software para um hardware, um software diferente ou em desenvolvimento ou outros ambientes operacionais ou de uso), instabilidade (o software pode ser instalado e/ou desinstalado em um ambiente específico) e substituição (com que facilidade os desenvolvedores podem substituir a funcionalidade por outro software).

O último item na lista ISO lida com os aspectos funcionais do software, que não acreditamos pertencer à lista:

Adequação funcional Essa característica representa o grau no qual um produto ou um sistema fornece funções que atendem as necessidades declaradas e implícitas quando usado sob certas condições.

A característica é composta pelas seguintes características secundárias:

Totalidade funcional O grau no qual o conjunto de funções cobre todas as tarefas especificadas e objetivos do usuário.

Correção funcional O grau no qual um produto ou um sistema fornece resultados corretos com o grau de precisão necessário.

Adequação funcional O grau no qual as funções facilitam a realização de tarefas e objetivos específicos. Não são as características da arquitetura, mas os requisitos motivacionais para criar o software. Isso mostra como evoluiu o pensamento sobre a relação entre as características da arquitetura e o domínio do problema. Vemos essa evolução no Capítulo 7.

Página 80

As Muitas Ambiguidades na Arquitetura do Software Uma frustração constante entre os arquitetos é a falta de definições claras de muitas coisas essenciais, inclusive da atividade da arquitetura do software em si! Isso leva as empresas a definirem seus próprios termos para coisas comuns, confundindo todo o setor porque os arquitetos usam termos obscuros ou, pior ainda, usam os mesmos termos para significados muito diferentes. Por mais que queiramos, não podemos impor uma nomenclatura padrão no mundo do desenvolvimento de software. Contudo, seguimos e recomendamos a orientação do design orientado a domínio (DDD) para estabelecer e usar uma linguagem universal entre os colegas de trabalho para ajudar a ter menos equívocos com os termos.

Trade-offs e Arquitetura Menos Pior

As aplicações suportam apenas algumas características da arquitetura que listamos por vários motivos. Primeiro, cada característica com suporte requer um esforço de design e, talvez, um suporte estrutural. Segundo, o maior problema está no fato de que cada característica costuma ter um impacto nas outras. Por exemplo, se um arquiteto deseja melhorar a segurança, é quase certo que terá um impacto negativo no desempenho: a aplicação deve aplicar mais criptografia em tempo real, indireção para ocultar segredos e outras atividades que diminuem potencialmente o desempenho.

Uma metáfora ajudará a mostrar a interconectividade. Aparentemente, os pilotos sempre tentam aprender a pilotar helicópteros porque ele requer um controle para cada mão e pé, e mudar um deles impacta os outros. Assim, pilotar um helicóptero é um exercício de equilíbrio, que descreve bem o processo de trade-off ao escolher as características da arquitetura. Para cada característica em que o arquiteto projeta um suporte, possivelmente teremos uma complicação do design em geral.

Assim, raramente os arquitetos encontram uma situação em que conseguem projetar um sistema e maximizar toda característica da arquitetura. Muitas vezes, as decisões se resumem às compensações entre várias questões em conflito.

Nunca mire na melhor arquitetura, mas na arquitetura menos pior.

Características excessivas da arquitetura levam a soluções genéricas que tentam resolver todo problema de negócio e essas arquiteturas raramente funcionam porque fica difícil de lidar com o design.

Isso sugere que os arquitetos devem projetar a arquitetura como sendo a mais iterativa possível.

Se você conseguir fazer mudanças na arquitetura com mais facilidade, poderá se estressar menos descobrindo a coisa correta e exata na primeira tentativa. Uma das lições mais importantes do desenvolvimento ágil de software é o valor da iteração; isso vale para todos os níveis de desenvolvimento do software, inclusive a arquitetura.

Página 81

5. Identificando as Características da Arquitetura

CAPÍTULO 5 Identificando as Características da Arquitetura Identificar as características que movem a arquitetura é um dos primeiros passos para criar uma arquitetura ou determinar a validade de uma existente. Identificar as características (“- ilidades”) corretas da arquitetura para certo problema ou aplicação requer que um arquiteto não entenda apenas o domínio do problema, mas também colabore com stakeholders para determinar o que é realmente importante da perspectiva do domínio.

Um arquiteto descobre as características da arquitetura pelo menos de três modos extraindo das preocupações, dos requisitos e do conhecimento implícito do domínio. Anteriormente, examinamos características implícitas e trataremos de outras duas aqui.

Extraindo Características da Arquitetura das Preocupações do Domínio

Um arquiteto deve conseguir traduzir as preocupações do domínio para identificar as características certas da arquitetura. Por exemplo, a escalabilidade é a preocupação mais importante ou é a tolerância a falhas, segurança ou desempenho? Talvez o sistema requeira as quatro características combinadas. Entender os principais objetivos e a situação do domínio permite a um arquiteto traduzir essas preocupações do domínio em “atributos”, que então formam a base para decisões de arquitetura corretas e justificáveis.

Uma dica ao colaborar com os stakeholders do domínio para definir as características da arquitetura orientadoras é trabalhar muito para manter a menor lista final possível. Um antipadrão comum na arquitetura envolve tentar planejar uma arquitetura genérica, com suporte para todas as características da arquitetura. Cada característica que a arquitetura suporta complica o design geral do sistema; dar suporte a características demais leva a uma complexidade cada vez maior antes de os arquitetos e os desenvolvedores começarem a lidar com o domínio do problema, a motivação original para escrever o software. Não fique muito obcecado com a quantidade de características, mas tenha motivação para manter o design simples.

Estudo de Caso: Vasa A história original das características da arquitetura especificadas em excesso, que acabou encerrando um projeto, deve ser o Vasa. Foi um navio de guerra sueco construído entre 1626 e 1628 por um rei que queria a embarcação mais impressionante criada. Até aquela época, as embarcações eram transportes de tropas ou navios de artilharia; o Vasa seria os dois! A maioria das embarcações tinha um deque, o Vasa tinha dois! Todos os canhões tinham duas vezes o tamanho em comparação com embarcações parecidas. Apesar de certo temor dos construtores especialistas (que não podiam dizer “não” para o rei Adolfo), eles finalizaram o navio. Na comemoração, a embarcação navegou no porto e disparou uma salva de canhão pela lateral. Infelizmente, como era muito pesada, virou e afundou na baía. No início do século XX, equipes de salvamento resgataram a embarcação, que agora está em um museu em Estocolmo.

Página 82

Muitos arquitetos e stakeholders do domínio querem priorizar a lista final das características da arquitetura que a aplicação ou o sistema deve usar. Embora seja muito desejável, na maioria dos casos é um disparate e não só será uma perda de tempo, como também gerará uma frustração e desacordos desnecessários com os principais stakeholders. É raro que todos eles concordem com a prioridade de cada característica. Uma abordagem melhor é pedir que eles selecionem as três características mais importantes na lista final (em qualquer ordem). Não apenas é muito mais fácil para chegar ao consenso, como também favorece debates sobre o que é mais importante e ajuda o arquiteto a analisar as concessões ao tomar decisões vitais da arquitetura.

A maioria das características da arquitetura vem de ouvir os principais stakeholders do domínio e colabor com eles para determinar o que é importante da perspectiva do domínio. Embora pareça uma atividade simples, o problema é que arquitetos e stakeholders do domínio falam línguas diferentes. Os arquitetos falam sobre escalabilidade, interoperabilidade, tolerância a falhas, aprendizado e disponibilidade. Os stakeholders do domínio falam sobre fusões e aquisições, satisfação do usuário, tempo de lançamento no mercado e vantagem competitiva. O que acontece é um problema de “perda na tradução”, em que o arquiteto e o stakeholder do domínio não se entendem. Os arquitetos não têm ideia de como criar uma arquitetura para dar suporte à satisfação do usuário e os stakeholders do domínio não entendem por que focar tanto e falar sobre disponibilidade, interoperabilidade, aprendizado e tolerância a falhas na aplicação.

Por sorte, costuma haver uma tradução das preocupações de domínio para as características da arquitetura. O Quadro 5-1 mostra algumas preocupações do domínio mais comuns e os “atributos” correspondentes que dão suporte a elas.

Quadro 5-1. Tradução das preocupações de domínio nas características da arquitetura Preocupação do domínio Características da arquitetura Fusões e aquisições Interoperabilidade, escalabilidade, adaptabilidade, extensibilidade Lançamento no mercado Agilidade, testabilidade, implementabilidade Satisfação do usuário Desempenho, disponibilidade, tolerância a falhas, testabilidade, implementabilidade, agilidade, segurança Vantagem competitiva Agilidade, testabilidade, implementabilidade, escalabilidade, disponibilidade, tolerância a falhas Tempo e orçamento Simplicidade, viabilidade Algo importante a notar é que agilidade não é igual a lançamento no mercado. Pelo contrário, é agilidade + testabilidade + implementabilidade. É uma armadilha na qual muitos arquitetos caem ao traduzirem as preocupações do domínio. Focar apenas um dos ingredientes é como esquecer de colocar farinha na massa do bolo. Por exemplo, um stakeholder do domínio pode dizer algo assim: “Devido a requisitos regulatórios, é imperativo concluir a precificação dos fundos no final do dia a tempo.” Um arquiteto ineficiente pode focar apenas o desempenho porque isso parece ser o foco principal dessa preocupação do domínio. Contudo, esse arquiteto fracassará por muitos motivos. Primeiro, não importa a rapidez do sistema se ele não fica disponível quando necessário. Segundo, conforme o domínio cresce e mais fundos são criados, o sistema também consegue escalar para terminar o processamento no fim do dia a tempo.

Terceiro, o sistema não deve apenas estar disponível, mas também ser confiável e não travar quando os preços dos fundos no final do dia são calculados. Quarto, o que acontece se a precificação dos fundos no final do dia estiver 85% concluída e o sistema parar? Ele deve ser capaz de se recuperar e reiniciar onde a precificação parou. Por fim, o sistema pode ser rápido, mas os preços dos fundos estão sendo calculados corretamente? Em caso afirmativo, além do desempenho, o arquiteto também deve focar igualmente a disponibilidade, a escalabilidade, a confiabilidade, a recuperabilidade e a auditabilidade.

Página 83

Extraindo Características da Arquitetura dos Requisitos

Algumas características da arquitetura vêm com afirmações explícitas nos documentos de requisitos. Por exemplo, a quantidade esperada e explícita de usuários e a escala normalmente aparecem no domínio ou nas preocupações do domínio. Outras vêm do conhecimento inerente do domínio que os arquitetos têm, um dos muitos motivos para o conhecimento do domínio sempre ser benéfico para eles. Por exemplo, suponha que um arquiteto planeje uma aplicação que lida com o registro de aulas para estudantes universitários. Para facilitar os cálculos, pressuponha que a escola tenha mil alunos e dez horas de registro. O arquiteto deve planejar um sistema pressupondo uma escala consistente, fazendo a suposição implícita de que os estudantes se distribuirão igualmente ao longo do tempo durante o processo de registro? Ou com base no conhecimento dos hábitos e das inclinações desses estudantes o arquiteto deve planejar um sistema que possa lidar com todos os mil alunos tentando se registrar nos últimos dez minutos? Qualquer pessoa que entende o quanto os estudantes normalmente procrastinam sabe a resposta! Raramente esses detalhes aparecerão nos documentos dos requisitos, embora informem as decisões do design.

Página 84

A Origem dos Katas de Arquitetura Alguns anos atrás, Ted Neward, um conhecido arquiteto, criou os katas de arquitetura, um método mais inteligente de permitir aos arquitetos iniciantes um modo de praticar a obtenção das características da arquitetura a partir das descrições para domínios. Com origem no Japão e nas artes marciais, kata é um exercício de treinamento individual, cuja ênfase está na forma e na técnica correta.

Como ter ótimos designers? Os ótimos designers fazem design, claro.

— Fred Brooks Então como podemos conseguir ótimos arquitetos se eles têm a chance de projetar poucas vezes apenas em suas carreiras?

Para dar um currículo aos aspirantes a arquiteto, Ted criou o primeiro site de katas de arquitetura, que os autores Neal e Mark adaptaram e atualizaram. A premissa do exercício kata fornece aos arquitetos um problema expresso em termos de domínio e contexto adicional (coisas que podem não aparecer nos requisitos, mas impactam o design). Equipes pequenas trabalham por 45 minutos em um design, então mostram os resultados para os outros grupos, que votam em quem propôs a melhor arquitetura. Fiel à sua finalidade original, os katas de arquitetura fornecem um laboratório útil para os aspirantes a arquiteto.

Cada kata tem seções predefinidas:

Descrição O problema geral do domínio que o sistema tenta resolver Usuários O número esperado e/ou tipos de usuários do sistema Requisitos Requisitos do domínio/nível do domínio, como um arquiteto pode esperar dos usuários/especialistas do domínio Neal atualizou o formato alguns anos depois em seu blog, acrescentando a seção contexto adicional a cada kata com importantes considerações extras, tornando os exercícios mais reais.

Contexto adicional Muitas considerações que um arquiteto deve fazer não são expressas explicitamente nos requisitos, mas pelo conhecimento implícito do domínio do problema Encorajamos que os novos arquitetos usem o site para fazer seu próprio exercício kata. Qualquer pessoa pode ter uma oportunidade informal na qual uma equipe de arquitetos aspirantes pode resolver um problema e ter um arquiteto experiente avaliando o design e a análise de trade-off, na hora ou com uma rápida análise após o fato. O design não será elaborado porque o exercício tem um tempo definido. O ideal é que os membros da equipe recebam um feedback da arquitetura experiente sobre as concessões que faltam e designs alternativos.

Estudo de Caso: Silicon Sandwiches

Para ilustrar vários conceitos, usamos os katas de arquitetura (veja “A Origem dos Katas de Arquitetura” para ler sobre a origem do conceito). Para mostrar como os arquitetos obtêm as características da arquitetura a partir dos requisitos, apresentamos o kata Silicon Sandwiches.

Descrição Uma loja de sanduíches nacional permite o pedido online (além do serviço por telefone atual).

Usuários Milhares, talvez um dia, milhões

Página 85

Requisitos Os usuários farão os pedidos, então terão um tempo para escolher seu sanduíche e orientações até a loja (que deve integrar vários serviços de mapas externos que incluem informações do trânsito) Se a loja oferece um serviço de delivery, envia o entregador com o sanduíche para o usuário Acessibilidade do dispositivo móvel Oferece promoções/ofertas diariamente em todo o país Oferece promoções/ofertas diariamente no local Aceita pagamento online, pessoalmente ou na entrega Contexto adicional As lojas de sanduíche são franquias, cada uma com um proprietário diferente A matriz tem planos para, em breve, expandir para o exterior A meta da empresa é contratar mão de obra barata para maximizar o lucro Dado esse cenário, como um arquiteto obteria as características da arquitetura? Cada parte do requisito pode contribuir com um ou mais aspectos da arquitetura (e muitas não). O arquiteto não projeta o sistema inteiro aqui; haverá um esforço considerável ao criar o código para resolver a declaração do domínio. Ao contrário, ele procura coisas que influenciam ou impactam o design, em particular o estrutural.

Primeiro, separe as características da arquitetura candidata em explícitas e implícitas.

Características Explícitas

As características explícitas da arquitetura aparecem em uma especificação dos requisitos como uma parte do design necessário. Por exemplo, o site da loja pode querer dar suporte a certa quantidade de usuários simultâneos, que os analistas do domínio especificam nos requisitos.

Um arquiteto deve considerar cada parte dos requisitos para ver se ele colabora com uma característica da arquitetura. Mas primeiro, deve considerar as previsões no nível do domínio sobre as métricas esperadas, como representadas na seção Usuários do kata.

Um dos primeiros detalhes que devem chamar a atenção de um arquiteto é a quantidade de usuários: atualmente milhares, talvez um dia, milhões (é uma loja de sanduíches muito ambiciosa!). Assim, a escalabilidade — a capacidade de lidar com um grande número de usuários simultâneos sem uma séria diminuição do desempenho — é uma das principais características da arquitetura. Observe que a declaração do problema não pediu explicitamente a escalabilidade, mas o requisito foi expresso como um número esperado de usuários. Muitas vezes, os arquitetos devem decodificar a linguagem do domínio nos equivalentes da engenharia.

Porém, também é possível que precisemos da elasticidade, ou seja, a capacidade de lidar com picos de requisições. Essas duas características costumam aparecer juntas, mas têm restrições diferentes. A escalabilidade parece o gráfico mostrado na Figura 5-1.

Página 86

Figura 5-1. A escalabilidade mede o desempenho dos usuários simultâneos Já a elasticidade mede os picos do tráfego, como na Figura 5-2.

Alguns sistemas são escaláveis, mas não elásticos. Por exemplo, considere um sistema de reservas de hotel. Na ausência de vendas ou eventos especiais, o número de usuários provavelmente é consistente. Por outro lado, considere o sistema de reservas de bilhetes para um concerto. Quando novos bilhetes entram para a venda, fãs fervorosos invadem o site, requerendo altos graus de elasticidade. Muitas vezes, os sistemas elásticos também precisam de escalabilidade: a capacidade de lidar com picos e altos números de usuários simultâneos.

A exigência para a elasticidade não apareceu nos requisitos da loja Silicon Sandwiches, embora o arquiteto deva identificar isso como uma consideração importante. Por vezes, os requisitos declaram as características da arquitetura de imediato, mas algumas se escondem dentro do domínio do problema. Considere uma loja de sanduíches. O tráfego é consistente durante o dia? Ou ela tem picos de tráfego na hora das refeições? É quase certo que seja a última opção.

Assim, um bom arquiteto deve identificar essa possível característica da arquitetura.

Página 87

Figura 5-2. Os sistemas elásticos devem aguentar os picos de usuários Um arquiteto deve considerar um requisito comercial por vez e ver se existem características da arquitetura:

1. Os usuários farão seu pedido, então terão um tempo para escolher o sanduíche e as orientações até a loja (que deve fornecer a opção de se integrar com serviços de mapa externos que incluem informações do trânsito).

Os serviços de mapa externos implicam em pontos de integração, que podem impactar aspectos como a confiabilidade. Por exemplo, se um desenvolvedor cria um sistema que conta com um sistema de terceiros, ainda que chame isso de falha, ele impacta a confiabilidade do sistema de chamadas. Contudo, os arquitetos também devem ter cuidado com as características da arquitetura com excesso de especificação. E se o serviço de tráfego externo ficar inativo? O site Silicon Sandwiches deve falhar ou oferecer menos eficiência sem informações do trânsito? Eles sempre devem evitar criar pouca consistência ou fragilidade desnecessária nos designs.

2. Se a loja oferece serviço de delivery, envie o entregador com o sanduíche para o usuário.

Nenhuma característica da arquitetura em especial parece necessária para dar suporte a esse requisito.

3. Acessibilidade do dispositivo móvel.

Esse requisito basicamente afetará o design da aplicação, levando a criar uma aplicação web para celular ou várias aplicações web nativas. Dadas as restrições no orçamento e a simplicidade da aplicação, é possível que um arquiteto considere um exagero criar várias aplicações, portanto o design indica uma aplicação web otimizado para celular. Assim, o arquiteto pode querer definir algumas características da arquitetura específicas do

Página 88

desempenho para o tempo de carregamento da página e outras características específicas para celular. Note que o arquiteto não deve atuar sozinho nessas situações, mas colaborar com os designers de experiência do usuário, stakeholders do domínio e outras partes interessadas para verificar tais decisões.

1. 4. Oferecer promoções/ofertas diariamente no país.
2. 5. Oferecer promoções/ofertas diariamente no local.

Ambos os requisitos especificam a customização das promoções e das ofertas. Note que o requisito 1 também implica nas informações personalizadas do tráfego com base no endereço. Com base nos três requisitos, o arquiteto pode considerar a customização como sendo uma característica da arquitetura. Por exemplo, um estilo de arquitetura, como a arquitetura de microkernel, suporta muitíssimo bem o comportamento personalizado definindo uma arquitetura de plug-in. Nesse caso, o comportamento padrão aparece no centro e os desenvolvedores escrevem as partes personalizadas opcionais, com base no local, via plug-ins. Contudo, um design tradicional também pode incluir esse requisito via padrões de design (como Template Method). Essa questão é comum na arquitetura e requer que os arquitetos sempre pesem as concessões entre as opções concorrentes. Detalhamos mais a concessão em “Design Versus Arquitetura e Concessões”.

6. Aceitar pagamento online, pessoalmente ou na entrega.

Pagamentos online implicam em segurança, mas nada nesse requisito sugere um nível de segurança particularmente elevado além do que está implícito.

7. As lojas de sanduíches são franquias, cada uma com um proprietário diferente.

Esse requisito pode impor restrições de custo na arquitetura; o arquiteto deve verificar a viabilidade (aplicar restrições como custo, tempo e capacidade da equipe) para saber se é garantido ter uma arquitetura simples ou de sacrifício.

8. A matriz tem planos para, em breve, expandir para o exterior.

Esse requisito implica na internacionalização ou em i18n. Muitas técnicas de design existem para lidar com isso, e não deve requerer uma estrutura especial. Contudo, é certo que orientará as decisões de design.

9. A meta corporativa é contratar mão de obra barata para maximizar o lucro.

Esse requisito sugere que a utilização será importante, mas, de novo, é mais uma preocupação com o design do que com as características da arquitetura.

A terceira característica da arquitetura da qual obtemos os requisitos anteriores é o desempenho: ninguém quer comprar em uma loja de sanduíches com um desempenho ruim, sobretudo nas horas de pico. Mas desempenho é um conceito cheio de nuanças; para qual tipo de desempenho o arquiteto deve projetar? Cobrimos as várias nuanças dessa característica no Capítulo 6.

Também queremos definir os números do desempenho junto dos números da escalabilidade, ou seja, devemos estabelecer uma linha de base do desempenho sem uma escala em particular, assim como determinar qual é um nível de desempenho aceitável, dada certa quantidade de usuários. Com muita frequência, as características da arquitetura interagem entre si, forçando os arquitetos a defini-las em relação às outras.

Página 89

Características Implícitas

Muitas características da arquitetura não são especificadas nos documentos de requisitos, embora componham um aspecto importante do design. Uma característica da arquitetura implícita que o sistema pode querer dar suporte é a disponibilidade: assegurar que os usuários possam acessar o site do sanduíche. Intimamente relacionada à disponibilidade está a confiabilidade: assegurar que o site fique ativo durante as interações; ninguém quer comprar em um site que fica caindo, forçando a fazer login de novo.

Segurança aparece como uma característica da arquitetura implícita em todo sistema: ninguém quer criar um software sem segurança. Mas pode ser priorizada dependendo da criticalidade, o que mostra a natureza interligada de nossa definição. Um arquiteto considera a segurança uma característica da arquitetura se ela influencia algum aspecto estrutural do design e é crítica ou importante para a aplicação.

Para a loja Silicon Sandwiches, um arquiteto pode pressupor que os pagamentos devem ser lidados por terceiros. Assim, contanto que os desenvolvedores sigam a recomendação de segurança geral (não passar os números do cartão de crédito como texto simples, não armazenar muitas informações etc.), o arquiteto não deve precisar de nenhum design estrutural em especial para incluir a segurança; um bom design na aplicação será suficiente. Cada característica da arquitetura interage com as outras, levando à armadilha comum de arquitetos especificando demais as características, que é tão perigoso quanto especificá-las de menos porque isso complica muito o design do sistema.

A última característica da arquitetura maior que a loja Silicon Sandwiches precisa dar suporte inclui vários detalhes dos requisitos: personalização. Note que várias partes do domínio do problema oferecem um comportamento personalizado: receitas, vendas locais e orientações que podem ser anuladas localmente. Assim, a arquitetura deve ter suporte para a capacidade de facilitar o comportamento personalizado. Normalmente isso entraria no design da aplicação.

Mas como nossa definição especifica, uma parte do domínio do problema que conta com a estrutura personalizada para ter suporte vai para uma característica da arquitetura. Esse elemento do design não é crítico para o sucesso da aplicação. É importante notar que não há respostas certas ao escolher as características da arquitetura, apenas as incorretas — ou, como Mark observa em uma de suas citações conhecidas:

Não existem respostas erradas na arquitetura, apenas as caras.

Página 90

Design Versus Arquitetura e Trade-offs No kata Silicon Sandwiches, provavelmente um arquiteto identificaria a customização como uma parte do sistema, mas a questão é: arquitetura ou design? A arquitetura implica algum componente estrutural, já o design reside dentro da arquitetura. No caso da customização da loja Silicon Sandwiches, o arquiteto poderia escolher um estilo de arquitetura como microkernel e criar um suporte estrutural para a personalização. Contudo, se o arquiteto escolheu outro estilo por causa de conflitos de interesse, os desenvolvedores poderiam implementar a customização usando o padrão de design Template Method, que permite às classes-mãe definirem o fluxo de trabalho que pode ser sobrescrito nas classes-filha.

Qual design é melhor?

Como em toda arquitetura, depende de muitos fatores. Primeiro, há bons motivos, como desempenho e acoplamento, para não implementar uma arquitetura de microkernel? Segundo, outras características da arquitetura desejáveis são mais difíceis em um design versus o outro? Terceiro, quanto custaria dar suporte a todas as características da arquitetura em cada design versus padrão? Esse tipo de análise de trade-off arquitetural é uma parte importante da função de um arquiteto.

Acima de tudo, é essencial que o arquiteto colabore com os desenvolvedores, gerente de projeto, equipe de operações e outros coconstrutores do sistema de software. Nenhuma decisão de arquitetura deve ser tomada de forma isolada da equipe de implementação (o que leva ao temido antipadrão Arquiteto da Torre de Marfim). No caso da loja Silicon Sandwiches, o arquiteto, o responsável técnico, os desenvolvedores e os analistas do domínio devem colaborar para decidir como implementar melhor a customização.

Um arquiteto pode planejar uma arquitetura que não inclui a customização estruturalmente, requerendo que o design da aplicação em si dê suporte a esse comportamento (veja “Design Versus Arquitetura e Trade-Offs”). Os arquitetos não devem se estressar muito descobrindo o conjunto correto e exato de características da arquitetura; os desenvolvedores podem implementar a funcionalidade de vários modos. Contudo, identificar corretamente os elementos estruturais importantes pode facilitar um design mais simples ou elegante. Os arquitetos devem se lembrar que não há um design melhor na arquitetura, apenas uma coleção menos pior de trade-offs.

Os arquitetos também devem priorizar essas características da arquitetura para tentar encontrar os conjuntos requeridos mais simples. Um exercício útil assim que a equipe deu um primeiro passo para identificar as características é tentar determinar a menos importante, ou seja, se você deve eliminar uma, qual seria? Em geral, é provável que eles descartem as características explícitas, pois muitas das implícitas dão suporte ao sucesso em geral. O modo como definimos o que é crítico ou importante para o sucesso ajuda os arquitetos a determinarem se a aplicação realmente requer cada característica da arquitetura. Tentando determinar a menos aplicável, os arquitetos podem ajudar a determinar a necessidade crítica. No caso da loja Silicon Sandwiches, qual característica da arquitetura identificada é menos importante? De novo, não existe uma resposta certa absoluta. Porém, nesse caso, a solução poderia perder a customização ou o desempenho. Poderíamos eliminar a customização como uma característica e planejar implementar esse comportamento como parte do design da aplicação. Das características operacionais, o desempenho provavelmente é o menos impactante para o sucesso. Claro, os desenvolvedores não querem criar uma aplicação com um desempenho terrível, mas um que não prioriza o desempenho acima das outras características, como escalabilidade ou disponibilidade.

Página 91

6. Medindo e Controlando as Características da Arquitetura

CAPÍTULO 6 Medindo e Controlando as Características da Arquitetura Os arquitetos devem lidar com uma variedade enorme de características da arquitetura em todos os diferentes aspectos dos projetos de software. Aspectos operacionais, como desempenho, elasticidade e escalabilidade, se misturam com preocupações estruturais, como modularidade e implementabilidade. Este capítulo foca definir concretamente algumas das características da arquitetura mais comuns e criar mecanismos de governança para elas.

Medindo as Características da Arquitetura

Vários problemas comuns existem na definição das características da arquitetura nas organizações:

Elas não são físicas Muitas características da arquitetura de uso comum têm significados vagos. Por exemplo, como um arquiteto projeta para ter agilidade ou implementabilidade? O setor tem perspectivas muito diferentes de termos comuns, por vezes orientados por contextos diferentes legítimos, outras por acaso.

Definições muito variadas Mesmo dentro da mesma organização, departamentos diferentes podem discordar da definição de recursos cruciais, como desempenho. Até que desenvolvedores, arquitetura e operações possam se unir com uma definição em comum, é difícil uma conversa adequada.

Complexas demais Muitas características desejáveis da arquitetura compõem muitas outras em uma escala menor. Por exemplo, os desenvolvedores podem dividir a agilidade em características como, modularidade, implementabilidade e testabilidade.

Definições objetivas para as características da arquitetura resolvem os três problemas: por haver concordância na organização sobre as definições concretas para as características da arquitetura, as equipes criam uma linguagem universal em torno da arquitetura. E mais, por incentivar a criação de definições objetivas, as equipes conseguem obter características complexas para revelar recursos mensuráveis que elas podem definir com objetividade.

Medidas Operacionais

Muitas características da arquitetura têm medidas diretas óbvias, como desempenho ou escalabilidade. Contudo, mesmo essas oferecem muitas interpretações sutis, dependendo das metas da equipe. Por exemplo, talvez uma equipe meça o tempo médio de resposta para certas requisições, um bom exemplo de medida das características da arquitetura operacional. Mas se

Página 92

as equipes medem apenas a média, o que acontece se alguma condição limite causa 1% de requisições levando 10 vezes mais tempo que as outras? Se o site tem tráfego suficiente, os valores atípicos podem nem mesmo aparecer. Portanto, uma equipe também pode querer medir os tempos máximos de respostas para capturar os valores atípicos.

Muitos Tipos de Desempenho Muitas das características da arquitetura descritas têm definições sutis e variadas. Desempenho é um ótimo exemplo.

Muitos projetos analisam o desempenho geral: por exemplo, quanto tempo os ciclos de solicitação e resposta levam para uma aplicação web. Mas os arquitetos e os engenheiros DevOps trabalharam muito para estabelecer os orçamentos do desempenho: orçamentos específicos para certas partes da aplicação. Por exemplo, muitas organizações pesquisaram o comportamento do usuário e determinaram que o tempo ideal da apresentação da primeira página (o primeiro sinal visível de progresso para uma página web, em um navegador ou dispositivo móvel) é de 500 ms, metade de um segundo; a maioria das aplicações fica na faixa de dois dígitos para essa métrica. Mas para os sites modernos que tentam capturar o máximo possível de usuários, é uma métrica importante a controlar, e as organizações por trás disso criaram medidas extremamente sutis.

Algumas dessas métricas têm outras implicações para o design das aplicações. Muitas organizações inovadoras colocam orçamentos de peso K para os downloads da página: um número máximo de bytes de bibliotecas e frameworks permitidas em certa página. O raciocínio por trás dessa estrutura deriva de limites físicos: apenas uma quantidade de bytes consegue trafegar em uma rede em dado momento, em especial nos dispositivos móveis em áreas de alta latência.

As equipes de alto nível não estabelecem apenas números de desempenho exatos, elas baseiam suas definições na análise estatística. Por exemplo, digamos que um serviço de streaming de vídeo deseja monitorar a escalabilidade. Em vez de definir um número arbitrário como meta, os engenheiros medem a escala ao longo do tempo e criam modelos estatísticos, então disparam alarmes se as métricas de tempo real ficam fora dos modelos de previsão. Uma falha pode significar duas coisas: o modelo está incorreto (o que as equipes gostam de saber) ou falta algo (o que as equipes também gostam de saber).

As características que as equipes podem medir agora evoluíram rápido, junto com ferramentas e uma compreensão sutil. Por exemplo, muitas equipes focavam recentemente os orçamentos de desempenho para métricas como a primeira eexibição de conteúdo e primeira inatividade (idle) da CPU, ambas sobre volumes relacionados a problemas com o desempenho para usuários e páginas web em dispositivos móveis. Conforme dispositivos, destinos, capacidades e várias outras coisas mudarem, as equipes encontrarão coisas e modos novos de medir.

Medidas Estruturais

Algumas medidas objetivas não são tão óbvias quanto o desempenho. E as características estruturais internas, como modularidade bem definida? Infelizmente não existem ainda métricas completas para a qualidade interna do código. Mas algumas métricas e ferramentas comuns permitem que os arquitetos lidem com alguns aspectos críticos da estrutura do código, embora ao longo de dimensões estreitas.

Um aspecto do código mensurável e óbvio é a complexidade, definida pela métrica complexidade ciclomática.

Página 93

Página 94

equipes não ficam de olho na complexidade que aumenta gradualmente, ela domina a base de código.

O que É um Bom Valor para a Complexidade Ciclomática?

Uma pergunta comum feita aos autores quando eles falam sobre esse assunto é: qual é um bom valor limite para a CC?

Claro, como todas as respostas na arquitetura de software: depende! Depende da complexidade do domínio do problema. Por exemplo, se você tiver um problema com algoritmo complexo, a solução produzirá funções complexas.

Alguns aspectos principais da CC para os arquitetos monitorarem: as funções são complexas por causa do domínio do problema ou da codificação ruim? Como alternativa, o código está mal particionado? Em outras palavras, um método grande poderia ser dividido em partes menores e lógicas, distribuindo o trabalho (e a complexidade) em métodos mais bem fatorados?

Em geral, os limites do setor para a CC sugerem que um valor abaixo de 10 é aceitável, exceto outras considerações, como os domínios complexos. Consideramos esse limite muito alto e preferimos um código abaixo de 5, indicando um código coeso e bem fatorado. Uma ferramenta de métrica em Java, Crap4J, tenta determinar o quanto o código é ruim (baixa qualidade) avaliando uma combinação de CC e cobertura de código; se a CC fica acima de 50, nenhuma cobertura de código melhora a má qualidade dele. O artefato profissional mais terrível que Neal já encontrou foi uma função C que servia como o centro de um pacote de software comercial cuja CC ficava acima de 800! Era uma função com mais de 4 mil linhas de código, inclusive o uso literal de declarações GOTO (para evitar loops profundamente aninhados impossíveis).

Práticas de engenharia, como o desenvolvimento orientado a testes (TDD), têm o efeito colateral acidental (mas positivo) de gerar métodos melhores e menos complexos em média para certo domínio do problema. Ao praticar o TDD, os desenvolvedores tentam escrever um teste simples, então escrevem uma quantidade menor de código para passar no teste. Isso foca o comportamento separado e bons limites de teste encorajam métodos altamente coesos e bem fatorados que mostram uma baixa CC.

Medidas do Processo

Algumas características da arquitetura cruzam os processos de desenvolvimento de software.

Por exemplo, a agilidade costuma aparecer como um recurso desejável. Mas é uma característica complexa que os arquitetos podem decompor em recursos como testabilidade e implementabilidade.

O teste é medido por ferramentas de cobertura de código para todas as plataformas que avaliam a totalidade do teste. Como todas as verificações do software, não é possível substituir o raciocínio e a intenção. Por exemplo, uma base de código pode ter 100% de cobertura de código, mas afirmações ruins que realmente não dão confiança na correção do código. Porém o teste é claramente uma característica mensurável e objetiva. Do mesmo modo, as equipes podem medir a implementabilidade com várias métricas: porcentagem de implementações bemsucedidas versus com falhas, quanto tempo levam as implementações, problemas/erros levantados pelas implementações e muitos outros. Cada equipe tem a responsabilidade de chegar a um bom conjunto de medidas que capturam dados úteis para a organização, em qualidade e quantidade. Muitas dessas medidas se resumem às prioridades e às metas da equipe.

Agilidade e suas partes afins se relacionam claramente com o processo de desenvolvimento de software. Porém, esse processo pode impactar a estrutura da arquitetura. Por exemplo, se a facilidade da implementação e do teste são prioridades altas, então um arquiteto daria mais ênfase na boa modularidade e no isolamento no nível da arquitetura, um exemplo de característica da arquitetura orientando uma decisão estrutural. Quase nada dentro do escopo de um projeto de software pode chegar no nível de uma característica da arquitetura se ela

Página 95

consegue atender a nossos três critérios, forçando um arquiteto a tomar decisões de design para explicar isso.

Governança e Funções de Aptidão

Assim que os arquitetos estabelecem as características da arquitetura e as priorizam, como podem assegurar que os desenvolvedores respeitarão essas prioridades? A modularidade é um ótimo exemplo de um aspecto da arquitetura que é importante, mas não urgente; em muitos projetos de software, a urgência é dominante, embora os arquivos ainda precisem de um mecanismo para a governança.

Governando as Características da Arquitetura

Governança, da palavra grega kubernan (orientar), é uma responsabilidade importante da função do arquiteto. Como o nome implica, o escopo da governança da arquitetura alcança qualquer aspecto do processo de desenvolvimento de software que os arquitetos (inclusive funções como arquitetos corporativos) devem influenciar. Por exemplo, assegurar a qualidade do software em uma organização se enquadra no título da governança arquitetural porque fica dentro do escopo da arquitetura e a negligência pode levar a problemas desastrosos na qualidade.

Por sorte, existem soluções cada vez mais sofisticadas para diminuir esse problema para os arquitetos, um bom exemplo de crescimento incremental nas capacidades dentro do ecossistema de desenvolvimento de software. O impulso para a automação nos projetos de software gerado pela Programação Extrema criou uma integração contínua, levando a mais automação nas operações contínuas, que agora chamamos de DevOps, continuando na governança arquitetural. O livro Building Evolutionary Architectures (sem publicação no Brasil) descreve uma família de tecnologias, chamadas funções de aptidão, usadas para automatizar muitos aspectos da governança da arquitetura.

Funções de Aptidão

A palavra “evolutivo”, no livro Building Evolutionary Architectures, vem mais da computação evolutiva do que da biologia. Uma das autoras, a Dra. Rebecca Parsons, passou um tempo no espaço da computação evolutiva, incluindo ferramentas como algoritmos genéticos. Tal algoritmo executa e produz uma resposta, então passa por mutação com técnicas bem conhecidas definidas no mundo da computação evolutiva. Se um desenvolvedor tenta projetar um algoritmo genérico para produzir um resultado benéfico, ele normalmente deseja orientar o algoritmo, fornecendo uma medida objetiva que indica a qualidade do resultado. Esse mecanismo de orientação se chama função de aptidão: uma função objeto usada para avaliar a proximidade com a qual a saída atinge o alvo. Por exemplo, suponha que um desenvolvedor precise resolver o problema do caixeiro viajante, um problema famoso usado como base para o aprendizado de máquina. Dados um caixeiro e uma lista de cidades que ele deve visitar, com distâncias entre elas, qual é a rota ideal? Se um desenvolvedor projeta um algoritmo genético para resolver esse problema, uma função de aptidão pode avaliar a extensão da rota, com a menor possível representando o maior sucesso. Outra função de aptidão pode ser avaliar o custo geral associado à rota e tentar manter o custo no mínimo. Todavia, outra poderia ser

Página 96

avaliar o tempo em que o caixeiro viajante está fora e otimizar a diminuição do tempo total da viagem.

As práticas na arquitetura evolutiva pegam esse conceito para criar uma função de aptidão da arquitetura:

Função de aptidão da arquitetura Qualquer mecanismo que fornece uma avaliação objetiva da integridade de alguma característica da arquitetura ou uma combinação delas As funções de aptidão não são um framework novo para os arquitetos baixarem, mas uma nova perspectiva em muitas ferramentas existentes. Note na definição as palavras qualquer mecanismo — as técnicas de verificação para as características da arquitetura são tão variadas quanto as características. As funções de aptidão sobrepõem muitos mecanismos de verificação existentes, dependendo de como são usadas: como métricas, monitores, bibliotecas de teste unitário, engenharia do caos etc., como mostrado na Figura 6-2.

Figura 6-2. Mecanismos das funções de aptidão Muitas ferramentas diferentes podem ser usadas para implementar as funções de aptidão, dependendo das características da arquitetura. Por exemplo, em “Acoplamento”, no Capítulo 3, apresentamos métricas que permitem aos arquitetos avaliarem a modularidade. Veja alguns exemplos de funções de aptidão que testam vários aspectos da modularidade.

Dependências cíclicas Modularidade é uma característica da arquitetura implícita importante para a maioria dos arquitetos, pois uma modularidade mal mantida prejudica a estrutura de uma base de código;