Desenvolvimento Ágil de Arquiteturas de Software

O objetivo deste artigo é abordar os princípios para a construção de arquiteturas de software através do desenvolvimento ágil.
Há mais de 30 anos, o foco do desenvolvimento de software estava na produção final deles. Se o software está pronto vamos executá-lo e, até mesmo, colocá-lo em produção.
Processos e metodologias começaram a ser criados para focar no planejamento do que deveria constar no software – os chamados requisitos. A partir deste ponto, tudo começaria a ficar mais difícil, pois o cliente começou a modificar em tempo de desenvolvimento os requisitos do software, e os desenvolvedores não estavam preparados para lidar com tal demanda de modificações.
Mesmo com processos burocráticos mais rígidos o desenvolvimento do software continuou caótico, o foco eram os processos e atividades a serem desempenhadas para se obter um resultado, porém deveriam ser direcionados às pessoas e ferramentas que realizariam tais atividades dentro de processos simples para obter resultados, utilizando ferramentas coerentes em cada ciclo da iteração.

Portanto, o desenvolvimento ágil criado a partir de práticas, princípios e valores, originou-se como reação à estes primeiros processos, sendo assim, mais leves e menos rígidos, focando nas pessoas e ferramentas, documentação necessária, colaboração do cliente e mudanças de requisitos para a confecção do software.
Um dos pontos mais importantes do desenvolvimento ágil é a construção de arquiteturas em ciclos iterativos garantindo a robustez e clareza diante das grandes mudanças de requisitos durante todo o processo.

A arquitetura é a base para todo o software. Componentes, interfaces, comunicação externa ao software são peças reutilizáveis que garantem agilidade, reusabilidade e robustez no desenvolvimento do software.

Mas, o que é Arquitetura de Software?

Arquitetura de software conceitua o estudo da organização global dos sistemas de software bem como do relacionamento entre seus subsistemas e componentes, permite entender a estrutura dos componentes de um sistema e seus inter-relacionamentos, especialmente daqueles atributos que são consistentes ao longo do tempo e de implementações.
A arquitetura de software engloba o conjunto de decisões significativas sobre a organização dos sistemas informatizados e divide-se em três partes:

  • Arquitetura Técnica de Concepção: apresenta uma visão relativa ao conjunto de decisões, padrões, roteiros e design patterns requeridos para construir uma aplicação. Pode-se dividir em: biblioteca de componentes, especificações verticais do domínio, frameworks customizados, biblioteca de patterns e bibliotecas de serviços.
  • Arquitetura de Infra-estrutura Coorporativa: arquitetura que descreve a infra-estrutura coorporativa na qual será implantado o sistema.
  • Arquitetura de Infra-estrutura do Sistema: arquitetura que descreve o sistema e qual infra-estrutura deve ser implantada para o funcionamento do sistema.

Princípios do Desenvolvimento Ágil de Arquiteturas

O desenvolvimento ágil conceitua a construção da arquitetura do software por iterações. A cada iteração são aplicados princípios, práticas e padrões para a resolução dos requisitos do dia. O objetivo é não perder tempo construindo uma arquitetura que atenderá todo o software, mas, a arquitetura que atenderá o software hoje e amanhã.

Ao planejar os requisitos de um software usando uma metodologia ágil deve-se definir em tempo a palavra amanhã. Pode-se defini-la em horas, dias ou até mesmo em semanas.

Porém, deve-se tomar alguns cuidados ao desenvolver a arquitetura utilizando os conceitos da metodologia ágil para não obter sintomas o que levará  o software ao fracasso, são eles:

  • Rigidity – é difícil alterar a arquitetura;
  • Fragility – a arquitetura torna-se frágil a qualquer problema;
  • Immobility – alto acoplamento da arquitetura, o que dificulta o reuso;
  • Viscosity – é difícil fazer a coisa certa;
  • Needless Complexity – complexidade desnecessária da arquitetura;
  • Needless Repetition – repetição desnecessária de estruturas na arquitetura, falta de abstração;
  • Opacity – é difícil ler e entender a arquitetura.

Os princípios do desenvolvimento ágil de arquiteturas são conceituados no paradigma de objetos. O design orientado a objetos foi fruto de pensamentos e textos por muitos desenvolvedores e pesquisadores. Os princípios ajudam os desenvolvedores a eliminar os sintomas e a construir a melhor arquitetura para estar aderente aos requisitos do software.

SRP – The Single Responsibility Principle

Este princípio conceitua o relacionamento entre os elementos de uma estrutura (módulo, conjunto de classes, etc.) da arquitetura. Quanto maior a responsabilidade de uma estrutura, maior a necessidade de separá-la. Para esta solução podem-se utilizar abstrações como: interfaces ou generalizações. Diminuir o acoplamento das responsabilidades é garantir que sintomas – Rigidity e Fragility – não apareçam na arquitetura do software.

OCP – The Open-Closed Principle

Ao modificar um software, adicionando novas funcionalidades, todas as estruturas da arquitetura dependentes serão alteradas em cascata. Esta afirmação diz respeito à violação do princípio Open-Closed. Este princípio conceitua que qualquer modificação da arquitetura para atender novas funcionalidades, não causa alteração de funcionalidades que já funcionam, não impacte em todo o resto. Todas as estruturas – classes, módulos, funções, etc. – devem estar abertas para extensão (open for extension) de novas funcionalidades ou ações e fechadas para as modificações (Closed for modification). Os atributos destacados acima são primordiais para este princípio:

  • Open for Extension – pode-se estender o comportamento das estruturas (Ex.: módulos). Pode-se alterar o que o módulo faz.
  • Closed for Modification – alterando-se o comportamento do módulo não resulta na alteração no código-fonte. O código-fonte sempre ficará intocável.

