Arquitetura de Software

Arquitetura de Software 1

Programação Modular 2

Programação Modular Implementação 3

Programação Modular Interface Implementação 4

Programação Modular Interface Provida Implementação Interface Requerida 5

Programação Modular Interface Provida Implementação Visível apenas dentro do Módulo Interface Requerida 6

Benefícios Esperados da Programação Modular [Parnas, 1972] (1) Tempo de desenvolvimento encurtado, já que grupos de desenvolvimento separados podem trabalhar em módulos distintos, com pouca necessidade de comunicação (2) Possibilidade de aplicar mudanças drásticas a um módulo sem a necessidade de mudar outros (3) Possibilidade de estudar o sistema olhando para um módulo de cada vez Interações entre módulos 7

Arquitetura de Software A estrutura de um sistema de software, que engloba componentes de software; suas propriedades visíveis externamente; e os relacionamentos e interações entre eles As primeiras decisões tomadas no projeto de um sistema As mais importantes! Uma arquitetura de software é composta por componentes e conectores 8

Conceitos Arquitetura de software descrição de subsistemas e componentes de um sistema de software e dos relacionamentos entre eles. Projeto arquitetural processo de construção de uma arquitetura de software explícita ligação entre os processos de especificação e de projeto detalhado de software 9 9

Atributos de arquitetura Performance Localizar operações de modo a minimizar a comunicação entre subsistemas Segurança Utilizar uma arquitetura em camadas com recursos críticos localizados em camadas internas Disponibilidade Incluir componentes redundantes na arquitetura Manutenção Utilizar componentes especializados e autocontidos 10 10

Projeto arquitetural Principais atividades Decomposição do sistema de software em subsistemas e componentes Identificação das interações e comunicação entre eles Modelagem arquitetural 11 11

Projeto arquitetural Problemas O projeto de arquiteturas de software específicas (ainda) é baseado em intuição e experiência Métodos pouco ajudam! Documentação (arquitetura e decisões) Modelagem arquitetural 12 12

