Arquitetura de Software
Universidade Federal de Pernambuco
Centro de Informática
Recife - Brazil
Introdução

Raízes da disciplina
 Dijkstra,
1968

particionamento

estruturação

não só a programação
 Parnas,
1970 - 1972

estruturação

famílias de programas
–
economia no desenvolvimento e na manutenção
Introdução

Raízes da disciplina
 DeRemmer,
1975

programming-in-the-large : programação da estrutura

comum em sistemas distribuídos

programming-in-the-small: programação das “funções” do
sistema

uso comum (C, Pascal)
Introdução

Idéias fundamentais da Arquitetura de Software
 Estrutura
é o ponto chave
 Reusabilidade
 A orientação
de elementos de “grande escala”
a objetos reusa elementos de
“pequena escala”
Introdução

Motivação
 problemas


aumento do tamanho dos softwares
aumento na complexidade dos softwares
A importância da Arquitetura de Software
para os projetistas de software nos anos 90
é comparável a importância das estruturas
de dados para os programadores nos anos 60
Introdução

Vantagens
 sistemas
podem ser construídos rapidamente
reusando-se ou gerando-se grandes componentes
desenvolvidos independentemente
 predizer
qualidades (desempenho,
mantenabilidadde) do sistema a partir de sua
arquitetura, sem um projeto ou um código detalhado
Introdução

Vantagens

comunicação

decisões de projeto nas fases iniciais


restrições sobre a implementação

predizer atributos de qualidade

base para treinos de iniciantes

visão do sistema e das mudanças
transferência de conhecimento

linhas de produtos
Princípios

Termo
Disciplina
 área emergente da ES
 aborda as questões ligadas à
estrutura do software
Estrutura do software
 várias definições
 nenhuma aceita como padrão
 semelhanças no núcleo das
definições e diferenças nas
características adicionais
Princípios

Definição 1
“Uma arquitetura de software deve
conter: a definição dos elementos de
projeto que compõe o software; a
descrição das interações entre estes
elementos; os padrões de composição
dos elementos; e um conjunto de
restrições sobre estes padrões.”
Princípios

Definição 2
“A descrição da arquitetura de software
é um passo intermediário entre a análise
de requisitos e o projeto. Esta
descrição consiste de elementos
arquiteturais, as interações entre estes
elementos, e as restrições sobre estes
elementos e sobre
as suas interações.”
Princípios

Definição 3
“Uma arquitetura de software é um
conjunto de componentes genéricos
junto com uma descrição de
propriedades, regras de como estes
componentes podem interagir, e
estilo de interação destes
componentes.”
Princípios

Definição 4
“Arquitetura de software é a
estrutura de
um programa ou um sistema, seus
relacionamentos e os princípios que
guiam o seu projeto e a sua evolução
no tempo.”
Princípios

Modelos
 Perry

elementos
–

processamento, armazenamento, interação
formas
–

& Wolf, 1992
propriedades dos elementos
rationale
–
restrições de composição dos elementos
Princípios

Modelos
 Shaw
& Garlan, 1996

Componentes

Conectores

Configuração
Princípios

Componentes

modela a computação e o armazenamento de informações

desenvolvido independentemente

exemplos de componentes

cliente

servidor

aplicação inteira
Princípios

Conectores
 modela
as interações entre os componentes
 desenvolvido
 exemplos

independentemente
de conectores
protocolos de comunicação
Princípios

Configuração
 topologia
 composição
 conjunto
de componentes combinados usando-se
os conectores
 grafo
de componentes e conectores ligados,
descrevendo uma estrutura arquitetural
Princípios

Visão de uma Arquitetura de Software
Componente
Java
C++
Conector
C
Configuração
Princípios

Componentes e formas de interação
Componentes
Tipos de interação
 Módulos
 Objetos
 Filtros
 Processos
 Arquivo de dados
 Base de dados
Chamada de procedimento
Dados compartilhados
Invocação de método
Fluxo de dados ( pipe )
Passagem de mensagem, RPC
Leitura e escrita
Consulta
Princípios

Módulos
Chamada de Procedimento
Módulo
Módulo
Módulo
Princípios

Objetos
Objeto
Invocação de método
Objeto
Objeto
Princípios

Programas e funções
Programa
Principal
Chamada de função
funções
funções
funções
funções
Princípios

