A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

1 Arquitetura de Software Prof a : Francilene Garcia Disciplina: Projeto I DSC – CCT – UFCG Março - 2005 Rogério Dourado

Apresentações semelhantes


Apresentação em tema: "1 Arquitetura de Software Prof a : Francilene Garcia Disciplina: Projeto I DSC – CCT – UFCG Março - 2005 Rogério Dourado"— Transcrição da apresentação:

1 1 Arquitetura de Software Prof a : Francilene Garcia Disciplina: Projeto I DSC – CCT – UFCG Março - 2005 Rogério Dourado rogerio@dsc.ufcg.edu.br

2 2 Roteiro Introdução Definições, Importância e Uso Visões Processo de Arquitetura Na prática...

3 3 Introdução

4 4 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

5 5 Um Panorama Requisitos Arquitetura Principalmente os requisitos não funcionais é que determinam a arquitetura

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

8 8 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

9 9 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

10 10 Visões

11 11 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

12 12 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

13 13 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

14 14 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

15 15 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

16 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 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 18 Subrotina com dados compartilhados Não permite reuso, mudanças não são bem toleradas, eficiente no uso do espaço

19 19 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

20 20 Processo de Arquitetura

21 21 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

22 22 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

23 23 Relação com outras fases do processo A arquitetura deve objetivar todo o sistema Pode haver ênfase para a 1ª versão

24 24 Relação com outras fases do processo Arquitetura guia as fases subsequentes

25 25 Na prática...

26 26 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

27 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 28 Visão de Negócio Atores, processos e suas interações Como o negócio resolve o problema

29 29 Visão de Negócio Como as entidades de negócio colaboram

30 30 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

31 31 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

32 32 Visão de Deployment Modela Infra-estrutura Como o Software está instalado na infra-estrutura Mecanismos de comunicação (middleware)

33 33 Perguntas?


Carregar ppt "1 Arquitetura de Software Prof a : Francilene Garcia Disciplina: Projeto I DSC – CCT – UFCG Março - 2005 Rogério Dourado"

Apresentações semelhantes


Anúncios Google