Arquitetura de Software (AS) Arquitetura de Software. Motivação para AS. Motivação para AS. Terminologias em AS. Terminologias em AS

Transcrição

1 Requisitos do Sistema Arquitetura de Software Ponte entre os requisitos do sistema e sua implementação Arquiteto(s) Arquitetura Implementação do Sistema Arquitetura de Software (AS) Abstração que ajuda a gerenciar complexidade Projeto Arquitetural do Software Estrutura modular do software Componentes Relacionamento entre componentes Linguagem de Descrição Arquitetural (ADL) descreve a arquitetura do sistema Motivação para AS Programming-in-the-large X Programming-inthe-small (Frank DeRemer and Hans Kron. 1976) Programming-in-the-large: estrutura da aplicação descrevendo a interconexão entre os componentes MILs (Module Interconnection Language): linguagens puramente declarativas para descrever estaticamente a interconexão entre os módulos Programming-in-the-small: código interno do componente ou do módulo Motivação para AS Representação de sistemas informalmente através de caixas e linhas Gerenciamento da complexidade de sistemas Dinamismo Redução do gap entre especificação e implementação Terminologias em AS Estilo Arquitetural ou Padrão Arquitetural ou Estilo (simplesmente): define os tipos de elementos e como eles interagem Ex.: Pipe-Filtros é um estilo que define: Elementos (dois tipos): pipe e filtro. Interação: um pipe pode ser conectado a um filtro mas pipes não podem ser conectados a pipes nem filtros podem ser conectados a filtros Arquitetura: processamento é mapeado em filtros e os pipes agem como condutores de dados Terminologias em AS Arquitetura de Referência ou Arquitetura de Software específica de Domínio: define tipos de elementos e interações permitidas em um domínio particular de aplicações. Ou seja, define como a funcionalidade de um domínio é mapeada em elementos arquiteturais 1

2 Terminologias em AS Arquitetura de uma linha de produtos: É aplicada a um conjunto de produtos dentro de uma organização. Tais produtos compartilham um design comum e, as vezes, parte da implementação Define tipos de elementos e como eles interagem Terminologias em AS As arquiteturas não são mutuamente exclusivas Exemplo: uma arquitetura de linha de produtos pode ser baseada em uma arquitetura de referência e esta, por sua vez, em um estilo arquitetural Arquitetura de Referência Estilo Arquitetural Arquitetura de Linha de Produtos ADLs Específicas para descrição de arquiteturas Expressam características estruturais e comportamentais dos sistemas Permitem reusabilidade Oferecem primitivas para composição do sistema Em geral incluem um formalismo ADLs Características Desejáveis: Suporte a dinamismo Inserir/Remover Componentes e Conexões entre eles Atualizar Componentes Permitir heterogeneidade de padrões e/ou de linguagens Elementos Básicos de ADLs Componentes Conectores Configurações Componentes Blocos de alto nível Oferece Modularidade Separação dos conceitos Publicam a interface Escondem a implementação 2