Software X Hardware
Arquitetura de Hardware
Arquitetura de Software
 número pequeno de
elementos de projeto
 mudança de escala
com a replicação dos
elementos de projeto
 ênfase na organização e
configuração
 grande número de
elementos de projeto
 mudança de escala com
a adição de novos
elementos de projeto
 ênfase na organização e
configuração
Princípios

Software X Redes de Computadores
Arquitetura de Rede
Arquitetura de Software
 nós
 conexões
 poucas topologias
 componentes
 conectores
 muitas topologias
Princípios

Software X Arquitetura de Construção
Arquitetura de Construção
Arquitetura de Software
 visões enfatizando diferentes
aspectos da construção
 restrição sobre os elementos de
projeto e a composição
 estreita relação entre o estilo
arquitetural e os princípios de engenharia
 a relação entre o estilo e o
material utilizado para a
construção é fundamental
 visões para diferentes e
usuários
 estilos arquiteturais
 princípios de engenharia
e estilo arquitetural
 implementação ( algoritmos
e estrutura de dados que
satisfazem a arquitetura )
Princípios

Sobre Arquitetura de Software
 descrição
mais abstrata no ciclo de vida do
software
 suprime
detalhes da implementação
Arquitetura de Software sempre existiu,
mas era implícita
Princípios

Sobre Arquitetura de Software

separação de interesses


funcionalidade
interação
Arquitetura de Software separa claramente
a funcionalidade (componentes) da interação
(conectores)
Princípios

Sobre Arquitetura de Software
Funcionalidade+interação
Funcionalidade
interação
Princípios

Sobre Arquitetura de Software
 define
aspectos estruturais importantes
 fornece
uma base para as outras fases de
desenvolvimento do software
a
arquitetura é normalmente descrita usando-se
linhas e caixas de diagramas acompanhados por
uma descrição textual
Princípios

Desenvolvimento de software
 Desenvolvimento tradicional
Análise de requisitos
 Desenvolvimento baseado em arquitetura
Análise de requisitos
Análise do domínio
Desenvolver / escolher a arquitetura
Arquitetura
Representação da arquitetura
Análise e avaliação da arquitetura
Projeto
Projeto
Implementação
Implementação
Princípios

Arquitetura X Projeto
Arquitetura
Projeto
 componentes e conectores
 procedimentos e interfaces
 restrições sobre componentes  algoritmos e estruturas de
e conectores
 composição de componentes
dados
 composição procedural
Princípios

Por que definir uma Arquitetura?
 reuso
de elementos de projeto permitindo maior
rapidez na construção do software
 definindo-se
uma arquitetura é possível predizer
algumas características do software
Princípios

Por que definir uma Arquitetura?
 facilita
a comunicação entre os desenvolvedores do
software
 permite
um entendimento maior da evolução do
software
Princípios

Por que definir uma Arquitetura?
 possibilidade
de análise da descrição da arquitetura
nas fases iniciais do desenvolvimento

consistência da configuração, componentes e conectores

propriedades não funcionais

conformidade com um determinado estilo
Estilos Arquiteturais

Termo
 padrão
organizacional
 padrão
arquitetural
 padrão
idiomático
 padrão
de organização estrutural
 idioma
arquitetural
Estilos Arquiteturais

Termo
“Um estilo arquitetural consiste de um
vocabulário de elementos de projeto, um
conjunto de regras de configuração, uma
interpretação semântica da composição dos
elementos, e um conjunto de análises que
podem ser executadas sobre um sistema
construído em um determinado estilo.”
Estilos Arquiteturais

Termo
 Vocabulário
 idioma
de projeto
 restringe
os elementos arquiteturais que podem ser
utilizados em uma descrição de arquitetura
 elementos

arquiteturais:
componentes , conectores
Estilos Arquiteturais

Regras de Configuração
 restrições
topólogicas
 restrigem
as composições dos elementos
arquiteturais

proibição de ciclos no estilo Fipe-filter

relacionamento n-para-1 no estilo Cliente-servidor
Estilos Arquiteturais

Análise
 verificação

de propriedades
ausência de impasses em um estilo Cliente-servidor
Estilos Arquiteturais

Sobre estilo arquitetural
 uso

ad hoc
“Camelot é baseado no modelo Cliente-servidor e usa
RPC para comunicação remota e local dos clientes e
servidores”
Estilos Arquiteturais

