Este capítulo continua a discussão de material de apoio concentrando-se em arquiteturas de aplicativos baseados em rede e descrevendo como os estilos podem ser usados para guiar o design arquitetônico.
A arquitetura é encontrada em vários níveis dentro de sistemas de software. Esta dissertação analisa o nível mais alto de abstração em arquitetura de software, onde as interações entre componentes são capazes de ser realizadas em comunicação de rede. Nós limitamos a nossa discussão a estilos de arquiteturas de aplicativos baseados em rede, a fim de reduzir as dimensões de variação entre os estilos estudados.
A distinção primária entre as arquiteturas baseadas em rede e arquiteturas de software em geral é que a comunicação entre os componentes é restrita a passagem de mensagens [6], ou o equivalente a passagem de mensagens se um mecanismo mais eficiente pode ser selecionado no tempo de execução com base na localização de componentes [128].
Tanenbaum e van Renesse [127] fazem uma distinção entre sistemas distribuídos e sistemas baseados em rede: um sistema distribuído é aquele que olha para seus usuários como um sistema centralizado comum, mas é executado em várias CPUs independentes. Em contraste, os sistemas baseados em rede são os que são capazes de operação através de uma rede, mas não necessariamente de uma forma que é transparente para o utilizador. Em alguns casos, é desejável que o usuário esteja consciente da diferença entre uma ação que requer um pedido de rede e um que pode ser satisfeita no seu sistema local, especialmente quando a utilização da rede implica um custo extra de transacção [133]. Esta dissertação abrange os sistemas baseados em rede ao não limitar os estilos candidatos àqueles que preservam transparência para o usuário.
2.2 Avaliando o Design de Arquiteturas de Aplicação
Um dos objetivos deste trabalho é fornecer orientações de design para a tarefa de selecionar ou criar a arquitetura mais adequada para um determinado domínio de aplicação, tendo em mente que uma arquitetura é a realização de um design arquitetônico e não o próprio design. Uma arquitetura pode ser avaliada por suas características de tempo de execução, mas, obviamente, preferimos um mecanismo de avaliação que poderia ser aplicada aos designs arquitetônicos candidatos antes de ter que implementar todos eles. Infelizmente, designs arquitetônicos são notoriamente difíceis de avaliar e comparar de forma objetiva. Como a maioria dos artefatos de design criativo, arquiteturas são normalmente apresentadas como uma obra completa, como se o design simplesmente aparecesse totalmente formado da mente do arquiteto. A fim de avaliar um design arquitetônico, precisamos examinar a lógica (rationale) de design por trás das restrições que ela coloca em um sistema, e comparar as propriedades derivadas desses constrangimentos para os objetivos da aplicação alvo.
O primeiro nível de avaliação é definida pelo conjunto de requisitos funcionais do aplicativo. Por exemplo, não faz sentido para avaliar o design de uma arquitetura de controle de processo contra os requisitos de um sistema hipermídia distribuídos, uma vez que a comparação é discutível caso a arquitetura não funcionar. Embora isso acabe eliminando alguns candidatos, na maioria dos casos outros designs de arquitetura permanecerão e que são capazes de atender às necessidades funcionais da aplicação. O restante se diferencia pela sua ênfase relativa nos requisitos não-funcionais - o grau em que cada arquitetura suportaria em relação as várias propriedades de arquitetura não-funcionais que tenham sido identificadas como necessárias para o sistema. Uma vez que as propriedades são criados pelas restrições arquitetônicas da aplicação, é possível avaliar e comparar diferentes designs arquitetônicos, identificando as restrições dentro de cada arquitetura, avaliando o conjunto de propriedades induzidas por cada restrição e comparando-as com as propriedades cumulativas de design com as propriedades requerida da aplicação.
Conforme descrito no capítulo anterior, um estilo arquitetônico é um conjunto coordenado de restrições arquitetônicas que receberam nomes para facilitar de referência. Cada decisão de design arquitetônico pode ser visto como uma aplicação de um estilo. Uma vez que uma restrição adicionada pode derivar um novo estilo, podemos pensar o espaço de todos os possíveis estilos arquitetônicos como uma árvore de derivação, com sua raiz sendo o estilo nulo (conjunto vazio de restrições). Quando suas restrições não entram em conflito, os estilos podem ser combinados para formar estilos híbridos, eventualmente culminando em um estilo híbrido que representa uma completa abstração do design arquitetônico. Um design arquitetônico pode, portanto, ser analisado por meio da quebra (breaking-down) de seu conjunto de restrições em uma árvore de derivação e da avaliação do efeito cumulativo das restrições representadas por aquela árvore. Se entendermos as propriedades induzidas por cada estilo básico, em seguida, percorrer a árvore de derivação nos dá uma compreensão das propriedades globais dos designs arquitetônicos. As necessidades específicas de uma aplicação podem, em seguida, ser comparados com as propriedades do design. A Comparação torna-se uma questão relativamente simples na identificação de qual design arquitetônico satisfaz as propriedades mais desejadas para essa aplicação.
Deve-se ter cuidado para reconhecer quando os efeitos de uma restrição pode neutralizar os benefícios de alguma outra restrição. No entanto, é possível para um arquiteto de software experiente construir essa árvore de derivação de restrições arquitetônicas para um determinado domínio de aplicativo e, em seguida, usar a árvore para avaliar muitos designs arquitetônicos diferentes para aplicações dentro desse domínio. Assim, a construção de uma árvore de derivação fornece um mecanismo para orientação do design arquitetônico.
A avaliação das propriedades arquitetônicas dentro de uma árvore de estilos é específico para as necessidades de um domínio de aplicação particular porque o impacto de uma dada restrição é muitas vezes dependente das características de aplicação. Por exemplo, o estilo pipe-and-filter permite várias propriedades arquitetônicas positivas quando usado dentro de um sistema que requer transformações de dados entre os componentes, enquanto que acrescentaria nada além de sobrecarga para um sistema que consiste apenas de mensagens de controle. Uma vez que é raramente útil comparar designs de arquitetura em diferentes domínios de aplicação, o meio mais simples de assegurar a coerência é fazer domínio específico da árvore.
A avaliação do design é frequentemente uma questão de escolha entre os trade-offs. Perry e Wolf [105] descreve um método de reconhecimento de trocas (trade-offs) explicitamente por meio da ação de colocar um peso numérico contra cada propriedade para indicar a sua importância relativa à sua arquitetura, proporcionando assim uma medida normalizada para comparação de designs candidatos. No entanto, a fim de ser uma métrica significativa, cada peso teria de ser cuidadosamente escolhido usando uma escala objetiva que é consistente em todas as propriedades. Na prática, não existe tal escala. Ao invés de ter a característica do arquiteto (architect fiddle) com valores de peso até que o resultado corresponda à sua intuição, prefiro apresentar todas as informações ao arquiteto de uma forma facilmente visível e deixar a intuição do arquiteto ser guiada pelo padrão visual. Isto será demonstrado no capítulo seguinte.