Uma Arquitetura em Camadas Clientes web (. etc (Mozilla, IE, Internet Servidor WEB Rede Local Banco de Dados Relacional 13

Uma Arquitetura em Camadas Clientes web (. etc (Mozilla, IE, Internet Servidor WEB Rede Local Banco de Dados Relacional Componente Componente Componente 14

Uma Arquitetura em Camadas Clientes web (. etc (Mozilla, IE, Internet Servidor WEB Rede Local Banco de Dados Relacional Conector (HTTP, ( RMI Conector (Ponte ( SQL 15

Projeto Arquitetural O processo de projeto que estabelece Os subsistemas que constituem um sistema A maneira como essas componentes interagem Incluindo algumas decisões tecnológicas Ex. Plataforma de componentes, SGBD A saída desse processo de projeto é uma descrição da arquitetura de software. A arquitetura de software lida com os requisitos não-funcionais do sistema 16

Projeto Arquitetural É o primeiro estágio do projeto do sistema Representa a ligação entre os processos de especificação e de projeto É freqüentemente conduzido em paralelo com algumas atividades de especificação Às vezes junto com a elicitação de requisitos Envolve a identificação dos componentes principais do sistema e sua interação Componentes => unidades de modularidade 17

Vantagens de uma Arquitetura Explícita Comunicação com os stakeholders A arquitetura pode ser usada como um foco de discussão pelos stakeholders do sistema. Análise de sistema Se há possibilidade de o sistema atender a seus requisitos de qualidade (não-funcionais) Reuso em larga escala A arquitetura pode ser reusável em uma variedade de sistemas Suas partes também! 18

Conflitos de arquitetura O uso de componentes de granularidade grossa aprimora o desempenho mas diminui a facilidade de manutenção A introdução de dados redundantes aprimora a disponibilidade, mas torna a proteção mais difícil E cria dificuldades para tornar o sistema confiável em outras partes Localizar as funcionalidades críticas de segurança em poucos locais pode criar gargalos de desempenho Decisões de projeto 19

Decisões de projeto Projeto de arquitetura é um processo criativo Cada sistema envolve diferentes decisões/requisitos/conflitos/restrições Envolve solucionar os problemas representados pelos requisitos Decisões de projeto: Escolhas feitas durante o projeto de um sistema Afetam sua capacidade de fornecer seu serviço Normalmente resultam em compromissos É importante avaliar as opções existentes Não estão restritas ao projeto arquitetural! 20

Exemplos de Decisões de Projeto Como representar o mapa em um sistema que traça rotas percorridas por ônibus de modo a minimizar o trabalho da equipe? Como garantir a confiabilidade de um servidor a um baixo custo? Qual a maneira mais eficiente de se construir uma grade de horários levando-se em conta as várias restrições impostas por professores, diretores e regras departamentais? Qual a melhor tecnologia para se construir uma ferramenta de análise de programas? Como a arquitetura do sistema deve ser documentada? 21

Características de um Sistema que decorrem de sua Arquitetura Desempenho Localizar operações críticas e minimizar comunicações. Usar componentes de fina ao invés de grossa granularidade. Proteção (security) Usar uma arquitetura em camadas com itens críticos nas camadas mais internas. Segurança (safety) Localizar características críticas de segurança em um pequeno número de subsistemas. Disponibilidade Incluir componentes redundantes e mecanismos para tolerância à falhas. Facilidade de manutenção Usar componentes facilmente trocáveis 22

Representação de Arquiteturas Arquiteturas são um ativo importante no desenvolvimento Podem ser a diferença entre o sucesso e o fracasso Representá-las é importante Torna possível falar sobre ela O projeto de arquitetura é normalmente expresso como um diagrama de blocos Modelos mais específicos também podem ser desenvolvidos. 23

Sistema de controle robotizado de empacotamento 24

Diagramas caixa e linha Muito abstrato não mostram a natureza dos relacionamento de componentes, nem suas propriedades externamente visíveis Contudo, são úteis para comunicação com os stakeholders e para planejamento de projeto. Alternativas: Notações formais Notações informais mais organizadas 25

Visões Arquiteturais A arquitetura de um sistema software normalmente é representada através de várias visões Visões são maneiras diversas de se enxergar uma mesma arquitetura Enfocando diferentes aspectos de interesse Ex.: as várias plantas de uma casa Arquiteturas de software são especificadas através de uma ou mais de suas visões 26

Correio Eletrônico Visão 1 Três principais elementos: agentes de usuário (UA). servidores de correio. simple mail transfer protocol: SMTP. servidor de correio SMTP SMTP servidor de correio agente de usuário agente de usuário SMTP fila de mensagens de saída caixa de correio do usuário servidor de correio agente de usuário POP3/IMAP agente de usuário agente de usuário 27

Correio Eletrônico Visão 2 1) Alice usa o UA para compor uma mensagem para bob@someschool.edu 2) O UA de Alice envia a mensagem para o seu servidor de correio; a mensagem é colocada na fila de mensagens. 3) O lado cliente do SMTP abre uma conexão TCP com o servidor de correio de Bob. 4) O cliente SMTP envia a mensagem de Alice através da conexão TCP. 5) O servidor de correio de Bob coloca a mensagem na caixa de entrada de Bob. 6) Bob chama o seu UA para ler a mensagem. 1 user agent mail server 2 3 4 mail server 5 6 user agent 28

Correio Eletrônico Visão 3 Fonte: Axigen Mail Server Documentation - Mail Server Architecture. Consultado em 24 de março de 2008 http://www.axigen.com/docs/en/mail-server-architecture_85.html 29

Um Exemplo de Sistema de Controle de Tráfego Aéreo M&C Console Exceções G.A.M Exceções Exceções Local/Group A.M. O/S E. A. S. Exceções ATC Console A.S.O.U Exceções Exceções Network Operating System Processor I/O Devices Fonte: Bass, Clements, and Kazman, Software Architecture in Practice, 2 nd Edition, 2003. Attachments 30

Sobre Visões Algumas são genéricas Lógica Diagramas de classes e pacotes De interação Diagrama de sequência Física ou de Alocação Diagrama de implantação Outras servem a fins específicos Fluxo de exceções Qualquer dos diagramas acima mostrando apenas componentes associados a exceções (ou ao fim específico em questão) 31

Reuso de arquitetura Sistemas do mesmo domínio freqüentemente têm arquiteturas similares que refletem os conceitos de domínio Resultam em decisões de projeto similares Linhas do produto de software são construídas em torno de um núcleo de arquitetura Variantes satisfazem requisitos de cada cliente. Reuso de arquiteturas é capturado através da noção de padrões ou estilos arquiteturais Próxima aula 32

Padrões e Estilos Arquiteturais 33

Padrões Projetistas e arquitetos experientes procuram aderir a princípios e promover boas práticas de design. usam padrões para documentar e reutilizar experiência comprovadamente boa em novos projetos (de software) Abordagem orientada a problemas 34 34

Estilos Arquiteturais A arquitetura de um sistema pode aderir a um ou mais estilos arquiteturais Um estilo define os tipos de elementos que podem aparecer em uma arquitetura e as regras que regem a sua interconexão Esses estilos pode simplificar o problema de definição de arquiteturas de sistema. A maioria dos sistemas de grande porte adere a vários estilos Estilos arquiteturais = modelos arquiteturais 35

Estilos arquiteturais Shaw and Garlan, 1996 Independent Components Communicating Processes Event-Driven Data Flow Batch Pipes & Filters Data-Centric Repository Blackboard Call & Return Layered systems Object Oriented Main Program & Subroutine Virtual Machine Interpreter Rule-Based 36 36

Exemplos de Estilos Arquiteturais Cliente-Servidor Em camadas Filtros e dutos (pipes and filters) Baseado em repositório Orientado a eventos (publisher/subscriber) Transferência Representacional de Estado (REST) Objetos distribuídos 37

Estilos Arquiteturais e Escolhas de Projto Um estilo arquitetural representa um conjunto de escolhas de projeto Conjunto de características comuns a diversos sistemas nos quais as mesmas escolhas foram feitas Padrões arquiteturais Um sistema aderente a determinado estilo ganha" as características inerentes a ele Estilos podem ser usados para descrever uma determinada arquitetura Foco nas soluções de projeto e não em sua documentação 38

Organização de sistema Reflete a estratégia básica que é usada para estruturar um sistema Exemplos: O estilo de repositório de dados compartilhados Estilo de serviços e servidores compartilhados Estilo de máquina abstrata ou em camadas Orientado a objetos (ou Objetos Distribuídos) Pipes and Filters ou Pipelining 39

Estilo de repositório Sistemas cujas partes precisam trocar dados com frequência: Dados compartilhados podem ser mantidos em um banco de dados central e acessados por todos os subsistemas Cada subsistema mantém seu próprio banco de dados e passa dados para outros subsistemas Podem usar uma abstração de repositório centralizado Implementação distribuída 40

Arquitetura de conjunto de ferramentas CASE 41

Características do Estilo Arquitetural de Repositório Vantagens É uma maneira eficiente de compartilhar grandes quantidades de dados Dados aderem a uma representação comum Simplifica a projeto de aplicações fortemente baseadas em dados Tanto para troca de info. quanto para armazenamento Desvantagens Os subsistemas devem estar de acordo com um modelo de dados padronizado A evolução de dados é difícil e dispendiosa Dificuldade para distribuir de forma eficiente 42

Estilo Cliente-Servidor Mostra como dados e processamento são distribuídos por uma variedade de componentes Servidores independentes que fornecem serviços tais como impressão, transferência de arquivos, gerenciamento de dados, etc. Clientes utilizam esses serviços Clientes e servidores normalmente se comunicam através de uma rede Diversas tecnologias de comunicação são possíveis 43

Biblioteca de filmes e fotografias 44

Vantagens Características do Estilo Cliente-Servidor Separação de interesses Inerentemente distribuído Balanceamento de carga, tolerância a falhas É fácil adicionar novos servidores ou atualizar servidores existentes. Desvantagens Gerenciamento redundante em cada servidor; Nenhum registro central de nomes e serviços pode ser difícil descobrir quais servidores e serviços estão disponíveis Requisições e respostas casadas 45

Modelo de Máquina Abstrata (Em Camadas) Organiza o sistema em um conjunto de camadas (ou máquinas abstratas) Cada uma fornece um conjunto de serviços Cada camada é cliente da camada subjacente Generalização do estilo Cliente-Servidor Não precisa ser distribuído Apóia o desenvolvimento incremental dos subsistemas em camadas diferentes. Ex. Se mudarmos a camada de negócios, só as camadas acima precisam ser modificadas 46

Sistema de gerenciamento de versões 47

Características do Estilo em Camadas Vantagens Facilidade de compreensão Facilidade de manutenção Desenvolvimento independente Desvantagens Duplicação de funcionalidade Às vezes é difícil estruturar um sistema através de camadas É comum que a estruturação seja violada Camadas relaxadas são necessárias Overhead de implementação e desempenho 48

Estilo Arquitetural de Objetos Sistema como um conjunto de objetos fracamente acoplados e com interfaces bem definidas Cada objeto oferece um conjunto de serviços No nível arquitetural, é frequentemente empregado na construção de sistemas distribuídos Objetos distribuídos Uma implementação OO não implica em uma arquitetura OO 49

Sistema de processamento de faturas 50

Características do Estilo Arquitetural de Objetos Vantagens Objetos são fracamente acoplados devido ao uso de interfaces Linguagens de implementação orientada a objeto são amplamente usadas. Desvantagens Mudanças de interface têm alto impacto Não envolve restrições topológicas, o que pode dificultar a manutenção Dependências entre objetos não são limitadas 51

Estilo Dutos e Filtros (Pipelining) Originário de sistemas operacionais UNIX e do projeto de compiladores Transformações funcionais processam entradas para produzir saídas. Componentes são chamados de filtros Conectores são dutos (pipes) Útil para aplicações de processamento de informação que interagem pouco com usuários 52

Sistema de processamento de faturas 53

Características do Estilo Dutos e Filtros Vantagens Apóia reuso de transformações. É fácil adicionar novas transformações. É relativamente simples implementar como sistema concorrente ou seqüencial. Desvantagens Requer um formato comum para a transferência de dados ao longo do pipeline Não é apropriado para aplicações interativas Mais especificamente: só é apropriado para realizar processamento sequencial 54

Fluxo de Controle Estilos arquiteturais relacionados com o fluxo de controle entre os componentes arquiteturais Controle centralizado Um subsistema tem responsabilidade global pelo controle e inicia e para outros sistemas Controle baseado em eventos Cada componente responde a eventos gerados por outros subsistemas 55

Controle centralizado Um componente é responsável pelo gerenciamento da execução de outros componente. O estilo Chamada-Retorno Controle se inicia no topo de uma hierarquia de subrotinas e move-se para baixo na hierarquia. Pode ser sequencial ou concorrente O estilo de Gerenciador Aplicável a sistemas concorrentes e de tempo real Um componente controla a parada, o início e a coordenação de outros processos de sistema 56

Chamada-Retorno 57

Gerenciador para um Sistema Tempo Real Comunicação entre o Controlador e os outros componentes pode ser baseada em eventos, chamadas de procedimentos, etc. 58

Sistemas orientados a eventos Dirigidos por eventos gerados externamente O timing dos eventos está fora do controle dos componentes que os processam Estilo Publisher/Subscriber Eventos são transmitidos a todos os componentes. Qualquer componente interessado pode respondê-los Estilo Orientado a Interrupções Usado em sistemas de tempo real Interrupções são detectadas por tratadores e passadas por outro componente para processamento. 59

Modelo Publisher/Subscriber É efetivo na integração de componentes em computadores diferentes em uma rede Desacoplamento espacial e temporal Componentes não sabem se um evento será tratado e nem quando será. Alguns componentes (publishers) publicam eventos Componentes (subscribers) registram interesse em eventos específicos e podem tratá-los A política de controle não é embutida no tratador de eventos e mensagens 60

Publisher/Subscriber 61

Estilo Orientado a Interrupções Usado em sistemas de tempo real onde a resposta rápida para um evento é essencial Existem tipos de interrupções conhecidos Um tratador definido para cada tipo Cada tipo é associado a uma localização da memória Uma chave de hardware causa a transferência de controle para um tratador. Permite respostas rápidas, mas é complexo para programar e difícil de validar. 62

Controle dirigido a interrupções 63

Arquiteturas de Referência Derivadas de um estudo de domínio de aplicação, ao invés de sistemas existentes. Podem ser usadas como base para a implementação de sistemas ou comparação de sistemas diferentes. Atua como um padrão com relação ao qual os sistemas podem ser avaliados. Exs. Modelo OSI para sistemas de comunicação Organização tradicional de compiladores em vanguarda e retaguarda (e seus elementos internos) 64

Modelo de referência OSI 65

Arquitetura de um Compilador 66

Estilos 67 67

Arquitetura de uma ferramenta CASE Editor de projeto Gerador de código Tradutor de projeto Repositório de projeto Editor de programa Analisador de projeto Gerador de relatório 68 68

Sistema de controle robotizado de Sistema de Visão embalagem Sistema de identificação de objetos Controlador de braço Controlador de garra Sistema de seleção de embalagem Sistema de embalagem Controlador de transportadora 69 69

Cliente-servidor Cliente 1 Cliente 2 Cliente 3 Cliente 4 Rede de banda larga Servidor de catálogo Servidor de vídeo Servidor de fotografias Servidor de hipertexto catálogo Arquivos de clipes de filmes Fotografias digitalizadas Web de hipertexto 70 70

Arquitetura baseada em eventos Subsistema 1 Subsistema 2 Subsistema 3 Subsistema 4 Manipulador de eventos e mensagens 71 71

Questões Como escolher subsistemas e componentes? Quais as suas propriedades? E responsabilidades? Como componentes interagem? Como incorporar e explicitar propriedades não-funcionais? Como descrever uma arquitetura? 72 72

Exemplos 73

100 100

101 101

102 102