Arquitetura de Software
Rogério Dourado
[email protected]
Profa: Francilene Garcia
Disciplina: Projeto I
DSC – CCT – UFCG
Março - 2005
1
Roteiro
Introdução

Definições, Importância e Uso
Visões
Processo de Arquitetura
Na prática...
2
Introdução
3
Por que construímos sistemas?
Para atingir alguns objetivos de negócio
Exemplos:






Oferecer novos serviços
Satisfação dos clientes
Otimizar operações
Aumentar mercado
Obter diferencial
competitivo
Etc...
Requisitos
Funcionais
Não funcionais
4
Um Panorama
Requisitos
Arquitetura
Principalmente os requisitos não
funcionais é que determinam a
arquitetura
5
O que é Arquitetura de Software?
Não existe uma definição universal, mas...
“...são as estruturas que incluem
componentes, suas propriedades
externas e os relacionamentos entre
eles, constituindo uma abstração do
sistema. Esta abstração suprime
detalhes de componentes que não
afetam a forma como eles são usados ou
como eles usam outros componentes,
auxiliando o gerenciamento da
complexidade.”
“...é a interface entre duas partes distintas: o problema de
negócio e a solução técnica.”
6
Qual sua importância?
Sistemas estão cada vez mais complexos
Diversidade de atores envolvidos, cada um com suas
necessidades (visões)
Uma série de decisões (não somente técnicas)
precisam ser registradas, representadas e conciliadas
Antecipa decisões de projeto
Principal meio pelo qual os requisitos não-funcionais
(que são tão importantes quantos os funcionais)
devem ser validados




Performance
Segurança
Confiança
Etc...
7
Arquitetura X Design
Toda arquitetura é design, mas nem todo
design é arquitetura
A arquitetura restringe as decisões de design
de mais baixo nível

Essas decisões devem ser compatíveis com a
arquitetura
O design do que é interno aos componentes
evidenciados na arquitetura é livre para ser
definido
8
Documentação da Arquitetura
Todo sistema tem uma arquitetura
A documentação é uma tentativa de
representação desta arquitetura
Serve como



Veículo de comunicação entre atores
Base para análise dos atributos do sistema
Guia para o desenvolvimento
9
Visões
10
Visões
Uma arquitetura é algo difícil de ser
visualizado de uma única vez
Sistemas são compostos de várias estruturas




Módulos, mostrando a composição/decomposição
mapeadas ao código
Processos e como estes se sincronizam
Programas e como estes trocam dados
Como o software é distribuído no hardware
Visões é a forma de gerenciar esta
complexidade
11
Visões
Diferente visões expõem certos requisitos não
funcionais em diferentes níveis. Ex:


Visão de Deployment – Performance e confiança
Visão em Camada - Portabilidade
A relevância das visões varia de acordo com o
projeto


Quem são os atores?
Qual relação destes com a arquitetura?
Nenhum visão específica pode representar
toda a arquitetura
12
Esquemas de Visões
São conjuntos de visões propostos por vários
autores



Kruchten, Rational 4+1
OMT
Booch
Apesar de diferirem, todas as visões “caem”
em alguma destas categorias:



Estruturação em termos de unidades de
implementação, denominados módulos
Estruturação em termos de componentes que
possuem comportamento em tempo de execução
Relacão ou alocação do software com o ambiente
13
Estilos
Formas recorrentes/comuns de modelos
Definem uma família de arquiteturas. Ex:

Tipo de Visão de Módulo
 Decomposição, Uso, Generalização, Camada

Tipo de Visão de Componente
 Cliente-servidor, Peer-to-Peer, Pipe-and-Filter,
Camada

Tipo de Visão de Alocação
 Deployment, Alocação de Tarefa
14
Estilo Pipe-and-Filter - Exemplo
Divide a tarefa de um sistema em vários
passos de processamento sequencial
Componentes



São chamados filtros
Tem um conjunto de entradas e saídas
Processa um stream de dados
Conectores