Sobre estilo arquitetural
 define
uma família e não apenas um sistema
 explora
os pontos comuns entre famílias de
sistemas e ignora detalhes específicos
a
construção de compiladores é o primeiro exemplo
do uso de estilos
Estilos Arquiteturais

Sobre estilo arquitetural

a descrição da arquitetura é uma instância de um
estilo
 exemplos

Cliente-servidor

Pipe-filter

Objetos

Invocação implícita

Camadas, repositórios
Estilos Arquiteturais
Arquitetura de software
Request-reply
Cliente
Servidor
Cliente
Cliente
Estilo Cliente-servidor
Estilos Arquiteturais
Arquitetura de software
Filtro
Pipe
Filtro
Filtro
Estilo Pipe-Filter
Estilos Arquiteturais
Arquitetura de software
Filtro
Pipe
Filtro
Filtro
Estilo Pipe-Filter
Estilos Arquiteturais

Por que definir estilos
 reuso
de projetos
 reuso
de código
o
uso de estruturas convencionais facilita o
entendimento da arquitetura

“cliente-servidor”
Estilos Arquiteturais

Por que definir estilos
a
restrição do espaço de projeto permite análises
mais especializadas para os estilos
 “menos
é mais”
Linguagem de Descrição de
Arquitetura

ADL - Architecture Description Language

O que podemos esperar de uma linguagem para
descrição de arquitetura de software?
 ênfase
em estruturas de alto nível em oposição a
detalhes de implementação
Linguagem de Descrição de
Arquitetura
 Composição

divisão hierárquica de um sistema complexo em partes
menores
 Abstração

explicitar a estrutura de mais alto nível
 Reusabilidade

componentes, conectores e padrões de arquitetura
Linguagem de Descrição de
Arquitetura

Configuração

separação da descrição de estruturas compostas da
descrição dos elementos dessas composições
 Análise

permite verificar propriedades dos sistemas,
especialmente referentes a Arquiteturas Dinâmicas
Linguagem de Descrição de
Arquitetura

Heterogeneidade

habilidade para combinar diferentes padrões arquiteturais
em um mesmo sistema

possibilidade de combinar componentes escritos em
linguagens diferentes
Linguagem de Descrição de
Arquitetura
 habilidade
para representar componentes
(primitivos ou compostos)
 habilidade
para representar conectores
 abstração
e encapsulamento
 tipos
e checagem de tipos
 permitir
a construção de ferramentas de análise
Linguagem de Descrição de
Arquitetura
 abstração
de componentes
 abstração
de comunicação
 integridade

de comunicação
a comunicação é limitada a componentes conectados
arquiteturalmente a outros
 habilidade
de modelar arquiteturas
Linguagem de Descrição de
Arquitetura

Modelagem de componentes
 conceitos

MetaH
–

um programa
C2
–

diferentes em cada ADL
uma aplicação inteira (componentes hierárquicos)
Wright
–
componente
Linguagem de Descrição de
Arquitetura

Modelagem de componentes
 interfaces
de componentes

pontos de interação com o ambiente externo

permitem a percepção da semântica dos componentes
–
serviços oferecidos
–
portas de comunicação
Linguagem de Descrição de
Arquitetura

Modelagem de componentes
 componentes
 uso

como tipos para serem reusados
explícito de parametrização
ACME, Darwin e Rapide
Linguagem de Descrição de
Arquitetura

Modelagem de componentes
 restrições
podem ser definidas por uma linguagem
específica
 componentes
podem evoluir

subtipagem de componentes

refinamento
Linguagem de Descrição de
Arquitetura

Modelagem de componentes
 especificação

de propriedades não-funcionais
permite simulação do comportamento em tempo de
execução

análise dos componentes

verificação de restrições

auxilia no gerenciamento do projeto
Linguagem de Descrição de
Arquitetura

Modelagem de conectores
 não
necessariamente corresponde a uma unidade
de compilação em uma implementação
 podem

ser modelados explicitamente
possuem interface própria
Linguagem de Descrição de
Arquitetura

Modelagem de conectores

podem ser modelados como entidades de primeira
classe

tipos ou instâncias

estabelecer restrições de uso via interface

suportar evolução
Linguagem de Descrição de
Arquitetura

