Carregar apresentação
A apresentação está carregando. Por favor, espere
PublicouHelena Bardini Gesser Alterado mais de 8 anos atrás
1
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1/41 Análise e Projeto de Sistemas Arquitetura de Software
2
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE2/41 Projeto de arquitetura n Define a estrutura geral de um sistema de software
3
©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
4
©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
5
©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
6
©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
7
©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)
8
©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
9
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE9/41 Modelos Estruturais
10
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE10/41 Exemplo de Modelo Estrutural: Sistema de Controle de um Robot para Empacotamento
11
©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
12
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE12/41 Modelo repositório: Arquitetura de um conjunto de ferramentas CASE
13
©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
14
©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
15
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE15/41 Modelo cliente-servidor: Biblioteca de filmes e fotografias
16
©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
17
©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
18
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE18/41 Modelo de máquina abstrata: Sistema de gerenciamento de versão
19
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE19/41 Modelos de Controle
20
©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
21
©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.
22
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE22/41 Modelo de retorno de chamada (controle centralizado)
23
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE23/41 Sistema de controle de tempo-real (modelo de gerente-centralizado)
24
©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.
25
©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
26
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE26/41 Broadcast seletivo
27
©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
28
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE28/41 Controle dirigido a interrupção
29
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE29/41 Modelos de Decomposição Modular
30
©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
31
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE31/41 Arquiteturas de domínios específicos
32
©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
33
©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
34
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE34/41 Modelo de compilador
35
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE35/41 Sistema de processamento de linguagem
36
©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
37
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE37/41 Modelo OSI de referência
38
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE38/41 Arquitetura de Software no RUP
39
©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
40
©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
41
©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
Apresentações semelhantes
© 2024 SlidePlayer.com.br Inc.
All rights reserved.