3 Componentes Interfaces Definem os pontos de acesso ao componente - propriedades visíveis externamente Possibilitam plug-and-play Servem como um contrato entre componentes Interfaces bem definidas tornam fácil a identificação e o propósito do comportamento do componente Podem ser representadas por: Portas, Pontos de Interação, Serviços, etc... (diferentes terminologias e, em alguns casos, diferentes tipos de informações) Exemplo Interface Interface pessoa { string nome; short identidade; long data_de_nascimento; Componentes void add_pessoa(in string nome, in short id, in long data) raises (JaCadastrado) } Componentes Exemplo Interface em MetaH with type package Nav_Types; process interface A is sensor: in port Nav_Types.Rate_Vector; position: out port Nav_Types.ECEF_Type; end A; A Conectores Descrevem as interações e estabelecem restrições de como as mensagens fluem entre os componentes Exemplo: um conector em um sistema clienteservidor descreve o comportamento do cliente como uma sequência de solicitações alternadas com a recepção dos resultados Concentram a informação sobre interconexão e a torna visível e reusável Conectores Conectores ADLs modelam conectores de várias formas: Explicitamente: têm nome e podem ser reusados Exemplos: UniCon, ACME, C2, Wright In-Line: não têm nome e não podem ser reusados Exemplo: Rapide e MetaH Exemplo Conector em ACME Connector rpc = { Roles {caller, callee} Properties { synchronous} Conector em Rapide connect C.Send > B1.Receive 3

4 Configurações Configurações Descrevem a topologia do sistema: os elementos constituintes (componentes e conectores) e como eles estão interconectados para formar a arquitetura B A C D E F Configuração em C2 architecture StackVisualizationArchitecture is components top_most StackADT; internal StackVisualization1; StackVisualization2; bottom_most GraphicsServer; connectors connector TopConnector is message_filter no_filtering end TopConnector; connector BottomConnector is message_filter no_filtering end BottomConnector; architectural_topology connector TopConnector connections top_ports StackADT; bottom_ports StackVisualization1; StackVisualization2; connector BottomConnector connections top_ports StackVisualization1; StackVisualization2; bottom_ports GraphicsServer; end StackVisualizationArchitecture; Exemplo em Wright Exemplos de ADLs Descrição simplificada de um sistema clienteservidor em Wright Style Cliente-Servidor Component Cliente Port p Computation [descrição] Component Servidor Port p Computation [descrição] Connector Cli-Serv Role c Role s Glue [descrição] EndStyle A configuração é uma instância do estilo arquitetural Configuration Cliente-Servidor Style Cliente-Servidor Instances C:Cliente, CS:Cli-Serv, S:Servidor Attachments C.p as CS.c S.p as CS.s End Configuration ADL Organização Referência Objetivos de Design Carnegie Mellon Carnegie Mellon Oferece uma linguagem de intercâmbio ACME para facilitar compartilhamento de University University, 1997 componentes arquiteturais Honeywell Especifica aspectos de tempo real e MetaH Vestal, 1998 Technology concorrência Stanford Luckham et al. Oferece uma ADL executável baseada Rapide em um modelo de execução orientado a University 1995 eventos Carnegie Mellon Shaw and Garlan, Suporta contrução arquitetural baseada UniCon University 1996 em estilo interconectando componentes Carnegie Mellon Allen and Garlan Oferece um formalismo que foca nos Wright University 1997 tipos explícitos de conectores Classificação de ADLs De acordo com o relacionamento entre a descrição arquitetural e a implementação do sistema Linguagens independentes de implementação Wright, Rapide Problema: Erosão Arquitetural => não correspondência entre descrição arquitetural e implementação do sistema Linguagens limitadas a implementação: UniCon Padrões Endereçam uma classe de problemas recorrentes e apresenta uma solução para eles (podem ser considerados um par problema-solução) Permitem a construção de software com propriedades definidas Ajudam na construção de arquiteturas de software complexas e heterogêneas Ajudam a gerenciar a complexidade do software 4

5 Anti-Padrões Mostram o insucesso da aplicação de uma padrão em determinadas classes de problemas Podem ser de dois tipos: Descrevem uma solução ruim para um problema Descrevem como escapar de uma solução ruim e a partir dela chegar em uma solução boa para um problema Categorias de Padrões Padrão Arquitetural ou Estilo Arquitetural Padrão de Design (Design Patterns) Idiomas Categorias de Padrões ESTILOS ARQUITETURAIS PADRÕES DE DESIGN IDIOMAS Padrões Arquiteturais Expressam um esquema de organização para sistemas de software Arquitetura de Software Orientada a Padrões Maneira de documentar arquiteturas de software Oferece templates para arquiteturas de software concretas que são um conjunto de regras predefinidas que especificam as responsabilidades e a organização dos relacionamentos entre as partes constituintes Os subsistemas da arquitetura de software bem como os relacionamentos entre eles, consistem de várias unidades arquiteturais menores. Tais unidades são descritas usando design patterns. Oferece um esquema para refinar os subsistemas São menores em escala que padrões arquiteturais mas estão em um nível mais alto que idiomas específicos de linguagens de programação Não tem efeito na estrutura fundamental do software (arquitetura) mas tem forte influência na arquitetura de um subsistema São independentes de um domínio particular da aplicação pois tratam com a estruturação da funcionalidade da aplicação e não com a implementação da funcionalidade 5

6 Categorias: Decomposição Estrutural: padrões que permitem uma decomposição adequada de subsistemas e componentes complexos em partes cooperantes Organização do Trabalho: padrões que definem como componentes colaboram para resolver um problema complexo Controle de Acesso: padrões que guardam e controlam o acesso a serviços ou componentes Gerenciamento: padrões que gerenciam uma coleção homogênea de objetos, serviços e componentes Comunicação: padrões que ajudam a organizar comunicação entre os componentes Decomposição Estrutural Decompor sistemas em partes menores facilita a realização de mudanças e extensões e tornam os sistemas mais fáceis de compreender Whole-Part (Todo-Parte) ajuda a agregar componentes para juntos formar uma unidade Composite organiza objetos em estruturas de árvore que representa uma hierarquia Decomposição Estrutural Whole-Part Um componente agregado (o whole) encapsula os componentes constituintes (o part) organiza uma interface comum Clientes enxergam o objeto agregado (whole) como um objeto atômico que não permite acesso direto às partes Decomposição Estrutural Whole-Part Exemplo: Objetos gráficos como círculos, linhas, retângulos, triângulos, etc podem ser agrupados em uma classe base chamada GraphicsObject que define métodos comuns como draw e rotate. Organização do Trabalho Decompor sistemas complexos através da cooperação de componentes Master-Slave (Mestre-Escravo) oferece suporte para computação paralela e tolerância a falhas. Aplica a idéia do princípio de Dividir e Conquistar onde o trabalho é dividido em subtarefas que são processadas independentemente Organização do Trabalho Master-Slave Um componente master (mestre) distribui trabalho a componentes slaves (escravos) que realizam a computação o componente master divide o trabalho em subtarefas iguais e delega as sub-tarefas aos componentes escravos que são semanticamente idênticos 6

7 Organização do Trabalho Master-Slave Exemplo: Problema do Caixeiro-Viajante (problema de teoria dos grafos) que deve encontrar o menor caminho entre duas cidades que visite cada cidade apenas 1 vez. (problema NP-completo) O tamanho das diferentes rotas é calculado em paralelo pelos escravos. Controle de Acesso Em algumas situações um servidor ou mesmo um sistema inteiro não deve estar acessível diretamente pelos clientes. Exemplo: nem todos os clientes estão autorizados a usar os serviços de um componente ou recuperar uma informação particular que o componente oferece Proxy é um padrão de design que faz com que clientes de um componente comunique-se com um representante ao invés de comunicar-se com o próprio componente Controle de Acesso Proxy Introduz um representante (proxy) que serve para muitos propósitos incluindo facilidade de acesso e proteção contra usuários não autorizados O proxy oferece uma interface para acesso ao componente e realiza processamento adicional (p.ex.: verificação de controle de acesso) O proxy é associado com o componente original através de um handle, que pode ser um ponteiro, um endereço, um identificador, um socket. Proxy Controle de Acesso Cliente Proxy Componente serviço resposta Pré-processamento serviço Pós-processamento Controle de Acesso Proxy Exemplo: Um proxy Firewall realiza a proteção contra potenciais acessos hostis ao ambiente. O proxy Firewall é, em geral, implementado como um processo daemon na máquina firewall que pode ser também chamado de proxy server. Todos os clientes acessam os serviços de uma rede via o proxy. O proxy rejeita solicitações que não obedecem a política de acesso da rede. Comunicação Existem muitos mecanismos de comunicação entre processos: sockets, RPC, TLI, etc. O uso de um mecanismo de comunicação específico pode tornar difícil mudança na aplicação posteriormente (p.ex. em casos de migração de uma rede para outra) 7

8 Comunicação Um padrão de design para comunicação pode permitir o desacoplamento entre componentes de um sistema distribuído e mecanismos usados para comunicação Dois aspectos importantes: encapsulamento do mecanismo de comunicação e transparência de localização Comunicação Publisher-Subscriber Mantém a sincronização entre os componentes cooperantes. Um publisher notifica os subscribers sobre mudanças no seu estado. Idiomas Idiomas É um padrão de baixo-nível específico para uma linguagem de programação Descreve como implementar aspectos particulares dos componentes ou relacionamentos entre eles usando as características de uma dada linguagem Podem endereçar a implementação de um padrão de design específico Há muitas maneiras de se resolver um problema usando uma dada linguagem. Exemplo: Implementação de cópia de string em C/C++ Os programas copiam o string s para o string d até encontrar um caracter com valor 0. void strcopykr(char *d, const char *s) { while (*d++=*s++); } Ambas seguem seu próprio estilo void strcopypascal(char d[], const char s[]) { int i; for (i=0; s[i]!= \0 ; i=i+1) { d[i] = s[i]; } d[i] = \0 ; } 8