Um dos principais desafios ao se elaborar a arquitetura de um software está em considerar seus atributos de qualidade e, principalmente, a correta especificação destes atributos. Muitos dos problemas, não por acaso, estão diretamente relacionados à essa dificuldade na especificação, como acontece no tratamento de segurança e desempenho, citando apenas alguns.
Os atributos de qualidade possuem um papel de extrema importância na aceitação do cliente e do usuário final. Desta forma, tratá-los de uma maneira sistemática e apropriada é um esforço importante, porém desafiador.
A desorganização sobre os atributos de qualidade
Os atributos de qualidade são difíceis de se lidar, pois precisam ser tratados de forma diferente e afetam não apenas as partes, mas o sistema como um todo. Engenheiros, por exemplo, não conseguem restringir atributos como segurança ou desempenho a um único ponto do sistema. Tais tentativas acabam mostrando-se impossíveis na maioria dos casos, pois os interesses são transversais e frequentemente até invasivos, isto é, eles fazem com que engenheiros de software injetem design e código em componentes pré-existentes. Em outras palavras, a maioria dos atributos de qualidade é sistêmica e precisa de um tratamento global e estratégico.
Grady Booch disse que arquitetura de software trata de tudo que for custoso para mudar, o que se aplica particularmente bem a atributos de qualidade. Nesse sentido também está Martin Fowler, que mencionou que a arquitetura de software diz respeito às coisas importantes - seja lá o que isso quer dizer.
Entendimento é fundamental para o design de sucesso
Mas como podem os engenheiros de software lidar com toda esta complexidade? O primeiro passo é ter certeza de que todos os requisitos estão bem compreendidos e priorizados. Não é nada proveitoso lidar com requisitos como "deveria ter alto desempenho" ou "precisa oferecer alta segurança". Estas frases podem até parecer lógicas vistas de longe, mas o que exatamente elas significam na prática?
O primeiro desafio e pré-condição para qualquer bom design é criar uma boa especificação de requisitos. Mas, afinal, o que significa um bom requisito? De acordo com ISO (Organização Internacional para Padronização), um bom requisito possui as seguintes propriedades:
- coeso: o requisito deve tratar apenas de um assunto;
- completo: ele deve ser totalmente declarado em um único lugar sem depender de informações adicionais;
- consistente: o requisito não deve contradizer outros requisitos e deve ser totalmente aderente à documentação;
- correto: todas as necessidades de negócio dos stakeholders devem ser tratadas;
- atual: os requisitos não devem se tornar obsoletos durante o projeto;
- observável externamente: os requisitos especificam uma característica do produto que é observável externamente ou experimentada pelo usuário. "Requisitos" que especificam arquitetura, design, implementação, teste ou outros atributos internos são restrições legítimas e devem estar claramente declaradas na seção de Restrições do documento de Requisitos;
- factível: o requisito pode ser implementado dentro das restrições do projeto;
- não ambíguo: o requisito é declarado de forma concisa sem recorrer a jargões técnicos, siglas (salvo se houver definição em outra parte do documento de Requisitos), ou outro palavreado difícil. Expressa fatos objetivos e não opiniões subjetivas;
- mandatório: o requisito representa uma característica definida pelo stakeholder cuja ausência resultaria em uma deficiência ao produto;
- verificável: A implementação do requisito pode ser determinada por meio de um dos quatro métodos disponíveis: inspeção, análise, demonstração ou teste.
Sempre ao receber uma especificação de requisitos, os engenheiros de software devem garantir sua qualidade. Uma especificação de requisitos ruim irá invariavelmente levar a um sistema de software ruim, pouco importando quão bons forem os designers e os desenvolvedores. Portanto, testar e avaliar a especificação de requisitos é da mais alta importância.
Atenção aos detalhes implícitos
É importante notar neste contexto que os arquitetos devem também estar atentos aos requisitos ocultos ou implícitos.
Ainda que não esteja documentado em lugar algum, é evidente que um smartphone deve ser acessível a qualquer momento e que tanto o teclado quanto a tela devem estar localizados do mesmo lado do aparelho. Estes requisitos podem parecer óbvios, mas não é assim para todos os requisitos implícitos. O diagrama ou análise de KANO, apesar de fora do escopo deste artigo, pode ser útil para lidar melhor com esta questão.
Outro ponto importante é que o stakeholder deve obter o que precisa e não necessariamente o que quer. Há uma história antiga de um cliente que ao chegar a uma concessionária fala ao vendedor que precisa de um carro com pára-choques melhores. O cliente explica que quando pega a estrada, tem sempre algum coelho atravessando a pista e que, na tentativa de desviar do coelho, o carro derrapa na pista molhada, acabando por bater em uma árvore. Obviamente o vendedor poderia vender um carro com melhores pára-choques, mas faz muito mais sentido oferecer um carro com freios ABS ao cliente.
Não menos importante, é sempre importante considerar o contexto quando lidar com atributos de qualidade. Suponha que seu sistema deva oferecer alta segurança. Mesmo que sua aplicação seja a mais segura do universo, ela não será bem sucedida se for necessário integrá-la com código legado que não é seguro e abre um ponto de vulnerabilidade para seu sistema. Lembre-se: a qualidade de qualquer sistema é sempre determinada por seu elo mais fraco.
O mundo não é plano
Ao lidar com atributos de qualidade, algo importante a se considerar é o universo multi-dimensional que eles criam. Uma atributo como desempenho, por exemplo, revela múltiplas facetas - a categorização foi proposta por um artigo da IBM:
- Pode lidar com throughput (vazão). O número de mensagens, por exemplo, que um middleware é capaz de transmitir por segundo;
- Também pode especificar o tempo de resposta ou o tempo entre a requisição e sua resposta;
- Velocidade de E/S [Entrada/Saída] que se refere ao processamento de dados em massa por um sistema;
- A percepção de desempenho que é a velocidade que o usuário sente ao interagir com o sistema;
- Também pode cobrir o tempo de inicialização, que é o tempo que o sistema precisa para estar totalmente disponível para uso;
- Por último, mas não menos importante, pode definir escalabilidade - embora alguns possam discordar que escalabilidade tenha qualquer relação com desempenho.
Além disso, ao lidar com desempenho, os engenheiros de software devem planejar quais facetas do desempenho eles estão de fato se referindo. Tratar de velocidade de E/S pode implicar em outras consequências além do throughput.
Abordagem baseada em cenários
Uma boa forma de documentar, modelar e expressar atributos de qualidade consiste em uma abordagem baseada em cenários, como introduzida pelos métodos de avaliação de arquitetura a exemplo do ATAM (Architecture Tradeoff Analysis Method, ou Método de Análise de Dilemas Arquiteturais). Todas as qualidades importantes devem ser especificadas usando cenários, que retratam ações no sistema ou em uma de suas partes efetuadas por usuários ou sistemas externos.
Um robô de rede pode disparar, por exemplo, um alto número de requisições contra um Servidor Web no intuito de torná-lo indisponível e este servidor poderia estar em um estado específico, como conectado ou desconectado da rede.
Sempre que um evento ocorrer, portanto, o sistema deve reagir de um modo específico, como bloquear o acesso de rede ao detectar um DDoS (Distributed denial-of-service, ou ataque distribuído de negação de serviço). As respostas do sistema também precisam ser quantificadas com métricas. Em um ataque DDoS, por exemplo, deve ser detectado e tratado em no máximo 3 minutos. O sistema é considerado uma caixa preta ou cinza nesta abordagem:
Cenários possibilitam muitos benefícios, tais como:
- São concretos, específicos e concisos à medida em que tratam de um aspecto particular de um atributo de qualidade aplicado a uma parte específica do sistema;
- Cenários ajudam a abordar os atributos de qualidade tanto no aspecto qualitativo quanto no quantitativo;
- Uma das vantagens mais importantes dos cenários é a clareza que proporcionam aos stakeholders. Ambos, stakeholders de negócio e engenheiros, podem entender, definir e discutir cenários;
- Não menos importante, cenários ajudam os gerentes de teste na especificação, com o propósto de garantir que os atributos de qualidade sejam realmente atingidos com sucesso.
Árvores de utilidades são nossas amigas
O próximo passo é criar uma árvore de utilidades que apresente os atributos de qualidade no formato de árvore, em que as folhas são os cenários.
Esta árvore de utilidades pode tanto ser definida colaborativamente entre stakeholders de negócio e técnicos quanto pode ser também preparada para servir de base para discussão dos arquitetos.
Em um workshop, stakeholders técnicos e de negócio atribuem métricas a cada cenário, que podem tratar da importância do cenário e da complexidade da sua implementação. Ambos critérios, em conjunto, ajudam a priorizar os cenários. Obviamente, um cenário de alta importância que é de difícil implementação deve ter prioridade maior que um cenário com baixa relevância para o negócio.
Os nós localizados diretamente abaixo da raiz da árvore de utilidades são tipicamente os atributos de qualidade de alto nível, tais como disponibilidade ou facilidade de manutenção. Os nós intermediários na árvore representam as facetas previamente apresentadas para desempenho, enquanto as folhas são os cenários.
Design estratégico e design tático
Para cada cenário, começando pelo mais importante por motivos estratégicos, as táticas de design, assim chamadas, podem ser então aplicadas.
Consideremos um diagrama de tática de design relativo a desempenho. Para tratar do aspecto segurança em uma aplicação, os engenheiros de software podem usar diferentes estratégias. Para cada estratégia podemos aplicar as táticas de design, como, por exemplo, para gerenciamento de recursos, podemos alavancar táticas como avaliação tardia (lazy evaluation) ou cache.
Após escolhidas as táticas de design para implementação de um cenário, normalmente os detalhes são aprofundados. Algumas táticas de design representam design patterns (padrões) por si mesmas. Em outras táticas podem existir múltiplos design patterns para dar suporte à implementação. Logo, selecionar os padrões corretos é a maior responsabilidade dos arquitetos de software e desenvolvedores nesta fase.
A essência da Rastreabilidade
A abordagem geral "magicamente" oferece rastreabilidade dos requisitos. Lembre-se que começou-se especificando os atributos de qualidade precisamente por meio de cenários que foram priorizados e consolidados, aos quais foram aplicadas as táticas de design e utilizados padrões de design.
Agora, temos uma relação bidirecional entre guias de arquitetura e decisões de arquitetura. Sempre que um cenário é modificado ou repriorizado, podemos rastrear todos os componentes arquiteturais afetados. E vice-versa: Quando um componente arquitetural é modificado, podemos checar quais requisitos são afetados pela modificação.
Na ATAM dois termos importantes foram cunhados. Um "ponto de sensibilidade" (sensitivity point) na arquitetura denota uma decisão arquitetural ou componente que está diretamente relacionado a um atributo de qualidade. Um "ponto de dilema" (tradeoff point) é uma decisão arquitetural ou componente que é um ponto de sensibilidade para pelo menos dois atributos de qualidade. É importante conhecer os pontos de sensibilidade, assim como os de dilema, pois são ferramentas que os arquitetos podem utilizar, mas que devem ser aplicadas com cuidado.
O que acabamos de ver é o que o Instituto de Engenharia de Software da Carnegie-Mellon (CMU/SEI) está chamando de ADD (attribute-driven design, ou design orientado a atributos).
Bolhas não estouram
Na prática, não é suficiente considerar apenas os aspectos arquiteturais ao lidar com atributos de qualidade. Bertrand Meyer disse uma vez que "Bolhas não estouram" e "Tudo que você precisa é de código."
Decisões tecnológicas impactam profundamente na obtenção da qualidade. O tipo de servidor de aplicação, a persistência de dados ou middleware de mensageria usados podem ser de alta relevância.
O design arquitetural deve ser complementado por protótipos ou simuladores que demonstrem se tratar de algo factível. Com protótipos deste tipo é possível avaliar atributos de qualidade específicos para verificar se é possivel obter com sucesso estes atributos. Simulações são substitutas para partes ausentes, como é típico na engenharia de sistemas em que os ciclos de desenvolvimento de hardware são mais lentos que os de desenvolvimento de software.
Resumo
Apesar dos requisitos funcionais serem desafiadores, os atributos de qualidade são ainda mais difíceis de implementar à medida em que eles representam, em sua maioria, preocupações transversais.
Desta maneira, estes atributos de qualidade devem ser manuseados com cuidado, pois qualquer tratamento ad hoc (improvisado) inevitavelmente conduzirá a um design ruim como é conhecido em muitos projetos que optam pela otimização prematura de desempenho.
Para lidar com os atributos de qualidade de uma forma sistemática, é preciso especificá-los apropriadamente; serem entendidos; priorizados; mapeados com decisões arquiteturais e verificados pela área de Qualidade. Uma forma efetiva para tal design sistemático é aplicar um método com base em cenários, iniciando com uma árvore de utilidades na modelagem dos atributos de qualidade e introduzir padrões de táticas de design.
Aplicada da forma correta, os projetos se beneficiarão da rastreabilidade bidirecional entre as guias de arquitetura e as decisões de arquitetura, em particular seus pontos de sensibilidade e de dilema. Cenários também são úteis para definir métodos de teste voltados a risco a fim de verificar se os atributos de qualidade foram obtidos com sucesso.
Para leitores interessados em mais detalhes, a leitura de livros como Architecture in Practice é o caminho certo para prosseguir.