©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/41 Análise e Projeto de Sistemas Arquitetura de Software

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE2/41 Projeto de arquitetura n Define a estrutura geral de um sistema de software

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE3/41 Objetivos n Introduzir o projeto de arquitetura e seu papel no processo de software n Descrever diferentes modelos de arquitetura e explicar quando eles são necessários n Discutir como modelos de referência de domínios específicos podem ser usados para comparar arquitetura de software

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE4/41 O que é projeto arquitetural? n Representa um link entre os processos de especificação e de projeto de software n Geralmente ocorre em paralelo com atividades de especificação n Preocupa-se em identificar os macro componentes (sub-sistemas ou módulos) de um sistema e suas comunicações

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE5/41 Vantagens da definição de uma arquitetura n Comunicação entre os stakeholders  A arquitetura pode ser usada como foco de uma discussão entre os stakeholders n Análise do sistema  É possível analisar se o sistema irá satisfazer alguns dos requisitos não-funcionais n Reuso em larga escala  A mesma arquitetura pode ser reusada em vários sistemas

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE6/41 Sub-sistemas e módulos n Um sub-sistema é também um sistema cuja operação é independente dos serviços providos por outros sub-sistemas n Um módulo é um componente do sistema que provê serviços a outros componentes mas que normalmente não seria considerado um sistema separado

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE7/41 Modelos arquiteturais n O projeto de arquitetura pode ser baseado num modelo ou estilo específico de arquitetura. n Contudo, a maioria dos sistemas são heterogêneos, ou seja, diferentes partes do sistema são baseados em diferentes modelos e, em alguns casos o sistema pode seguir um modelo composto n O modelo escolhido afeta os requisitos não- funcionais (ex: performance, segurança, disponibilidade, manutenabilidade e distributividade)

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE8/41 Modelos arquiteturais n Diferentes modelos ou estilos arquiteturais podem ser produzidos durante o projeto arquitetural n Cada um dos modelos representa diferentes perspectivas da arquitetura. Ex:  Modelos estruturais estáticos - mostram os principais sub- sistemas ou componentes do sistema  Modelos de controle - lidam com fluxo de controle entre sub- sistemas.  Modelos de decomposição modular - outro nível estrutural onde sub-sistemas são decompostos em módulos

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE9/41 Modelos Estruturais

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE10/41 Exemplo de Modelo Estrutural: Sistema de Controle de um Robot para Empacotamento

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE11/41 O modelo de repositório n Sub-sistemas devem compartilhar dados. Isto pode ser feito de duas formas:  O dado compartilhado é colocado num banco de dados ou repositório, podendo ser acessado por todos os sub- sistemas  Cada sub-sistema mantém seu próprio banco de dados independente e passa dado explicitamente para os outros sub-sistemas n Quando a quantidades de dados compartilhados é grande, o modelo de repositório compartilhado é mais apropriado

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE12/41 Modelo repositório: Arquitetura de um conjunto de ferramentas CASE

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE13/41 Características do modelo de repositório n Vantagens  Forma eficiente de compartilhar grandes quantidades de dados  Sub-sistemas que produzem dados não precisam se preocupar onde e como os dados são usados  Gerenciamento centralizado ex. backup, segurança, etc.  O modelo de compartilhamento é tornado público através do esquema do repositório n Desvantagens  Sub-sistemas devem concordar no modelo de dados do repositório. Inevitavelmente um compromisso.  A evolução dos dados é difícil e cara  Não há espaço para políticas específicas de gerenciamento  Dificuldade de distribuição efetiva de dados em máquinas distintas

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE14/41 Arquitetura cliente-servidor n Modelo de sistema distribuído que mostra como dados e processamento são distribuídos entre um número de componentes (processadores) n Conjunto de servidores separados que provêem serviços específicos tais como impressão, gerenciamento de dados, etc. n Conjunto de clientes que usam estes serviços n Rede permite que clientes acessem os servidores

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE15/41 Modelo cliente-servidor: Biblioteca de filmes e fotografias

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE16/41 Características do cliente-servidor n Vantagens  A distribuição dos dados é feita de forma natural  Faz uso efetivo de sistemas em rede.  Fácil de adicionar novos servidores ou atualizar os atuais servidores n Desvantagens  Como não há modelo de dados compartilhado, sub-sistemas podem organizar dados de forma diferente. Troca de dados pode ser ineficiente  Gerenciamento redundante em cada servidor  Como não há registro central de nomes e serviços, pode ser difícil saber quais servidores e serviços estão disponíveis

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE17/41 Modelo de máquina abstrata n Usado para modelar o interfaceamento entre sub- sistemas n Organiza o sistema num conjunto de camadas (ou máquinas abstratas), cada uma provendo um conjunto de serviços n Suporta o desenvolvimento incremental de sub- sistemas em camadas diferentes. Quando uma interface de uma camada muda, somente a camada adjacente é afetada n Contudo, geralmente é difícil estruturar sistemas desta forma

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE18/41 Modelo de máquina abstrata: Sistema de gerenciamento de versão

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE19/41 Modelos de Controle

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE20/41 Modelos de controle n Tipos de Controle:  centralizado èUm sub-sistema tem responsabilidade geral pelo controle de ativação e desativação de outros sub-sistemas  baseado em eventos èCada sub-sistema pode responder a eventos gerados externamente por outros sub-sistemas ou pelo ambiente do sistema

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE21/41 Controle centralizado n Dividem-se em duas categorias:  Modelo de retorno de chamada èSe aplica a sistemas seqüenciais. Modelo de sub-rotina top-down, onde o controle começa no topo de uma hierarquia de sub-rotinas e move em direção para baixo.  Modelo de gerente èUm componente do sistema controla a parada, início e coordenação de outros processos do sistema. Pode ser implementado em sistemas seqüenciais através de sentenças “case”, mas também pode ser aplicado a sistemas concorrentes.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE22/41 Modelo de retorno de chamada (controle centralizado)

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE23/41 Sistema de controle de tempo-real (modelo de gerente-centralizado)

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE24/41 Controle baseado em eventos n Dirigidos por eventos gerados externamente, onde a ocorrência do evento está fora do controle dos sub- sistemas que processam o evento. n Dois modelos principais  Modelo broadcast. Um evento é enviado para todos os sub- sistemas. Qualquer dos sub-sistemas que trate o evento poderá fazê-lo.  Modelos dirigidos a interrupção. Usado em sistemas de tempo-real, onde interrupções são detectadas por um gerenciador de interrupções e repassadas para algum outro componente para processamento.

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE25/41 Modelo Broadcast (controle baseado em evento) n Efetivo na integração de sub-sistemas em diferentes computadores de uma rede n Sub-sistemas registram um interesse em um evento específico. Quando ele ocorre, o controle é transferido para o sub-sistema que pode tratar o evento n A política de controle não está embutida no controlador de mensagens e eventos. Os sub-sistemas decidem quais eventos são de seu interesse. n Contudo, sub-sistemas não sabem se e quando um evento será tratado

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE26/41 Broadcast seletivo

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE27/41 Sistemas dirigidos a interrupção (controle baseado em evento) n Usado em sistemas de tempo real onde a resposta rápida a um evento é essencial n Existem tipos conhecidos de interrupção com um manipulador definido para cada tipo n Cada tipo está associado com uma localidade de memória e um interruptor de hardware causa a transferência para seu manipulador n Permite resposta rápida, porém complexo para programar e difícil de validar

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE28/41 Controle dirigido a interrupção

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE29/41 Modelos de Decomposição Modular

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE30/41 Decomposição modular n Dois tipos de decomposição abordados  Um modelo objeto onde o sistema é decomposto em objetos que interagem  Um modelo de fluxo de dados onde o sistema é decomposto em módulos funcionais que transformam entradas em saídas. Também conhecido como modelo pipeline

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE31/41 Arquiteturas de domínios específicos

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE32/41 Arquiteturas de domínios específicos n Modelos que são específicos para algum domínio de aplicação n Dois tipos de modelo de domínio específico  Modelos genéricos que são abstrações de um número real de sistemas e que encapsulam as principais características destes sistemas  Modelos de referência que são mais abstratos, modelos idealizados. Permitem comparar diferentes arquiteturas n Modelos genéricos são normalmente bottom-up; Modelos de referência são top-down

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE33/41 Modelos genéricos (Arquitetura de domínio específico) n Modelo de um compilador é bem conhecido, embora outros modelos existam em domínios de aplicação mais especializados  Lexical analyser  Symbol table  Syntax analyser  Syntax tree  Semantic analyser  Code generator n Um compilador genérico pode ser organizado de acordo com diferentes modelos de arquitetura

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE34/41 Modelo de compilador

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE35/41 Sistema de processamento de linguagem

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE36/41 Modelos de referência n Modelos de referência são derivados de estudos do domínio de aplicação em vez de modelos existentes n Pode ser usado como base para uma implementação do sistema ou para comparar sistemas diferentes. Funciona como um padrão contra o qual os sistemas podem ser avaliados n Ex: O Modelo OSI é um modelo de camadas para sistemas de comunicação

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE37/41 Modelo OSI de referência

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE38/41 Arquitetura de Software no RUP

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE39/41 O modelo de “4+1 Visões” Topologia, implantação, comunicação Visão de Implementação Visão Lógica Visão de Distribuição Visão de Processos Visão de Casos de Uso Analista de Sistemas Arquiteto Estrutura Programadores Arquiteto Escalabilidade Estrutura, componentes Arquiteto

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE40/41 Pontos principais n O arquiteto de software é responsável por projetar a arquitetura do sistema n Grandes sistemas raramente estão de acordo com um único modelo de arquitetura n Modelos estruturais incluem modelos de repositórios, modelos cliente-servidor e modelos de máquinas abstratas n Modelos de controle incluem controle centralizado e modelo dirigido por evento

©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE41/41 Pontos principais n Decomposição modular inclui fluxo de dados e modelo objeto n Modelos de arquitetura de domínios específicos são abstração de domínios de aplicação. Eles podem ser construídos a partir da abstração de sistemas existentes ou podem ser modelos idealizados