Arquitetura de Software
A arquitetura de software é uma subárea da engenharia de software, é uma ponte entre os requisitos e o código (implementação). Quando a arquitetura de software é bem implementada, o resultado é um software que satisfaz as principais exigências do projeto, tais como desempenho, confiabilidade, portabilidade, etc. É a arquitetura de software que define, por meio de diagramas e representações gráficas, a estrutura do software, que compreende os componentes com suas propriedades visíveis externamente e os relacionamentos entre eles.
Logo no início do projeto a arquitetura de software deve buscar estabelecer uma plataforma tecnológica e tratar dos requisitos não funcionais. As preocupações a cerca da arquitetura de software deveriam estar presentes desde o início do projeto até o seu término.
Independente do projeto de software, a arquitetura estará presente, seja de modo acidental (quando existe simplesmente pelas decisões de implementação) ou intencional (quando há preocupação com sua elaboração e manutenção).
A linha divisória entre arquitetura e implementação é bastante tênue, basicamente a implementação é a realização da arquitetura e a arquitetura é o projeto da implementação por meio de artefatos de documentação como, por exemplo, diagramas.
Arquitetura de Software versus Agilidade
A agilidade no desenvolvimento de software se caracteriza principalmente por entregas rápidas e frequentes de software, rápidas respostas as mudanças de requisitos e inicio do desenvolvimento antes do total entendimento.
Equipes ágeis tendem a criar e manter pouca documentação em comparação às equipes com processos mais tradicionais. Este é o principal ponto de conflito entre arquitetura de software e agilidade.
Existem alguns mitos na comunidade de desenvolvimento de software a cerca da arquitetura de software e do desenvolvimento ágil que deixam claro quais são os principais pontos de divergência. A tabela 1 lista alguns mitos de agilidade versus arquitetura de software [7].
Mito | Quem costuma acreditar nisto | Realidade |
Arquitetura de software produz “muito papel”. | Alguns adeptos de métodos ágeis. | O processo de software adotado determina quais documentos são realmente necessários. Comunica-se somente o estritamente necessário. |
Arquitetura de software implica em big design up front (intenção de criar todos os modelos no início do projeto). | Alguns agilistas e arquitetos. | A arquitetura deve respeitar a natureza do método. Em projetos ágeis, a arquitetura do software deve ser evolutiva. |
Requisitos arquiteturais não podem mudar a partir de um certo momento. | Alguns arquitetos e engenheiros de processos. | Métodos ágeis aceitam mudanças a qualquer momento, tendo impacto ou não sobre a arquitetura. O cliente deve sempre estar ciente das consequências de uma mudança de requisito (arquitetural ou não) |
Softwares desenvolvidos com métodos ágeis não tem arquitetura. | Ignorantes da engenharia de software. | Todo software tem uma arquitetura, independente se alguém a projetou intencionalmente ou não. |
“Arquiteto de software é somente um novo e pomposo título que programadores pedem para ter em seus cartões.” Projetos ágeis não precisam do arquiteto. | Alguns adeptos de métodos ágeis. | Vários métodos ágeis prescidem de papéis. Mesmo que ninguém na equipe tenha o papel ou cargo de arquiteto de software, convém planejar a arquitetura. |
Toda a arquitetura deve ser modelada no início do projeto. | Alguns arquitetos de software. | Novamente: o arquiteto deve respeitar a natureza do projeto. Se o método prescreve “prove com código sempre que possível”, é interessante realizar a arquitetura em software executável mesmo que não esteja completamente modelada. |
Conciliando Arquitetura de Software com Agilidade
O entendimento da tabela 1 é um ponto de partida para a conciliação da arquitetura de software com agilidade. As ideias apresentadas deixam claro que os pontos de divergência entre arquitetura de software e agilidade são mitos. O problema é o que as pessoas pensam sobre arquitetura de software e métodos ágeis, em muitas pessoas estão enraizadas as ideias de que métodos ágeis dispensam documentação e de que a arquitetura de software é burocrática e exige muita documentação quando na verdade nenhuma destas ideias está correta.
Um dos pensamentos do manifesto ágil é o de que código funcionando é mais importante do que documentação, mas isto não significa que a documentação deve ser eliminada ou ignorada. O ideal é responder a seguinte pergunta antes de sair criando artefatos ou documentos: “Quem vai usar isto? É útil?”.
Em relação à ideia de que arquitetura de software é burocrática, é preciso deixar claro que a arquitetura de software não é um processo de software. É o processo de software adotado no projeto que é responsável por fornecer o caminho dos artefatos que devem ou não ser criados e como utilizá-los.
Sobre métodos ágeis não darem espaço para arquitetura: a arquitetura de software já está presente em projetos que utilizam métodos ágeis, afinal, como foi dito anteriormente, independente do processo utilizado no projeto de software, a arquitetura estará presente, seja de modo acidental (quando existe simplesmente pelas decisões de implementação) ou intencional (quando há preocupação com sua elaboração e manutenção).
Sintetizando a conciliação de arquitetura e agilidade, a arquitetura não pode ser encarada como um processo de software a ponto de ter artefatos e documentos criados sem utilidade, ela deve respeitar o processo, sendo assim, em métodos ágeis a arquitetura deve ser evolutiva, como manda o processo. A arquitetura deve refletir o projeto atual e acolher as mudanças, pois métodos ágeis aceitam mudanças a qualquer momento. E o mais importante é entender que todo software possui uma arquitetura, seja ela intencional ou não, é importante planejar a arquitetura de forma intencional e não transformá-la em um processo.
Arquitetura de software e agilidade tem o potencial de produzir produtos de software de maior qualidade quando conciliadas, pois como a arquitetura de software já existe mesmo que de forma intencional, se houver algum cuidado especial por parte dos membros da equipe em relação à arquitetura, o resultado será um software com uma arquitetura de maior qualidade e de forma ágil.
Referências bibliográficas
[1] SILVEIRA, Paulo, et al. Introdução à Arquitetura e Design de Software: Uma visão sobre a plataforma Java. 1. ed. São Paulo: Editora Campus, 2012.
[2] ROCHA, Allex Motta Melo. Introdução a Arquitetura de Software. Fábrica de Software do CESUPA – Centro Universitário do Pará
[3] FACUNDES, Prof. Marco. Apresentação: Arquitetura de Software, Fundamentos e Tendências.
[4] SANTOS, Prof. MSc. João Paulo. Arquitetura de Software em Equipes Ágeis: Formas de Trabalho em Projetos de Grande Escala.
[5] SANTOS, Rildo F. Apresentação: Engenharia de Software Ágil: SCRUM e FDD.
[6] ULTREMARE, Fernando. Podemos acabar com o papel do arquiteto em projetos ágeis? InfoQ. Disponível em http://www.infoq.com/br/news/2011/09/arquitetos-agile – Último acesso em 16/10/2012
[7] VIGGIANO, Eros. Agilidade versus Arquitetura de Software. Disponível em http://blog.arkhi.com.br/2009/04/13/agilidade-versus-arquitetura-de-software/ – Último acesso em 16/10/2012
[8] BRIZENO, Marcos. O que é Arquitetura Ágil? Disponível em http://brizeno.wordpress.com/2012/04/18/o-que-e-arquitetura-agil/ – último acesso em 16/10/2012