Pipes: servem como condutores dos dados
Ex: Compiladores,
Shell Unix
15
Estilo Pipe-and-Filter - Exemplo
Especializações do estilo

Pipelines, Typed Pipes...
Implementação

Divida as tarefas do sistema em uma sequência de
estágios de processamento
 Cada estágio deve depender somente da saída do seu
predecessor
 Todos os estágios são conectados por um fluxo de dados


Defina o formato de dados a ser passado ao longo
de cada pipe
Decida como implementar cada conexão com pipe
 Se estes serão ativos ou passivos
16
Exemplo do Uso de Estilos
“O sistema X tem como entrada um conjunto de
linhas. As linhas são formadas por palavras que por
sua vez são formadas por caracteres. As linhas
podem sofrer um shift circular quando a primeira
palavra é retirada do início e colocada no final. O
sistema gera a lista de todas os possíveis shifts de
todas as linhas em ordem alfabética.”
Cada estilo possuis suas vantagens e desvantagens:



Subrotina com dados compartilhados
Pipe-and-Filter
Etc...
17
Subrotina com dados
compartilhados
Não permite reuso, mudanças não são
bem toleradas, eficiente no uso do
espaço
18
Pipe-and-Filter
Unidades de processamento isolados (assimila
melhor as mudanças)
Facilidade de acréscimos de novos filtros
Porém ineficiente em termos de uso de espaço
19
Processo de Arquitetura
20
Processo de Arquitetura
Fases em um nível macro:






Elaboração do modelo de negócio
Entendimento dos requisitos
Criação ou seleção de uma arquitetura
Representação e divulgação
Implementação baseada na arquitetura
Avaliação da arquitetura
Modelos Arquiteturais

Negócio, domínio da aplicação, componentes,
infra-estrutura tecnológica, distribuição do
software
21
Papéis
Analista de requisitos

Identifica requisitos funcionais e não-funcionais
Arquiteto


Cria a arquitetura e identifica outros requisitos
não-funcionais que a arquitetura deve atender
Acompanha o processo de desenvolvimento da
arquitetura proposta
Projetista ou Implementador

Implementador dos componentes propostos
22
Relação com outras fases do
processo
A arquitetura deve objetivar todo o
sistema
Pode haver ênfase para a 1ª versão
23
Relação com outras fases do
processo
Arquitetura guia as fases subsequentes
24
Na prática...
25
Mas e aí, como se faz?
O conjunto de visões arquiteturais é o meio pelo qual
tentamos gerenciar a complexidade do software
Etapa intermediária necessária da transformação dos
requisitos em código
Na prática, podemos adotar uma abordagem
crescente de detalhamento




Visão de Negócio
Visão Conceitual
Visão de Desenvolvimento
Visão de Deployment
26
Fazendo um “Zoom”
Visão de Negócio

Como o negócio funciona?
Visão Conceitual

Quais os principais conceitos envolvidos e como
estes se relacionam?
Visão de Desenvolvimento

Qual a melhor maneira de implementar estes
conceitos tendo em vista a solução?
Visão de Deployment

Depois de pronto como o software sera instalado e
distribuído ao longo da infra-estrutura?
27
Visão de Negócio
Atores,
processos e suas
interações
Como o negócio
resolve o
problema
28
Visão de Negócio
Como as entidades de negócio
colaboram
29
Visão Conceitual
Mais próxima ao
domínio da
solução
Ainda não tem
os detalhes
necessários a
implementação
Conceitos e suas
relações
30
Visão de Desenvolvimento
Qual a melhor maneira de implementar a solução
tendo em vista os requisitos?
Modularização, comunicação entre subsistemas,
reusabilidade
Emprego de padrões arquiteturais como MVC
31
Visão de Deployment
Modela



Infra-estrutura
Como o Software
está instalado na
infra-estrutura
Mecanismos de
comunicação
(middleware)
32
Perguntas?
33