Apesar do interesse em arquitetura de software como um campo de pesquisa, há pouco consenso entre os pesquisadores quanto ao que exatamente deve ser incluída na definição de arquitetura. Em muitos casos, isso levou os aspectos de importantes projetos arquitetôticos serem negligenciados por pesquisas anteriores. Este capítulo define uma terminologia auto-consistente para a arquitetura de software baseada na avaliação de definições existentes na literatura e minha própria visão no que diz respeito à arquiteturas de aplicativos baseados em rede. Cada definição, destacados em uma caixa de texto para facilitar a referência, é seguida por uma discussão de onde ela foi derivada, ou a qual se compara, em relação a pesquisa relacionada.
A arquitetura de software é uma abstração dos elementos de tempo de execução (run-time) de um sistema de software durante alguma fase de sua operação. Um sistema pode ser composto de diversos níveis de abstração e muitas fases da operação, cada um com sua própria arquitetura de software.
No coração da arquitetura de software, é o princípio da abstração: esconder alguns dos detalhes de um sistema por meio de encapsulamento, a fim de melhor identificar e sustentar suas propriedades [117]. Um sistema complexo irá conter vários níveis de abstração, cada um com sua própria arquitetura. Uma arquitetura representa uma abstração do comportamento do sistema no seu próprio nível, de modo a que elementos arquitetônicos são delineadas pelas interfaces abstratas que prestam aos outros elementos a esse nível [9]. Dentro de cada elemento pode ser encontrada outra arquitetura, definindo o sistema de sub-elementos que implementam o comportamento representado pela interface abstrata do elemento pai. Esta recursão de arquiteturas continua até os elementos mais básicos do sistema: aqueles que não podem ser decompostos em elementos menos abstratos.
Além níveis de arquitetura, um sistema de software, muitas vezes, têm múltiplas fases operacionais, tais como start-up, a inicialização, o processamento normal, re-inicialização e desligamento. Cada fase operacional tem sua própria arquitetura. Por exemplo, um arquivo de configuração será tratado como um elemento de dados durante a fase de start-up, mas não será considerado um elemento arquitectônico durante o processamento normal, uma vez que nesse momento a informação que continha já terá sido distribuído por todo o sistema. Isto pode, de fato, ter definido a arquitetura de processamento normal. Uma descrição geral de uma arquitetura de sistema deve ser capaz de descrever não só o comportamento operacional da arquitetura do sistema durante cada fase, mas também a arquitetura de transições entre as fases.
Perry e Wolf [105] definem elementos de processamento como "transformadores de dados", enquanto Shaw et al. [118] descrevem componentes como "o locus da computação e do Estado". Isto é melhor esclarecido em Shaw e Clements [122]: "Um componente é uma unidade de software que executa alguma função em tempo de execução (run-time). Exemplos incluem programas, objetos, processos e filtros". Isto levanta uma importante distinção entre arquitetura de software e o que é normalmente referido como estrutura de software: a primeira é uma abstração do comportamento de tempo de execução (run-time) de um sistema de software, enquanto a segunda é uma propriedade do código-fonte do software estático. Embora haja vantagens em se ter a estrutura modular do código-fonte em harmonia com a decomposição de comportamento de um sistema em execução, também há vantagens em ter componentes de software independentes sendo implementados usando partes do mesmo código (por exemplo, bibliotecas compartilhadas). Separamos o ponto de vista de arquitetura de software da do código-fonte, a fim de concentrarmos em características de tempo de execução (run-time) do software independentes da execução de um determinado componente. Portanto, design de arquitetura e design estrutural de código-fonte, embora intimamente relacionados, são atividades de design de software separadas. Infelizmente, algumas descrições de arquitetura de software não conseguem fazer essa distinção (por exemplo, [9]).
Uma arquitectura de software é definido por uma configuração dos elementos de arquitetura - componentes, conectores e dados - restritas em suas relações a fim de alcançar um conjunto desejado de propriedades de arquitectura.
Um exame abrangente do escopo e base intelectual para a arquitetura de software pode ser encontrado em Perry e Wolf [105]. Eles apresentam um modelo que define uma arquitetura de software como um conjunto de elementos arquitetônicos que têm uma forma particular, explicados por um conjunto de lógica (rationale). Os elementos arquitetônicos incluem o processamento, dados e elementos de ligação. Forma é definida pelas propriedades dos elementos e as relações entre os elementos - ou seja, as restrições relativas aos elementos. A lógica (rationale) fornece a base subjacente para a arquitetura, capturando a motivação para a escolha do estilo arquitetônico, a escolha de elementos, e a forma.
Minhas definições para arquitetura de software são uma versão elaborada das descritas no modelo de Perry e Wolf [105], exceto o fato de eu excluir a lógica (rationale). Embora lógica (rationale) seja um aspecto importante para a pesquisa de arquitetura de software e da descrição da arquitetura em particular, incluindo-a na definição de arquitetura de software implicaria que a documentação de design do projeto seja parte do sistema de tempo de execução (run-time). A presença ou ausência de lógica (rationale) pode influenciar na evolução de uma arquitetura, mas, uma vez constituída, a arquitetura é independente das suas razões de existir. Sistemas reflexivos [80] podem usar as características de desempenho passado para mudar o comportamento futuro, mas ao fazê-lo estão substituindo uma arquitetura de nível inferior com uma outra arquitetura de nível mais baixo, em vez de lógica (rationale) abrangente dentro dessas arquiteturas.
Como ilustração, considere o que acontece a um edifício, se seus projetos e planos de design são queimados. O edifício irá desmoronar imediatamente? Não, desde que as propriedades pelas quais as paredes sustenta o peso do telhado permanecerem intactos. Uma arquitetura tem, pelo design, um conjunto de propriedades que lhe permitem atender ou exceder os requisitos de sistema. A ignorância dessas propriedades pode levar a alterações posteriores que violam a arquitetura, assim como a substituição de um muro de suporte de carga, com uma grande moldura da janela pode violar a estabilidade estrutural de um edifício. Assim, em vez de lógica (rationale), a nossa definição de arquitetura de software inclui propriedades arquitetônicas. A lógica (rationale) fundamenta essas propriedades, e falta de lógica (rationale) pode resultar na deterioração gradual ou degradação da arquitetura ao longo do tempo, mas a lógica (rationale), propriamente dita, não faz parte da arquitetura.
Uma característica fundamental do modelo em Perry e Wolf [105] é a distinção dos vários tipos de elementos. Elementos de processamento são aqueles que executam transformações em dados, elementos de dados são aqueles que contêm a informação que é usada e transformada e elementos de ligação são a cola que mantém as diferentes peças da arquitetura juntas. Eu uso os termos mais prevalentes de componentes e conectores para me referir a elementos de processamento e de ligação, respectivamente.
Garlan e Shaw [53] descrevem uma arquitetura de um sistema como um conjunto de componentes computacionais em conjunto com uma descrição das interacções entre estas componentes - os conectores. Este modelo é abordado mais profundamente em Shaw et al. [118]: A arquitetura de um sistema de software define o sistema, em termos de componentes e de interacções entre esses componentes. Além disso, para especificar a estrutura e topologia do sistema, a arquitectura mostra a correspondência pretentendia entre os requisitos de sistema e elementos de sistema construído. O desenvolvimento mais avançado desta definição pode ser encontrada em Shaw e Garlan [121].
O que é surpreendente sobre o modelo de Shaw et al. [118] é que, em vez de definir a arquitetura de software como existindo dentro do software, ele está definindo uma descrição da arquitetura de software como se isso fosse a arquitetura. No processo, a arquitetura de software como um todo é reduzida ao que é comumente encontrada em mais informais diagramas de arquitetura: caixas (componentes) e linhas (conectores). Os elementos de dados, juntamente com muitos dos aspectos dinâmicos de arquiteturas de software real, são ignorados. Tal modelo é incapaz de descrever adequadamente as arquiteturas de software baseadas em rede, uma vez que a natureza, localização e movimento dos elementos de dados dentro do sistema são, muitas vezes, os únicos e mais relevantes determinantes do comportamento do sistema.
Um componente é uma unidade abstrata de instruções de software e um estado interno que proporciona uma transformação de dados através de sua interface.
Componentes são aspectos mais facilmente reconhecidos na arquitetura de software. Os elementos de processamento de Perry e Wolf [105] são definidos como aqueles componentes que fornecem a transformação em elementos de dados. Garlan e Shaw [53] descrevem componentes simplesmente como os elementos que realizam computação. A nossa definição tenta ser mais preciso em fazer a distinção entre os componentes e o software dentro de conectores.
Um componente é uma unidade abstrata de instruções de software e um estado interno que proporciona uma transformação de dados através de sua interface. Exemplos de transformações incluem carregar na memória de armazenamento secundário, realizar alguns cálculos, traduzindindo para um formato diferente, encapsulamento com outros dados, etc. O comportamento de cada componente é parte da arquitetura enquanto o comportamento pode ser observado ou discernido a partir do ponto de vista de um outro componente de [9]. Em outras palavras, um componente é definido pela sua interface e os serviços que ele fornece a outros componentes, em vez de pela sua aplicação por trás da interface. Parnas [101] definiria isto como o conjunto de pressupostos que outros elementos arquitetônicos podem construir em relação a outros componente.
Um conector é um mecanismo abstrato que intermedia a comunicação, a coordenação ou a cooperação entre os componentes.
Perry e Wolf [105] descrevem elementos de ligação vagamente como a cola que mantém as várias partes da arquitetura juntos. Uma definição mais precisa é fornecida por Shaw e Clements [122]: Um conector é um mecanismo abstrato que intermedia a comunicação, a coordenação ou a cooperação entre os componentes. Exemplos incluem representações compartilhadas, chamadas de procedimento remoto, protocolos de transmissão de mensagens e fluxos de dados.
Talvez a melhor maneira de pensar sobre conectores é contrastá-las com os componentes. Conectores habilitam a comunicação entre os componentes através da transferência de elementos de dados de uma interface para uma outra, sem alterar os dados. Internamente, um conector pode ser constituído por um subsistema de componentes que transformam os dados para a transferência, efetuam a transferência, e, em seguida, a transformação inversa de entrega. No entanto, a abstração do comportamento externo capturado pela arquitetura ignora esses detalhes. Em contraste, um componente pode, mas não sempre, transformar os dados a partir da perspectiva externa.
Um dado (datum) é um elemento de informação que é transferida a partir de um componente, ou recebida por um componente, através de um conector.
Como observado acima, a presença de elementos de dados é a diferença mais significativa entre o modelo de arquitetura de software definido por Perry e Wolf [105] e o modelo utilizado por grande parte da pesquisa de arquitetura de software marcado em [1, 5, 9, 53, 56, 117-122, 128]. Boasson [24] critica a pesquisa atual de arquitetura de software pois a sua ênfase em estruturas de componentes e ferramentas de desenvolvimento de arquitetura, sugerindo que mais foco deveria ser dado em modelagem arquitetônica centrada em dados. Comentários similares são feitas por Jackson [67].
Um dado (datum) é um elemento de informação que é transferida a partir de um componente, ou recebida por um componente, através de um conector. Exemplos incluem sequências de byte (byte-sequences), mensagens, parâmetros mobilizados e objetos serializados, mas não incluem informações que são residentes permanentemente ou escondidas dentro de um componente. Do ponto de vista arquitetônico, um "arquivo" é uma transformação que um componente do sistema de arquivos pode fazer a partir dos dados recebidos de um "nome de arquivo" em sua interface para uma seqüência de bytes gravados dentro de um sistema de armazenamento escondido internamente. Os componentes também podem gerar dados, como no caso de um encapsulamento de um relógio ou sensor.
A natureza dos elementos de dados dentro de uma arquitetura de aplicativo baseada em rede, muitas vezes, determinará um determinado estilo arquitetônico é apropriado ou não. Isto é particularmente evidente na comparação dos paradigmas de design de codificação de códigos móveis [50], em que a escolha deve ser feita entre interagir com um componente diretamente ou transformar o componente em um elemento de dados, transferindo-o através de uma rede, e em seguida, transformá-lo de volta a um componente que pode ser interagido localmente. É impossível avaliar tal arquitetura sem considerar os elementos de dados a nível arquitetônico.
Uma configuração é a estrutura das relações entre os componentes arquitetônicos, conectores e dados durante um período de tempo de execução do sistema.
Abowd et al. [1] definem a descrição arquitetônica como o apoio à descrição dos sistemas em termos de três classes sintáticas básicas: componentes, que são o locus da computação; conectores, que definem as interações entre os componentes e configurações, que são coleções de componentes e conectores que se interagem. Várias notações concretas de estilos específicos podem ser usadas para representar estas classes sintáticas básicas visualmente, facilitar a descrição dos cálculos legais e interações, e restringir o conjunto de sistemas desejáveis.
Falando de maneira restrita, pode-se pensar em uma configuração como sendo equivalente a um conjunto de restrições específicas sobre a interação de componentes. Por exemplo, Perry e Wolf [105] incluem topologia em sua definição de relações de formas arquitetônicas. No entanto, separando a topologia ativa de restrições mais generalizadas permite que um arquiteto de diferencie a configuração ativa do domínio em potencial de todas as configurações legítimas. Lógica (rationale) adicional para distinguir configurações dentro de linguagens de descrição de arquitetura é apresentado em Medvidovic e Taylor [86].
O conjunto de propriedades arquitetônicas de uma arquitetura de software inclui todas as propriedades que derivam da seleção e disposição dos componentes, conectores e dados do sistema. Exemplos incluem tanto as propriedades funcionais adquiridas pelo sistema e propriedades não-funcionais, tais como a facilidade relativa de evolução, a reutilização de componentes, eficiência e extensibilidade dinâmica, frequentemente referidos como atributos de qualidade [9].
Propriedades são induzidas pelo conjunto de restrições dentro de uma arquitetura. As restrições são, muitas vezes, motivadas pela aplicação de um princípio de engenharia de software [58] com um aspecto dos elementos de arquitectura. Por exemplo, o estilo pipe-and-filter uniforme obtém as qualidades de reutilização de componentes e configurabilidade da aplicação através da aplicação generalidade a suas interfaces de componentes - restringindo os componentes de um único tipo de interface. Assim, a restrição de arquitectura é componente de interface uniforme, motivada por princípio a generalidade, a fim de obter duas qualidades desejáveis que se tornarão as propriedades de arquitetura de componentes reutilizáveis e configuráveis quando esse estilo é instanciado dentro de uma arquitetura.
O objetivo do design arquitetônico é criar uma arquitetura com um conjunto de propriedades arquitetônicas que formam um superconjunto dos requisitos do sistema. A importância relativa das diferentes propriedades de arquitetura depende da natureza do sistema a que se destinam. A [Seção 2.3](Capítulo 2#2.3 Architectural Properties of Key Interest) examina as propriedades que são de interesse particular para arquiteturas de aplicativos baseados em rede.
Um estilo arquitetônico é um conjunto coordenado de restrições arquitetônicas que se restringe as funções/características de elementos arquitetônicos e as relações permitidas entre esses elementos dentro de qualquer arquitetura que está em conformidade com esse estilo.
Uma vez que uma arquitectura incorpora propriedades funcionais e não-funcionais, pode ser difícil comparar arquiteturas de diferentes tipos de sistemas diretamente, ou até mesmo para o mesmo tipo de sistema descrito em ambientes diferentes. Estilos são um mecanismo para categorizar arquiteturas e definir as suas características comuns [38]. Cada estilo fornece uma abstração para as interações de componentes, capturando a essência de um padrão de interação, ignorando os detalhes incidentais do resto da arquitetura [117].
Perry e Wolf [105] definem estilo arquitetônico como uma abstração de tipos de elementos e aspectos formais de várias arquiteturas específicas, talvez concentrando-se em apenas determinados aspectos de uma arquitetura. Um estilo arquitetônico encapsula decisões importantes sobre os elementos arquitetônicos e enfatiza restrições importantes relativas aos elementos e seus relacionamentos. Esta definição permite que estilos se concentrem apenas nos conectores de uma arquitetura, ou sobre aspectos específicos das interfaces de componentes.
Em contraste, Garlan e Shaw [53], Garlan et al. [56] e Shaw e Clements [122], todos, definem o estilo em termos de um padrão de interações entre componentes tipados. Especificamente, uma arquitetura determina o vocabulário de componentes e conectores que podem ser utilizados em instâncias daquele estilo, juntamente com um conjunto de restrições de como eles podem ser combinados [53]. Esta visão restrita de estilos arquitetônicos é um resultado direto de sua definição de arquitetura de software - pensamento em arquitetura como uma descrição formal, em vez de como um sistema em execução, leva a abstrações com base em apenas nos padrões compartilhados de diagramas de caixa e linha. Abowd et al. [1] vão ainda mais longe e definem isso explicitamente como a visualização da coleção de convenções que são usadas para interpretar uma classe de descrições arquiteturais como a definição de um estilo arquitetônico.
Novas arquiteturas pode ser definidas como instâncias de estilos específicos [38]. Desde de que estilos arquitetônicos possam abordar diferentes aspectos da arquitetura de software, uma dada arquitetura pode ser composta por vários estilos. Da mesma forma, um estilo híbrido pode ser formado por uma combinação de múltiplos estilos básicos em um único estilo coordenado.
Alguns estilos arquitetônicos são colocados, frequentemente, como soluções de "bala de prata" para todas as formas de software. No entanto, um bom designer deve escolher um estilo que corresponda às necessidades do problema específico a ser resolvido [119]. Escolher o estilo arquitetônico correto para uma aplicação baseada em rede requer um entendimento do domínio do problema [67] e, assim como as necessidades de comunicação da aplicação, uma consciência da variedade de estilos arquitetônicos e as preocupações específicas que se referem, e a capacidade de antecipar a sensibilidade de cada estilo interação com as características da rede de comunicação baseados em rede [133].
Infelizmente, usando o temo estilo para se referir a um conjunto coordenado de restrições muitas vezes leva à confusão. Este uso difere substancialmente da etimologia de estilo, que enfatizaria personalização do processo de design. Loerke [76] dedica um capítulo para denegrir a noção de que as preocupações estilísticas pessoais tem um lugar qualquer no trabalho de um arquiteto. Em vez disso, ele descreve estilos como a visão crítica de arquitetura passada, onde a escolha de materiais disponíveis, a cultura da comunidade ou o ego do governante local ram responsáveis pelo estilo arquitetônico, e não o designer. Em outras palavras, Loerke vê a verdadeira fonte de estilo na arquitetura de construções tradicional como sendo o conjunto de restrições aplicadas ao design e alcançar ou copiar um estilo específico deveria ser o menor dos objetivos do designer. Desde de que se referir a um conjunto nomeado de restrições como um estilo faz com que seja mais fácil se comunicar as características de restrições comuns, usamos estilos arquitetônicos como um método de abstração, e não como um indicador de design personalizado.
Em paralelo com a pesquisa em engenharia de software sobre estilos arquitetônicos, a comunidade de programação orientada a objetos tem explorado o uso de padrões de design e padrões linguagens para descrever abstrações recorrentes no desenvolvimento de software baseado em objeto. Um padrão de design é definido como sendo importante e recorrente na construção de um sistema. Uma linguagem padrão é um sistema de padrões organizados em uma estrutura que orienta a aplicação dos padrões [70]. Ambos os conceitos são baseados nos escritos de Alexander et al. [3, [4](Referências.md#4] no que diz respeito à construção de arquitetura.
O espaço de design de padrões inclui preocupações específicas no que diz respeito a aplicação de técnicas de programação orientada a objetos, tais como herança de classe e composição de interface, bem como as questões de alto nível de design abordados pelos estilos arquitetônicos [51]. Em alguns casos, as descrições de estilos arquitetônicos foram reformuladas como padrões de arquitetura [120]. No entanto, uma vantagem principal dos padrões é que elas podem descrever protocolos relativamente complexos de interações entre objetos como uma única abstração [91], incluindo, assim, ambas as restrições sobre o comportamento e especificações da implementação. Em geral, um padrão, ou linguagem de padrão, no caso de múltiplos padrões integrados, pode ser pensado como uma receita para a implementação de um conjunto desejado de interações entre os objetos. Em outras palavras, um padrão define um processo para resolver um problema seguindo um caminho de projeto e escolhas de implementação [34].
Como estilos arquitetônicos de software, a pesquisa de padrões de software se desviou um pouco desde a sua origem na construção de arquitetura. De fato, a noção de padrões de Alexander gira em torno de arranjos de elementos arquitetônicos recorrentes, mas sim sobre o padrão recorrente de eventos - a atividade humana e a emoção - que ocorrem dentro de um espaço, com o entendimento de que um padrão de eventos não pode ser separado do espaço onde ocorre [3]. A filosofia de design de Alexander é identificar padrões de vida que são comuns à cultura-alvo e determinar quais as restrições de arquitetura necessários para diferenciar um determinado espaço de tal forma que permita que os padrões desejados corram naturalmente. Tais padrões existem em vários níveis de abstração e em todas as escalas.
Como um elemento do mundo, cada padrão é uma relação entre um determinado contexto, um determinado sistema de forças que ocorre repetidamente nesse contexto e uma determinada configuração espacial que permite que estas forças se resolvam.
Como um elemento da linguagem, um padrão é uma instrução que mostra como essa configuração espacial pode ser utilizado, uma e outra vez, para resolver o dado sistema de forças, onde quer que o contexto se faça relevante.
O padrão é, em suma, ao mesmo tempo uma coisa que acontece no mundo e a regra que nos diz como criar aquela coisa, e quando devemos criá-la. É, ao mesmo tempo, um processo e uma coisa; tanto uma descrição de uma coisa que está viva e uma descrição do processo que irá gerar essa coisa. [3]
De muitas formas, os padrões de Alexander têm mais em comum com estilos arquitetônicos de software do que os padrões de design da pesquisa de OOPL (linguagem de programação de orientação a objetos). Um estilo arquitetônico, como um conjunto coordenado de restrições, é aplicado a um espaço de design a fim de induzir as propriedades arquitetônicas que são desejadas do sistema. Ao aplicar um estilo, um arquiteto estará diferenciando o espaço de design de software na esperança de que o resultado será melhor combinado com as forças inerentes à aplicação, levando assim ao comportamento do sistema que aumenta o padrão natural, em vez de entrar em conflito com ele.
Um ponto de vista arquitetônico é muitas vezes específico de aplicação e varia amplamente com base no domínio de aplicação. ... Vimos pontos de vista arquitetônicos que abordam uma variedade de questões, incluindo: questões temporais, abordagens de estado e controle, representação de dados, ciclo de vida de transação, garantias de segurança e picos de de demanda e degradação. Sem dúvida, existem muitos mais pontos de vista possíveis. [70]
Além das muitas arquiteturas dentro de um sistema, e os diversos estilos arquitetônicos de que as arquiteturas são compostas, também é possível ver uma arquitetura de muitas perspectivas diferentes. Perry e Wolf [105] descrevem três visões importantes na arquitetura de software: processamento, dados e visualizações de conexão. Uma visão de processo enfatiza o fluxo de dados através dos componentes e alguns aspectos das ligações entre os componentes em relação aos dados. A visão de dados enfatiza o fluxo de processamento, com menos ênfase nos conectores. Uma visão de conexão enfatiza a relação entre os componentes e o estado de comunicação.
Várias visões de arquitetura são comuns dentro de estudos de caso de arquiteturas específicas [9]. Uma metodologia de design arquitetônico, o 4+1 View Model [74], organiza a descrição de uma arquitetura de software utilizando cinco pontos de vista simultâneos, cada um dos quais aborda um conjunto específico de preocupações.
Incluo aqui apenas as áreas de pesquisa que definem arquitetura de software ou descrevem os estilos de arquitetura de software. Outras áreas de pesquisa de arquitetura de software incluem técnicas de análise de arquitetura, arquitetura de recuperação e re-engenharia, ferramentas e ambientes para o design arquitetônico, arquitetura refinamento da especificação para implementação e estudos de caso de arquiteturas de software implementados [55]. Trabalhos relacionados nas áreas de classificação de estilo, paradigmas de processo distribuídos e middleware são discutidos no [Capítulo 3](Capítulo 3.md).
A maioria das primeiras pesquisas de arquitetura de software foram concentradas em metodologias de design. Por exemplo, o design da orientação a objetos [25] defende uma forma de estruturar problemas que naturalmente leva a uma arquitetura baseada em objeto (ou, mais precisamente, não conduz naturalmente a qualquer outra forma de arquitetura). Uma das primeiras metodologias de design que enfatizam o design em um nível arquitetônico é Jackson Desenvolvimento de Sistemas [30]. JSD estrutura intencionalmente a análise de um problema para que ele leve a um estilo de arquitetura que combina pipe-and-filter (fluxo de dados) e as restrições de controle de processo. Estas metodologias de projeto tendem a produzir apenas um estilo de arquitetura.
Tem havido alguns trabalhos iniciais que investigam metodologias para a análise e o desenvolvimento de arquiteturas. Kazman et al. descreveram métodos de design para elicitar os aspectos arquitetônicos de um design através da análise baseada em cenários com SAAM [68] e análise de trade-off arquitetônico via ATAM [69]. Shaw [119] compara uma variedade de designs do estilo caixa-e-flecha (box-and-arrow) para um sistema de controle de cruzeiro automóvel, cada feito usando uma metodologia de design diferente e abrangendo vários estilos arquitetônicos.
Shaw [117] defende o desenvolvimento de manuais de arquitetura ao longo das mesmas linhas das disciplinas tradicionais de engenharia. A comunidade de programação orientada-a-objeto assumiu a liderança na produção de catálogos de padrões de design, como exemplificado pelo livro Gang of Four [51] e os ensaios editados por Coplien e Schmidt [33].
Padrões de design de software tendem a ser mais do que estilos arquitetônicos orientados por problema. Shaw [120] apresenta oito exemplo padrões de arquitetura com base nos estilos arquitetônicos descritos em [53], incluindo informações sobre os tipos de problemas mais adequados para cada arquitetura. Buschmann et al. [28] apresentam uma análise abrangente dos padrões arquitetônicos comuns para o desenvolvimento baseado em objetos. Ambas as referências são meramente descritivas e não fazem nenhuma tentativa de comparar ou ilustrar as diferenças entre os padrões arquitetônicos.
Tepfenhart e Cusick [129] usam um mapa dimensional dois para demonstrar as diferenças entre taxonomias de domínio, modelos de domínio, estilos arquitetônicos, frameworks, kits, padrões de design e aplicações. Na topologia, padrões de design são estruturas de design predefinidos usados como blocos de construção para uma arquitetura de software, enquanto estilos arquitetônicos são conjuntos de características operacionais que identificam uma família de arquitetura independente de domínio do aplicação. No entanto, eles falham ao definir a arquitetura em si.
1.8.3 Modelos de Referência e Arquiteturas de Software de Domínio Específico (DSSA - Reference Models and Domain-specific Software Architectures)
Os modelos de referência são desenvolvidos para fornecer estruturas conceituais para descrever arquiteturas e mostrando como os componentes são relacionados entre si [117]. A Arquitetura de Gerenciamento de Objeto (OMA - Object Management Architecture), desenvolvida pela OMG [96] como um modelo de referência para arquiteturas de objetos distribuídos e intermediados, especifica como os objetos são definidos e criados, como aplicações cliente invocam objetos e como os objetos podem ser compartilhados e reutilizados. A ênfase está no gerenciamento de objetos distribuídos, ao invés de interação aplicação eficiente.
Hayes-Roth et al. [62] definem a arquitetura de software de domínio específico (DSSA) como compreendendo: a) uma arquitetura de referência, que descreve um framework geral computacional para um domínio importante das aplicações, b) uma biblioteca de componentes, que contém pedaços reutilizáveis de perícia do domínio e c) um método de configuração da aplicação para selecionar e configurar os componentes dentro da arquitetura para atender aos requisitos específicos da aplicação. Tracz [130] fornece uma visão geral de DSSA.
DSSA projetos foram bem sucedidos na transferência de decisões de arquitetura de sistemas em execução, por da restrição do espaço de desenvolvimento de software a um estilo arquitetônico específico que corresponda aos requisitos de domínio [88]. Exemplos incluem ADAGE [10] para sistemas de avião (aviônicos), AIS [62] para sistemas inteligentes adaptativos e MetaH [132] para sistemas de orientação de mísseis, navegação e controle. DSSA enfatizam a reutilização de componentes dentro de um domínio de arquitetura comum, em vez de selecionar um estilo de arquitetura que é específico para cada sistema.
A maioria das obras publicadas recententemente relacionadas a arquiteturas de software é na área de linguagens de descrição de arquitetura (ADL). Uma ADL é, de acordo com Medvidovic e Taylor [86], uma linguagem que proporciona recursos para a especificação explícita e modelagem de arquitetura conceitual de um sistema de software, incluindo, no mínimo: componentes, interfaces de componentes, conectores e configurações arquitetônicas.
Darwin é uma linguagem declarativa que se destina a ser uma notação de uso geral por especificar a estrutura de sistemas compostos por diversos componentes, utilizando diversos mecanismos de interacção [81]. As qualidades interessantes de Darwin são que ela permite a especificação de arquiteturas distribuídas e arquiteturas compostas de forma dinâmica [82].
UniCon [118] é uma linguagem e um conjunto de ferramentas associadas para compor uma arquitetura de um conjunto restrito de exemplos de componentes e conectores. Wright [5] fornece uma base formal para especificar as interações entre componentes de arquitetura, especificando os tipos de conectores pelos seus protocolos de interação.
Como metodologias de design, ADLs muitas vezes introduz pressupostos arquitetônicos específicos que podem impactar em sua capacidade de descrever alguns estilos arquitetônicos e podem entrar em conflito com os pressupostos em middleware existentes [38]. Em alguns casos, uma ADL é desenvolvida especificamente para um único modelo de arquitetura, melhorando assim a sua capacidade para a descrição e análise especializada no custo de generalidade. Por exemplo, C2SADEL [88] é um ADL concebida especificamente para descrever arquiteturas desenvolvidas no estilo C2 [128]. Em contraste, a ACME [57] é uma ADL que tenta ser o mais genérica possível, mas mantendo o trade-off que ele não suporta análise específica de estilo e a construção de aplicações reais; em vez disso, seu foco é sobre o intercâmbio entre as ferramentas de análise.
Abowd et al. [1] afirmam que estilos arquitetônicos pode ser descritos formalmente por meio de um pequeno conjunto de mapeamentos a partir do domínio sintático de descrições arquiteturais (diagramas caixa e linha) para o domínio semântico do significado arquitetônico. No entanto, isso pressupõe que a arquitetura é a descrição, em vez de uma abstração de um sistema em execução.
Inverardi e Wolf [65] usam o formalismo da Máquina de Abstrações Químicas - Chemical Abstracts Machine (CHAM) para modelar elementos de arquitetura de software como é feito com produtos químicos cujas reações são controladas por regras explicitamente declaradas. Ele especifica o comportamento dos componentes de acordo com a maneira que eles transformam elementos de dados disponíveis e usam regras de composição para propagar as transformações individuais em um resultado geral do sistema. Embora este seja um modelo interessante, não é claro o modo como CHAM poderia ser utilizado para descrever qualquer forma de arquitetura cuja finalidade vai além de transformar um fluxo de dados.
Rapide [78] é uma linguagem concorrente e baseada em eventos projetada especificamente para a definição e simulação de arquiteturas de sistema. O simulador produz um conjunto parcialmente ordenado de eventos que podem ser analisados para a conformidade com as restrições arquitetônicas relativas à interconexão. Le Métayer [75] apresenta um formalismo para a definição de arquiteturas em termos de grafos e gramáticas de grafos.
Este capítulo examinou o conteúdo de apoio desta dissertação. Apresentar e formalizar um conjunto consistente de terminologia para os conceitos de arquitetura de software são necessários para evitar a confusão entre arquitetura e descrição de arquitetura que é comum na literatura, particularmente desde que grande parte da pesquisa prévia excluem os dados como um elemento arquitetônico importante. Uma conclusão minha através de um levantamento de outras pesquisas relacionadas à arquitetura de software e estilos arquitetônicos.
Os próximos dois capítulos continuam a nossa discussão de material de apoio, concentrando-se em arquiteturas de aplicativos baseados em rede e descrevem como os estilos podem ser usados para guiar seus designs arquitetônicos, seguido de um levantamento de estilos arquitetônicos comuns usando uma metodologia de classificação, que destaca as propriedades arquitetônicas induzidas quando os estilos são aplicados a uma arquitetura para hipermídia baseado em rede.