Reuso de Software 14/03/2012

   # # # # # # # # # # # # #
  # Reuso de Software       #
  # Prof Eduardo Figueiredo #
  # notasdogarcia.blog.com  #
   # # # # # # # # # # # # #

  Arquitetura de Software e Padrões Arquiteturais.

  Padrões Arquiteturais:
    - Arquitetura em Camadas (Layered Architecture) - Nessa aula
    - Dutos e Filtros (Pipes & Filters)             - Nessa aula
    - Repositório Compartilhado (Black Board)       - Nessa aula
    - Cliente-Servidor
    - Modelo-Visão-Controle
    - Microkernel

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Revendo padrões de projeto:
    Padrões são descrições de problemas comuns juntamente com descrições de boas e bem planejadas soluções e seus prós e contras.

CONCEITO:
  Padrões de Arquitetura são um nível de abstração a mais, são padrões de organização de subsistemas de um programa.

  Pode ser dividido em duas partes:
    1 Projeto de arquitetura:
      - Define a estrutura modular do software, é feito usando um diagrama de caixas pretas.
        // Os diagramas são bem flexíveis, e podem ser desenhados da forma que parecer mais natural ao projetista.

    2 Projeto detalhado:
      - Inclui planejar a comunicação e os processamentos de cada caixa preta do diagrama.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  O projeto é uma atividade criativa e portanto não tem uma solução única.

  Um projeto arquitetural pode ser pensado também como uma ponte de ligação entre as funções finais do programa e as partes internas dele.
  Afinal com o projeto voce consegue aos poucos enchergar onde cada função se integra com o todo, e depois fica fácil programar o código interno de cada uma.

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Primeiros Passos da criação de um Projeto de Arquitetura é a criação do Diagrama de Componentes:

    1° - Pensar "o que é a solução?", intuitivamente nós já sabemos o que é, e devemos partir disso.
    2° - Sair pensando quais peças comporão sua solução, dessa forma voce descobre os modulos (ou Componentes) que formarão seu Diagrama de Componentes.
    3° - Uma vez em mente os quais os modulos deve-se esclarecer quem se comunica com quem e já ir pensando em como.

  Então já se pode desenhar o diagrama, que representará em mais alto nível seu primeiro esboço do Projeto de Arquitetura.

  Por fim, voce deve detalhar cada modulo mais e mais até ter uma idéia firme e bem estruturada do que é o seu sistema.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Vantagens do Projeto já em forma de Diagrama:

    - O diagrama pode ser usado como foco de discussão do problema com os clientes e associados.
    - Análise do sistema pode ser feita sobre o modelo arquitetural, ou seja é mais fácil criar novas funcionalidades nesse ponto do que mais tarde.
    - Reuso em larga escala, um componente bem bolado e modularizado pode ser re-usado inteiramente em outros programas, então é um ponto que deve receber atenção.
    - Facilita o desenvolvimento em paralelo (facilita a decisão de dividir a equipe para programar várias partes ao mesmo tempo).

  Desvantagens:
    - Não mostra em detalhe os relacionamentos (a natureza das comunicações dos sub-sistemas).
    - Não indica as propriedades internas do sistema.

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Uma arquitetura pode afetar:

    - O desempenho do sistema.
    - A facilidade de distribuição (tornar o programa multi-plataforma).
    - A facilidade de manutenção (crie componentes bem modularizados).

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  A arquitetura deve considerar elementos não funcionais (que seria aquilo de já ir pensando outras partes do sistema):

    - Desempenho, ou seja evitar gargalos.
    - Segurança, já bloqueando pontos de risco.
    - Mecanismos anti-falha, como sistemas redundantes.

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Questões a serem respondidas:

    - Como a execução do sistema funcionará se for distribuida em diferentes máquinas?
    - Como serão decompostas em componentes?
    - Como avaliar se a arquitetura atende aos requesitos não funcionais?, ou seja coisas que não tenham a ver diretamente com a solução do problema.
    - Existe uma arquitetura genérica que possa ser usada? // Um dos padrões de arquiteturas que estudaremos?

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Padrões Arquiteturais (ou Estilos Arquiteturais, ou Arquitetura de Referência)
  // Falaremos agora de Padrões Arquiteturais, ou seja arquiteturas úteis e comumente utilizadas.

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Razões para estudarmos os Padrões de Arquitetura:

    Cada arquitetura é ligeiramente diferente, mas em campos próximos elas costumam ser parecidas.
    Isso permite que vários projetos sejam reutilizados ao menos parcialmente em outros projetos.
    É útil que uma arquitetura possa partir já de um ponto mais avançado, assim utilizar um padrão de projeto já poupa tempo.

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Padrões arquiteturais podem ser modelados para aderir a algumas propriedades de um sistema.

    - Redundancia.
    - Velocidade.
    - Segurança.
    - Etc..

  O conhecimento de vários destes padrões pode facilitar o projeto da arquitetura de um sistema.
  // Note que voce pode utilizar mais de um padrão em um mesmo sistema.

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Um padrão deve conter:

    - Um conjunto de sub-sistemas.
    - Responsabilidades de cada um.
    - Relacionamento entre os componentes.

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Padrões arquiteturais definem também os padrões a serem seguidos pelos programadores.
  ou seja, quais padrões padrões de projetos, e quais "idiomas" de programação utilizar.

  // Idiomas de programação diz respeito a detalhes como: Como será o formato do comentários?, Que padrões os nomes de variáveis seguirão? etc.

  Como estes padrões definem uma estrutura fundamental, eles devem prever que as proximas versões devem seguir os mesmos padrões.

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Padrões Arquiteturais, obviamente não te dão a solução de bandeja, eles precisam ser trabalhados para chegar no sistema especifico.

  Um padrão deve ser refinado com o tempo, assim a cada revisão do sistema deve-se quebrar componentes maiores em componentes mais detalhados,
  Deve assim com o passar do tempo detalhar melhor as comunicações, os idiomas e os padrões de projeto escolhidos.

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  A escolha de um padrão deve prever o tipo de sistema e seus requesitos não-funcionais.

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Algumas perguntas que devem ser feitas:
    - O sistema é interativo?
    - Possui muitas variações?
    - Quais os requesitos não-funcionais importantes?
    - Confiabilidade é importante?
    - Adaptabilidade é importante?

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Cada padrão leva a consequencias um pouco diferentes, mesmo quando os problemas são semelhantes.
  Pode ser necessário em um mesmo sistema se utilizar dois Padrões Arquiteturais para atender a todo o sistema.

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Vantagens de Padrões de Arquitetura:

    - Favore o modelo de desenvolvimento incremental (voce não tem que pensar em tudo ao mesmo tempo)
    - As camadas tornam-se modulares, pode-se substituir se necessário sem muito esforço (requer interfaces estáveis e bem construidas).
    - Mudanças em uma camada teoricamente só impactam a camada superior.
    - Camadas superiores podem ser indepentes de plataforma/hardware.

  Desvantagens:

    - Identificar o que fica em cada camada pode não ser fácil, principalmente os das camadas mais baixas.
    - Camadas em excesso podem comprometer o desempenho por excesso de comunicação entre as menssagens.

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Agora vamos começar a falar em detalhes de cada Padrão de Arquitetura:

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Padrões de Projeto:

  Da Desordem à Estrutura:
    - Layered Architecture (Arquitetura em Camadas)
    - Pipes and Filters (Dutos e Filtros)
    - Black board (Repositorio Compartilhados)

  Sistemas Distribuidos:
    - Client-Server (Cliente-Servidor)
    - Broker

  Sistemas Interativos:
    - Model View Controller
    - Presentation Abstratcion Control

  Sistemas Adaptaveis:
    - Microkernel
    - Reflection

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Arquitetura em Camadas:

    Cada camada solicita serviços da camada inferior e fornece a camada superior.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Dica: Evite criar muitas camadas, isso complica as coisas (entre 3 e 4 camadas é ok).

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Camadas comuns são:

    - Camada de Apresentação -> Dados apresentados aos usuários
    - Camada de Negócios     -> Programa em sí.
    - Camada de Dados        -> Banco de Dados, Comunicação etc.

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Dutos e Filtros:

  Padrão de organização da dinâmica de um sistema.

  É dividido em dois componentes:
    - Dutos: Componentes que conduzem os dados
    - Filtros: São os componentes que tratam os dados.

  Permitem que voce pense no programa como uma linha de produção onde os dados seguem um caminho pelo sistema
  e a cada passagem por um filtro são incrementados.

  Usado em aplicações de processamento de dados.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Vantagens:

    - Os filtros são bem modulares. (é fácil acrescentar um novo filtro entre dois antigos)
    - O fluxo de execução parece com o fluxo de trabalho da empresa então é fácil para um cliente compreender.
    - Fácilmente extensível com adição de novos filtros.
    - Se aplica tanto a sistemas paralelos quanto a sistemas concorrentes.

  Desvantagens:
    - Deve haver um padrão para o formato dos dados trafegados.
    - Pode haver um overhead pela padronização dos dados.
    - Incompatibilidade na padronização pode prejudicar o re-uso.

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  Repositório Compartilhado (Black Board)

    Todos os dados ficam contidos no mesmo local então é facil planejar a comunicação e a estruturação das tarefas já que é tudo centralizado.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Vantagens:
    - Formas de proteção dos dados podem ser melhor implementadas.
    - Os sub-sistemas que gravam dados não precisam saber quem os usa e vice-versa (permitindo modularidade, e evitando mta comunicação)
    - Fácil integrar novos sub-sistemas.

  Desvantagens:
    - É preciso também padronizar os dados.
    - A manutenção desse grande volume de dados pode ser problemática.
    - É preciso evitar redundancias e inconsistencias nos dados devido aos acessos de multiplos locais.
    - Sub-sistemas diferentes podem ter dados com diferentes requesitos de tratamento (Ex: segurança, disponibilidade, acesso rápido etc)
      // Ou seja pode ter um dado que é uma senha, ele deve ficar bem protegido, outro é frequentemente acessado então deve tomar pouco tempo,
      // Tudo deve ser programado as vezes tratando um dado ou outro de forma especial,
      // o que pode fazer o Modulo de dados virar uma macarronada de fluxo de execução.
      // (Esse comentário acima foi interpretação minha: Vinicius Garcia)

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

  // Fim da aula.
  próxima aula linha de produtos.
  Faltou falar de mais um Padrão que ele pretende falar ainda.