1 Arquitetura de Software Prof a : Francilene Garcia Disciplina: Projeto I DSC – CCT – UFCG...
-
Upload
livia-philippi-mendonca -
Category
Documents
-
view
220 -
download
2
Transcript of 1 Arquitetura de Software Prof a : Francilene Garcia Disciplina: Projeto I DSC – CCT – UFCG...
1
Arquitetura de Software
Profa: Francilene GarciaDisciplina: Projeto IDSC – CCT – UFCG
Março - 2005
Rogério [email protected]
2
Roteiro Introdução Definições, Importância e Uso Visões Processo de Arquitetura Na prática...
3
Introdução
4
Por que construímos sistemas?
Para atingir alguns objetivos de negócioExemplos: Oferecer novos
serviços Satisfação dos
clientes Otimizar operações Aumentar mercado Obter diferencial
competitivo Etc...
Requisitos
FuncionaisNão funcionais
5
Um Panorama
Requisitos
Arquitetura
Principalmente os requisitos não funcionais é que determinam a arquitetura
6
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.”
7
Qual sua importância?Sistemas estão cada vez mais complexosDiversidade 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 conciliadasAntecipa decisões de projetoPrincipal 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...
8
Arquitetura X DesignToda arquitetura é design, mas nem todo design é arquiteturaA arquitetura restringe as decisões de design de mais baixo nível Essas decisões devem ser compatíveis com
a arquiteturaO design do que é interno aos componentes evidenciados na arquitetura é livre para ser definido
9
Documentação da Arquitetura
Todo sistema tem uma arquiteturaA documentação é uma tentativa de representação desta arquiteturaServe como Veículo de comunicação entre atores Base para análise dos atributos do
sistema Guia para o desenvolvimento
10
Visões
11
VisõesUma arquitetura é algo difícil de ser visualizado de uma única vezSistemas 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
12
VisõesDiferente 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
13
Esquemas de VisõesSã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
14
EstilosFormas recorrentes/comuns de modelosDefinem 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çãoDeployment, Alocação de Tarefa
15
Estilo Pipe-and-Filter - Exemplo
Divide a tarefa de um sistema em vários passos de processamento sequencialComponentes 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
16
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
17
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...
18
Subrotina com dados compartilhados
Não permite reuso, mudanças não são bem toleradas, eficiente no uso do espaço
19
Pipe-and-FilterUnidades de processamento isolados (assimila melhor as mudanças)Facilidade de acréscimos de novos filtrosPorém ineficiente em termos de uso de espaço
20
Processo de Arquitetura
21
Processo de ArquiteturaFases 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
22
PapéisAnalista de requisitos Identifica requisitos funcionais e não-
funcionaisArquiteto Cria a arquitetura e identifica outros requisitos
não-funcionais que a arquitetura deve atender Acompanha o processo de desenvolvimento
da arquitetura propostaProjetista ou Implementador Implementador dos componentes propostos
23
Relação com outras fases do processo
A arquitetura deve objetivar todo o sistemaPode haver ênfase para a 1ª versão
24
Relação com outras fases do processo
Arquitetura guia as fases subsequentes
25
Na prática...
26
Mas e aí, como se faz?O conjunto de visões arquiteturais é o meio pelo qual tentamos gerenciar a complexidade do softwareEtapa intermediária necessária da transformação dos requisitos em códigoNa 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
27
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?
28
Visão de NegócioAtores, processos e suas interações
Como o negócio resolve o problema
29
Visão de NegócioComo as entidades de negócio colaboram
30
Visão Conceitual
Mais próxima ao domínio da soluçãoAinda não tem os detalhes necessários a implementaçãoConceitos e suas relações
31
Visão de DesenvolvimentoQual a melhor maneira de implementar a solução tendo em vista os requisitos?Modularização, comunicação entre subsistemas, reusabilidadeEmprego de padrões arquiteturais como MVC
32
Visão de DeploymentModela
Infra-estrutura Como o
Software está instalado na infra-estrutura
Mecanismos de comunicação (middleware)
33
Perguntas?