decisões de design articuladas que determinam as principais propriedades comportamentais e estruturais de um programa (sistema de software). Decisões estratégicas abordam preocupações globais, de todo o sistema e trazem as implicações mais conseqüentes. As decisões estratégicas incluem a escolha do paradigma de programação (“programação orientada a objetos”), estilo arquitetônico (“pipes and filters”), estrutura de aplicação (“Microsoft Foundation Classes”), padrões de engenharia de software baseados em componentes (“Enterprise JavaBeans”), e princípios de projeto (“classe base universal”), bem como suposições que podem levar a um descompasso arquitetônico (“The Softbench Broadcast Message Server expects all of the components to have a graphical user interface”) e regularidades governadas por lei (“cada classe do sistema herda da classe C”). Por causa das conseqüências que carregam, decisões estratégicas devem ser tomadas cedo no processo de desenvolvimento de software e devem ser estabelecidas explicitamente antes de qualquer projeto detalhado ser realizado.
Em contraste, declarações de projeto tático articulam decisões de projeto que estão relacionadas com um módulo específico. As decisões tácticas descrevem frequentemente um padrão de correlações entre uma colecção de módulos (objectos, procedimentos, classes, etc.) e outro. Intuitivamente falando, as declarações táticas são ‘locais’ no sentido de que seu escopo é limitado a alguma parte do programa e não fora dele. As decisões táticas incluem a escolha de padrões de design (“Factory Method”), refatorações (“Replace Conditional With Polymorphism”) e expressões idiomáticas de programação (“counted pointer”), e geralmente são tomadas muito mais tarde do que as decisões estratégicas de design no processo de desenvolvimento de software.
Embora eu concorde amplamente com a regra geral de global = estratégico e local = tático, ele não deve ser considerado um absoluto. É possível que um segmento de um sistema tenha aspectos que influenciam fortemente a arquitetura geral (justificando os critérios de significância de Booch). Esta é a razão pela qual eu não tenho a opinião de que requisitos funcionais são design e não funcionais são arquitetura.
Arnon Rotem-Gal-Oz, gerente de arquitetura da Nice Systems, identifica vários aspectos da arquitetura em sua apresentação “Arquitetura de Software”. A arquitetura compreende os principais componentes de um sistema; suas relações e interações. Os dados e o comportamento desses componentes principais só são relevantes para a arquitetura do ponto de vista das interações entre esses componentes. Como Booch, a Rotem-Gal-Oz caracteriza a arquitetura como sendo as partes mais difíceis de mudar do sistema. Como Eden, Kazman e Hirshfeld, ele define arquitetura como as decisões de design que devem ser tomadas o mais cedo possível no processo.
O valor das decisões estratégicas e fundacionais de design deve ser óbvio. Como esses aspectos do sistema são difíceis e caros de mudar, deve haver um incentivo considerável para se fazer escolhas ótimas. Como observado por Kevlin Henney em “What is Software Architecture?” no developerFusion:
A questão não é se um sistema tem arquitetura, mas se sua arquitetura é boa ou não. Todos os sistemas têm arquitetura, seja intencional ou acidental, explícita ou implícita, boa ou ruim – mesmo os sistemas “sem arquitetura” têm arquitetura!
Aparando a arquitetura relacionada ao custo da mudança, temos uma forma simples de avaliar a qualidade arquitetônica. Não é que uma boa arquitetura torne um sistema barato de criar; é que também é barato de evoluir. Em outras palavras, uma boa arquitetura é aquela em que o significado das decisões de design é minimizado. Você é livre para mudar muitos aspectos de um sistema sem o medo de que tais mudanças sejam desafiadoras, caras ou criem uma cascata de bugs. Uma boa arquitetura é, portanto, uma arquitetura sustentável.
Dada a criticidade dessas decisões de design, faz pouco sentido deixá-las ao acaso. Arquitetura sustentável e flexível é pouco provável que surja organicamente. Será necessário um planejamento e coordenação suficientes de alguém na função de arquiteto (independentemente de a função ser em tempo integral ou parcial). Decisões de projeto localizadas podem então ser tomadas dentro dessa estrutura de forma descentralizada.
Ocasionalmente ouço pessoas ainda levantando o mantra ágil contra o Big Design/Requirements Up Front. O problema é que o Agile Manifesto nunca disse para enterrar intencionalmente sua cabeça na areia com relação ao propósito do sistema. Foi um empurrão contra passar meses em análise sem nada além de documentos saindo, mas o objetivo era chegar a um meio-termo. Nunca ninguém disse “sem design à frente” ou “sem requisitos à frente”.
(Udi Dahan de “Uma Viagem CQRS – com e sem Microsoft”)
Reposted from Form Follows Function