arquitetura de software - facombacala/as2/02-arquitetura_de_sw.pdfprogramação modular [parnas,...

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” 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.

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