A chave deste princípio são a abstração e o polimorfismo para a implementação de estruturas da arquitetura.

LSP – The Liskov Substitution Principle

Este princípio conceitua os tipos de hierarquia que podem ser substituíveis por seus tipos base. Permite a modificação do comportamento de estruturas (módulos). O baixo acoplamento entre os módulos é a chave para a aplicação deste princípio.

DIP – The Dependency-Inversion Principle

Este princípio conceitua-se em duas afirmações:

  • Estruturas da arquitetura de alto nível não devem depender de estruturas de baixo nível da arquitetura. Os dois níveis devem ser dependentes de abstrações.
  • Abstrações não devem ser dependentes dos detalhes do software. Os detalhes devem depender das abstrações.

Módulos de alto nível detêm decisões de controle e regras de negócios do software. Estes módulos não podem ter dependências com módulos de baixo nível, pois, qualquer modificação nestes módulos, afetará diretamente os módulos de alto nível.

ISP – The Interface-Segregation Principle

Este princípio conceitua a falha do uso de interfaces que agregam muitas ações (métodos) e não são coesivas. Interfaces que agregam muitas ações devem ser quebradas em grupos de interfaces, pois, cada grupo servirá um cliente. Os clientes devem conhecer apenas as ações pertinentes ao seu negócio. Um modo simples de encapsulamento é o uso dos patterns MVP (Model-View-Presenter) e MVC (Model-View-Controller).

Conclusão

O desenvolvimento ágil de arquiteturas de software é um processo que envolve princípios, padrões e práticas para melhorar a estrutura e readaptabilidade de um software. É manter a arquitetura do software o mais simples, compreensível e significativo possível.
Como exemplo de conceito, a metodologia ágil eXtreme Programming conceitua que a construção de uma arquitetura de software deve ser simples e significativa. Portanto, a arquitetura é construída apenas com as estórias especificadas por cada iteração, visando a migração de arquitetura (deixando-a melhor) para as próximas iterações do projeto.

Assim, os times XP nunca irão construir uma arquitetura por sua infra-estrutura ou por seu middleware. Os times irão agir sobre o conjunto de estórias, especificando a arquitetura mais simples possível. A especificação da infra-estrutura da arquitetura será implementada quando as estórias levarem o time a especificá-la.

Alguns conceitos chaves para a construção de arquiteturas:

  • Consider the Simplest Thing That Could Possibly Work – times XPs tentam encontrar a solução mais simples para a construção de uma arquitetura.
  • You Aren’t Going To Need It – times XPs sabem que irão precisar de persistência em Banco de Dados, ou suportar múltiplos usuários, mas será que é preciso implementar neste momento do projeto? Esta é a pergunta que deve ser feita antes de implementar qualquer alteração na arquitetura.
  • Once and Only Once – desenvolvedores XPs não toleram códigos duplicados. Por isso, a regra é eliminar código duplicado assim que for achado.

Referências

5 Comentários

  • Reply

    Por Rogerio Santos em 3 de November de 2012 às 22:27

    Muito interessante o texto. Muito instrutivo e agradável de ler

  • Reply

    Por Marcio Duran em 19 de May de 2014 às 16:56

    Digamos, que sou um investidor e quero iniciar uma StartUp , e não conheça nada sobre processo ágil ou desenvolvimento de Software, mas queria estar presente em passos na entrega de valores na incubadora responsável por desenvolver a solução em software desejada. Como isso funcionaria ? Que papel eu teria no modelo de Scrum ?

    • Reply

      Por Fabio A. Falavinha em 4 de June de 2014 às 11:20

      Você pode atuar como observador no Sprint Review e pode participar e intervir na Restrospectiva.

      O scrum tem que ser entre o interessado no produto/software e quem o faz. A menos que o produto seja para uso da incubadora, o Scrum seria melhor usado entre a start up e o cliente real. Mas ai existem problemas de discloser que a incubadora pode não querer que seja visível a existência da startup. É um problema politico que só se resolve caso a caso e não ha uma receita geral.

      O modelo ágil nesse caso não seria tão vantajoso para você. Talvez um modelo como Agile Unified Process ajudaria neste caso seria melhor. Clique no link abaixo e dê uma lida a respeito deste modelo. Lá você conseguirá descobrir o seu papel (role) dentro do processo.

      Agile Unified Process – AUP

  • Reply

    Por Kleber em 24 de June de 2014 às 17:40

    Olá Amigo,

    Muito bom seu texto, estou iniciando em metodos ageis e gostaria de entender alguma a diferença entre Design ágil e arquitetura ágil, posso considerar a mesma coisa?

  • Reply

    Por Fabio A. Falavinha em 27 de February de 2015 às 14:21

    Olá Kleber,

    Ao se deparar com a prática Agile Design você terá que fazer alguma modelagem na arquitetura.

    Lembre-se que design é referente ao modelo de classes, entidades, serviços, ou seja, a abstração que você criará para resolver o problema.

    Já em arquitetura, você terá que modelar além de referências ao software, como: transação. Em design você terá que modelar e implementar o controle e gerenciamento de transações, mas é na arquitetura que você terá que tomar decisões como:
    - Usar transação do container onde a minha aplicação está em execução;
    - Ou simplesmente, usar diretamente do código.

    Os dois métodos são bons, porém cada um dentro do seu caso de uso.

    Acesse o link abaixo para mais detalhes:

    http://agilemodeling.com/essays/agileDesign.htm

    Espero que ajude.

    Um grande abraço





Desenvolvido por hacklab/ com WordPress