Olá pessoal!

O título deste post pode ser interpretado sob duas perspectivas. Uma possível interpretação é “O que um arquiteto faz em seu dia-a-dia?”. Outra poderia ser “O que forma um arquiteto?”. Ambas as interpretações estão corretas e a resposta para ambas as questões é a mesma: Quality Attributes. Continue lendo e entenda o motivo.

Neste post inicio uma série em que abordarei um assunto de extrema importância dentro de arquitetura de software: atributos de qualidade. Sob este nome o tema pode parecer um pouco obscuro, porém, pode se tornar familiar sob outra definição: requisitos não-funcionais.

O conteúdo deste e dos demais posts desta série é baseado principalmente no livro Software Architecture in Practice – Second Edition, já mencionado em posts anteriores, no conteúdo do curso Software Architecture Principles and Practices, ministrado pelo Software Engeneering Institute (SEI), sendo complementado por outros materiais.

O que são atributos de qualidade?

É possível dizer que atributos de qualidade são considerados em praticamente todos os esforços de desenvolvimento de sistemas. Muito provavelmente você (e eu também) considera atributos de qualidade em suas demandas de forma inconsciente. E para provar esta teoria, um exemplo de um sistema que não leva em consideração atributos de qualidade, seria um sistema estruturado de forma monolítica, sem nenhuma estrutura de organização interna. Quantas vezes você considerou esta abordagem nos sistemas que projetou?

Desta forma, percebemos que um sistema não tem como requisito apenas funcionalidades que deve prover (requisitos funcionais). Time-to-market (um atributo de qualidade voltado ao negócio) e modificabilidade são frequentemente atributos de qualidade (ou requisitos não funcionais) que levam a estruturação de um sistema em módulos, de forma que ele possa ser construído em paralelo por mais de uma pessoa (time-to-market), ao mesmo tempo atribuindo responsabilidades de forma coerente (low coupling e high coesion), o que possibilita maior facilidade em modificações futuras (modificabilidade). Estes, portanto, são os motivos que nos levam a não projetar um sistema monolítico: atributos de qualidade.

O mesmo vale quando falamos da opção pela utilização de um padrão MVC, por exemplo. Essa escolha tem (ou pelo menos deveria ter) como motivação não apenas o fato de se estar seguindo uma tendência recente. O padrão MVC possibilita a que um sistema tenha atributos de qualidade como modificabilidade, já que é estruturado em camadas com responsabilidades bem definidas (separation of concerns), permitindo, por exemplo, que alterações no design da aplicação (tela) não necessariamente afetem a lógica de programação, e vice-versa. Testabilidade é outro atributo de qualidade decorrente da utilização deste padrão, já que possibilita a execução de testes unitários na camada de apresentação, por exemplo. Ambos, modificabilidade e testabilidade, trazem como beneficio para o negócio atributos como um baixo time-to-market, já que manutenções evolutivas serão implementadas mais rapidamente, e maior disponibilidade (availability), já que a aplicação de testes unitários tende a reduzir o número de bugs de um sistema, tornando-o mais estável (disponível) para o usuário final.

Podemos entender então que atributos de qualidade são requisitos não-funcionais, ou seja, que não dizem respeito ao que o sistema deve prover em termos de funcionalidade, mas sim, em termos de qualidade. Existem diversas categorias de atributos de qualidade e diversos assuntos relacionados. Availability, modifyability, performance, security, testabiliy, usability, scalability, extensibility, reliability, são exemplos de atributos de qualidade. Existem também alguns conceitos mais difundidos que levam em consideração um subconjunto de atributos de qualidade específicos. Por exemplo:

· FURPS: functionality, usability, reliability, performance, supportability;

· ACID: atomicity, consistency, isolation, durability;

· ISO/IEC 9126: functionality, reliability, usability, efficiency, maintainability;

Por que atributos de qualidade são importantes?

No livro Software Architecture in Practice – Second Edition, é dado um exelente exemplo da importância dos atributos de qualidade:

“Sistemas são frequentemente substituídos ou redesenhados não porque suas funcionalidades são deficientes – as substituições geralmente são idênticas em termos de funcionalidades – mas porque eles são difíceis de manter, portar, escalar, ou porque são muito lentos, ou porque foram comprometidos por hackers” (minha tradução).

E apesar de tal importância, muito frequentemente apenas as funcionalidades são observadas em um ciclo de desenvolvimento de software. Especificações comumente não tratam de atributos de qualidade de forma satisfatória, apesar do fato de que tal detalhamento ser de total interesse dos representantes de negócios de uma organização (veja imagem ao lado – provida pelo SEI). E é ai que o papel do arquiteto torna-se importante dentro de um projeto. É do arquiteto a responsabilidade de delinear os atributos de qualidade de um sistema, caso eles não estejam especificados, de entendê-los, especificá-los segundo o conceito SMART e, posteriormente, de endereça-los através de praticas e padrões arquiteturais (veremos este assunto em detalhes mais adiante).

Por enquanto ficaremos por aqui. Nos próximos posts veremos como analisar, registrar e endereçar atributos de qualidade através de táticas arquiteturais. Depois, partiremos para questões especificas de alguns atributos de qualidade mais relevantes, como por exemplo, availability, performance, security, modifiability e testability. Até lá!