Upload
others
View
7
Download
0
Embed Size (px)
Citation preview
1
Arquitetura de Software
2
Programação Modular
3
Implementação
Programação Modular
4
Implementação
Interface
Programação Modular
5
Implementação
Interface Provida
Interface Requerida
Programação Modular
6
Implementação
Interface Provida
Interface Requerida
Visível
apenas
dentro do
Módulo
Programação Modular
7
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
8
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
Arquitetura de Software
9
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
10
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 auto-contidos 10
11
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
12
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
13
Clientes web (Mozilla, IE, etc.)
Servidor WEB Rede Local
Banco de Dados Relacional
Internet
Uma Arquitetura em Camadas
14
Componente Componente Componente
Clientes web (Mozilla, IE, etc.)
Servidor WEB Internet Rede
Local
Banco de Dados Relacional
Uma Arquitetura em Camadas
15
Banco de Dados Relacional
Conector (Ponte SQL)
Conector (HTTP, RMI)
Clientes web (Mozilla, IE, etc.)
Servidor WEB Rede Local
Internet
Uma Arquitetura em Camadas
16
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
17
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
18
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!
19
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
20
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!
21
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?
22
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
23
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.
24
Sistema de controle robotizado de
empacotamento
25
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
26
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
27
Três principais elementos:
agentes de usuário (UA).
servidores de correio.
simple mail transfer protocol:
SMTP.
caixa de correio do usuário
fila de mensagens
de saída
agente de
usuário
servidor de correio
SMTP
SMTP
SMTP
agente de
usuário
agente de
usuário
agente de
usuário agente
de usuário
servidor de correio
servidor de correio
Correio Eletrônico – Visão 1
POP3/IMAP
28
1) Alice usa o UA para compor uma mensagem “para” [email protected]
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.
user agent
mail server
mail server user
agent
1
2 3 4 5 6
Correio Eletrônico – Visão 2
29
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
Correio Eletrônico – Visão 3
30
Um Exemplo de Sistema de
Controle de Tráfego Aéreo
M&C Console
G.A.M
Local/Group A.M.
ATC Console
A.S.O.U
O/S E. A. S.
Network Operating System
Processor I/O Devices
Attachments
Exceções
Exceções
Exceções
Exceções
Exceções
Fonte: Bass, Clements, and Kazman, Software Architecture in Practice, 2nd Edition, 2003.
Exceções
31
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)
32
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
33
Padrões e Estilos Arquiteturais
34
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
35
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”
36
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
37
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
38
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
39
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
40
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
41
Arquitetura de conjunto de ferramentas
CASE
42
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
43
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
44
Biblioteca de filmes e fotografias
45
Características do Estilo
Cliente-Servidor
Vantagens
• 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
46
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
47
Sistema de gerenciamento de
versões
48
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
49
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
50
Sistema de processamento de faturas
51
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
52
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
53
Sistema de processamento de
faturas
54
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
55
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
56
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
57
Chamada-Retorno
58
Gerenciador para um
Sistema Tempo Real
Comunicação entre o Controlador e os outros componentes pode ser
baseada em eventos, chamadas de procedimentos, etc.
59
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.
60
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
61
Publisher/Subscriber
62
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.
63
Controle dirigido a interrupções
64
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)
65
Modelo de referência OSI
66
Arquitetura de um Compilador
67
Estilos
67
68
Arquitetura de uma ferramenta CASE
Tradutor de
projeto
Editor de
projeto
Gerador de
código
Analisador
de projeto
Gerador de
relatório
Editor de
programa
Repositório
de projeto
68
69
Sistema de controle robotizado de embalagem
Sistema
de Visão
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
70
Cliente-servidor
Rede de banda larga
Cliente 2 Cliente 4
Servidor de
catálogo
catálogo
Servidor de
vídeo
Arquivos de clipes de filmes
Servidor de
fotografias
Fotografias digitalizadas
Servidor de
hipertexto
Web de hipertexto
Cliente 3 Cliente 2 Cliente 3 Cliente 4 Cliente 1
70
71
Arquitetura baseada em eventos
Subsistema
1
Subsistema
2
Subsistema
3
Subsistema
4
Manipulador de eventos e mensagens
71
72
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
73
Exemplos
74 74
75 75
76 76
77 77
78 78
79 79
80 80
81 81
82 82
83 83
84 84
85 85
86 86
87 87
88 88
89 89
90 90
91 91
92 92
93 93
94 94
95 95
96 96
97 97
98 98
99 99
100 100
101 101
102 102