Modelagem de configurações
a
estrutura de um sistema deve, idealmente,
permitir que a especificação da configuração seja
compreendida sem se conhecer detalhes internos
dos componentes e os conectores
Linguagem de Descrição de
Arquitetura

Modelagem de configurações
 descrição
de configurações permite estimar
aspectos concorrentes e distribuídos de uma
arquitetura
 ADLs
podem modelar evolução e dinamismo das
configurações
Linguagem de Descrição de
Arquitetura

Modelagem de configurações
 suporte
à composição hierárquica é fundamental
em uma ADL
 em
algumas ADLs uma configuração é modelada
simplesmente como um componente composto

Darwin, UniCon, CL
Linguagem de Descrição de
Arquitetura

Modelagem de configurações
 heterogeneidade

uma configuração deve idealmente lidar com componentes
e conectores programados em diversas linguagens
Linguagem de Descrição de
Arquitetura

Modelagem de configurações
a
especificação de restrições é fundamental para
descrever dependências entre componentes e
conectores
 Uma ADL
deve permitir refinamento da arquitetura
Linguagem de Descrição de
Arquitetura

Modelagem de configurações
 devem
suportar especificação e desenvolvimento
de sistemas que possam sofrer alterações durante
sua execução.

C2

Darwin

Rapide

ZCL

Wright
Linguagem de Descrição de
Arquitetura

Exemplo - Sistema de Monitoramento de Pacientes
O sistema de monitoramento de pacientes
consiste
de medições periódicas ou por solicitação de
pulso, temperatura e pressão através de
sensores colocados no paciente. Tais sensores
disparam um alarme sempre que qualquer das
medições atingirem valores não adequados.
Linguagem de Descrição de
Arquitetura

Exemplo
Hospital
alarme
Enfermeira
estado
alarme
Paciente
estado
Linguagem de Descrição de
Arquitetura

Exemplo - CL
system hospital
begin
use task enfermeira, paciente;
create cama from paciente;
create cuidado from enfermeira ;
link cama.alarme to cuidado.alarme;
link cuidado.estado to cama.estado;
activate cuidado, cama;
end.
Linguagem de Descrição de
Arquitetura

Wright
 Componentes

interface (portas)

computação (comportamento)
 Conectores

Role (comportamento de um único participante)

Glue (comportamento completo)
 Configuração

componentes + conectores
Linguagem de Descrição de
Arquitetura

Exemplo - pipe-filter
Este sistema lê um conjunto caracteres e
transforma-os em caracteres maiúsculos
Linguagem de Descrição de
Arquitetura

Exemplo - pipe-filter
input
UpperCase
output
right
left
right
Split
left
Merge
Linguagem de Descrição de
Arquitetura

Exemplo - pipe-filter
Component SplitFilter
port input [entrada de dados]
port left [porta de saída para o UpperCase]
port right [porta de saída para o Merge]
computation [lê dados e envia-os para as
portas de saída]
left
right
Split
Linguagem de Descrição de
Arquitetura

Exemplo - pipe-filter
Connector Pipe
role Source [envia dados repetidamente]
role Sink [recebe dados repetidamente]
glue right [Sink recebe dados na mesma ordem
que foram enviados por Source]
input
UpperCase
output
Linguagem de Descrição de
Arquitetura
Configuration Capitalise
Componentes Component UpperCase ...
Component MergeFilter ...
Component SplitFilter ...
Conector
Connector Pipe ...
Instanciação Instances
Split : SplitFilter
Upper: UpperCase
Marge: MergeFilter
P1, P2, P3 : Pipe
Attachments
Configuração
Split.left as P1.Source
Upper.input as P1.Sink
Split.right as P2.Source
Merge.right as P2.Sink
Upper.output as P3.Source
Merge.left as P3.Sink
End Capitalise.
Linguagem de Descrição de
Arquitetura

Exemplo - incluindo comportamento
out
A
{a}
in
C {a,c}
A||C||B
B
{b,c}
Linguagem de Descrição de
Arquitetura
Configuration ABC
Component A-Type
Port Out =a Out •
Computation = Out.a  Computation •
Component B-Type
Port In = c  In •
Computation = In.c  b  Computation •
Connector C-Type
Role Origin = a  Origin •
Role Target = c  Target •
Glue Origin = Origin.a  Target.c  Glue •
Instances
A : A-Type
B : B-Type
C : C-Type
Attachments
A.Out as C.Origin
B.In as C.Target
End ABC.