Tese de Doutorado Middleware para Integração de Dados Heterogêneos Baseado em Composição de Frameworks Aluno: Alvaro Cesar P Barbosa Orientador: Prof.

Apresentação em tema: "Tese de Doutorado Middleware para Integração de Dados Heterogêneos Baseado em Composição de Frameworks Aluno: Alvaro Cesar P Barbosa Orientador: Prof."— Transcrição da apresentação:

1 Tese de Doutorado Middleware para Integração de Dados Heterogêneos Baseado em Composição de Frameworks Aluno: Alvaro Cesar P Barbosa Orientador: Prof. Rubens Nascimento Melo Co-Orientador: Prof. Carlos José Pereira de Lucena

2 Sumário Introdução Objetivo O Ambiente CoDIMS Estudo de Caso
Considerações Finais Nos começamos apresentando uma Introdução e a motivação, deste trabalho, e então seu Objetivo, Segue uma descrição do ambiente CoDIMs: que é a contribuição maior deste trabalho, através da proposta de uma nova abordagem para se gerar sistemas configurados para a integração de dados, Como instrumento de validação, apresentaremos um estudo de caso e sua implementação, e finalmente as Considerações Finais, incluindo as Conclusoes, Contribuições e Trabalhos Futuros.

3 Introdução Integração de dados heterogêneos é um tema de pesquisa atual e com muitos problemas em aberto. Aplicações necessitam acessar dados de diferentes fontes de dados distribuídas, através de sistemas integradores. Aplicações necessitam acessar dados armazenados em diferentes fontes de dados distribuídas, requerendo o uso de sistemas integradores, por exemplo em aplicações B2B

4 Introdução Desenvolver sistemas de integração de dados não é uma tarefa simples devido a complexidade de: Acesso a diferentes modelos de dados; Integração semântica de dados; Estratégias para processamento de consultas; Técnicas de gerência de transação. Desenvolver sistemas de integração de dados é uma tarefa complexa, devido a necessidade de Acessar diferentes tipos e modelos de dados: por exemplo, integrar dados de um banco de dados relacional e de um arquivo XML; Ao problema da Integração semântica de dados: por ex, em duas fontes diferentes o mesmo dado pode ter definições diferentes;; Diferentes Estratégias para processamento de consultas, como ex a tese Fábio Porto sobre otimização de consultas para aplicações científicas; Técnicas de gerência de transação, para alterações de dados em aplicações B2B.

5 Introdução O crescimento da Internet tem aumentado estes problemas, devido a: Usuários com diferentes perfis e interesses; Dados de diferentes tipos e modelos; Aplicações com diferentes funcionalidades. A Internet, se por um lado facilitou o acesso aos dados, por outro lado permitiu disponibilizar mais e mais dados, aumentando o problema da integração, devido a Existência de muitos usuários, com diferentes perfis e interesses; de leigos a profissionais do ramo; que necessitam acessar diferentes tipos e modelos de dados; requerendo, para isso, aplicações com diferentes funcionalidades, como: - aplicações somente leitura dos dados; - aplicações que podem requerer alterações nos dados. - aplicações para processar tipos de dados específicos.

6 Introdução - Sistemas Existentes
Abordagem Modelo de Dados Integrador Linguagem de Consulta Processamento Strudel (AT & T Labs) Mediador Grafo de páginas HTML STRUQL Baseado em sistemas de recuperação de informação Araneus (Universidade de Roma Tre) Relacional Interface HTML * Não está claro nas referências Le Select (INRIA) SQL Tradicional DISCO Orientado a Objeto OQL TSIMMIS de Stanford) Object Exchange Model (OEM) OEM-QL Conjunto padrão de sub-consultas MIRO-Web (GMD) Relacional- Garlic (IBM) SGBDH MOCHA de Maryland) Middleware HEROS (PUC-Rio) Na literatura são encontrados diversos sistemas de integração, sendo estes os mais citados. Mas são voltados para aplicações específicas ou genéricos (heavy weigh), tornando-se pesados e complexos. Historicamente foram 2 as abordagens para o desenvolvimento de sistemas de integração de dados: SGBDHs ou mediadores. Os SGBDHs, voltados para a integração de sistemas de bancos de dados; Os mediadores para a integração de outros tipos de dados. Devido à extensão destas 2 abordagens, atualmente estão sendo genericamente denominados de middleware de integração de dados. Possuem uma arquitetura fixa e disponiblizam funcionalidades bem definidas, como o modelo da dados integrador linguagem de consulta, que podem levar a problemas: Ex. integrar XML e BDR usando MDC OO Obs.: SGBDH: utilizando as funcionalidades dos serviços de gerência de dados dos SGBDs, e integrando os esquemas em um esquema global. Mediador fornece informação integrada sem a necessidade de se integrar as fontes de dados.

7 Introdução Trabalhos anteriores do nosso grupo de pesquisa:
Desenvolvimento do Sistema HEROS; Desenvolvimento do projeto ECOHOOD; Atual participação no projeto ECOBASE (CNPq/INRIA). Sistema Heros, sendo um dos trabalhos anteriores do grupo de pesquisa em integração de dados heterogêneos. O HEROS é um SGBDH federado com modelo de dados integrador orientado a objeto. Na utilização do HEROS, percebemos que nem todas as suas funcionalidades eram necessárias em algumas aplicações, o que dificultava o processo de adaptação, além de tornar um sistema pesado para tais aplicações. Assim, passamos a pesquisar sobre sistemas configuráveis, através do Projeto ECOHOOD: um ambiente para se construir SGBDs flexíveis e configuráveis. Atualmente, participamos do Projeto ECOBASE: Tecnologias de banco de dados e Web para sistemas de informações ambientais. Um projeto de cooperação entre o C`NPq e o INRIA, envolvendo a comunidade de banco de dados do Rio de Janeiro e pesquisadores do INRIA.

8 Motivação As soluções devem ser moldadas a fim de conciliar os diferentes aspectos entre usuários, dados e aplicações. Necessidade de desenvolver sistemas de integração que sejam flexíveis e configuráveis. A experiência adquirida com os projetos desenvolvidos pelo nosso grupo de pesquisa, nos permitiu conhecer os problemas envolvidos no desenvolvimento de sistemas de integração de dados e que motivou o presente trabalho Percebemos que as soluções ... ... O que nos leva a necessidade de ....

9 Objetivo  Desenvolver um ambiente flexível, denominado CoDIMS, que permita gerar sistemas middleware configurados para a integração de dados heterogêneos e distribuídos. CoDIMS: Configurable Data Integration Middleware System

10 Objetivo Middleware Fontes de Dados Aplicações c/ visão integrada
Os sistemas integradores, por serem uma camada intermediária entre os dados e a de apresentação receberam o nome de middleware. Outros BDs Legados Internet … Fontes de Dados

11 O Ambiente CoDIMS Fontes de Dados Aplicações c/ visão integrada
No nosso caso, o CoDIMS gera sistemas middleware configurados, a partir da combinação de serviços típicos de gerência de dados. Outros BDs Legados Internet … Fontes de Dados

12 O Ambiente CoDIMS O CoDIMs permite a seleção e integração de um conjunto adequado de componentes DIMS: Data Integration Middleware Services. Ou seja, um sistema configurado é obtido pela seleção e integração de um conjunto adequado de DIMS, onde DIMS implementam serviços típicos de gerência de dados, tal como os existentes nos SGBDs. Estes componentes são: Controle: responsável pela configuração, execução e comunicação. Interface: Possibilitar a comunicação da aplicação com o middleware. Gerência de Metadados: Armazenar, gerenciar e viabilizar o acesso aos metadados do sistema, incluindo os das fontes de dados. Processamento de Consulta: Responsável pela interpretação, otimização e execução de consulta. Acesso aos Dados: Possibilitar a comunicação do middleware com as fontes de dados. Gerência de Transação: Garantir as propriedades ACID no caso de alteração dos dados. Cont. de Concorrência: Gerenciar e controlar a existência de transações conocrrentes; Gerência de Regras: Prover o sistema com um comportamento ativo, tal como nos SGBDs ativos.

13 O Ambiente CoDIMS “What you need is only what you get”. (wynwyg)
Gerar sistemas de integração configurados apenas com os componentes necessários e adequados a uma aplicação específica. “What you need is only what you get”. (wynwyg) O objetivo maior do CoDIMs é gerar... Assim, a abordagem do CoDIMS é ...

14 Exemplo de Configuração 1
Controle No caso de leitura dos dados, apenas o uso dos componentes... Somente Leitura dos Dados Integrados

15 Exemplo de Configuração 2
Controle No caso de aplicação alterar os dados das fontes de dados, torna-se necessário incluir o componente gerência de transação para garantia da atomicidade da operação. No caso da existência de transações concorrentes seria necessário incluir o componente Controle de Concorrência. Alteração nas Fontes de Dados

16 Exemplo de Configuração 3
Controle Caso se queira disponibilizar um comportamento ativo ao sistema, tal como nos sistemas de bancos de dados ativos, deve-se incorporar o componente gerência de regras. Podem ser incorporados outros componentes, para aplicações específicas. Como por exemplo, um serviço para sincronizar audio e vídeo em aplicações multimídia.

17 Arquitetura do CoDIMS Controle FD1 FD2 Gerência de Processamento
Acesso aos Dados Wrapper Gerência de Metadados Processamento de Consulta Gerência de Regras Controle de Concorrência Transação Interface Aqui temos um “overview” da arquitetura do CoDIMS. Podemos observar que o componente Controle é um broker, responsável pela integração dos componentes e pela comunicação entre eles. O componente Acesso aos dados acessa os dados través de wrappers.

18 A Abordagem CoDIMS Flexibilidade: Configuração e Frameworks
Configuração Física: Componentes e Serviços A ênfase da abordagem do CoDIMS é em configuração e flexibilidade; A configuração permite oferecer diferentes serviços através da integração de diferentes componentes. No CoDIMS, cada componente é um framework; Já a flexibilidade, oferecida através da configuração e de frameworks, proporciona diferentes características ao sistema, de acordo com a necessidade da aplicação. A essência da abordagem do CoDIMS está nos mecanismos de configuração física e lógica. Configuração Lógica: Escalonamento dos Serviços

19 Configuração Program P; Type R = Record C1 : T1; C2 : T2; ….. Cn : Tn
end; Proc Serviço 1; Proc Serviço 2; … Proc Serviço n; Begin Serviço i1; Serviço in End. Para exemplificar o processo de configuração, vamos supor que um sistema de integração seja análogo a um programa Pascal-like, como este. Vimos que, os sistemas de integração existentes são específicos ou genéricos.

20 Configuração Serviços Funcionalidade Program P; Type R = Record
C1 : T1; C2 : T2; ….. Cn : Tn end; Proc Serviço 1; Proc Serviço 2; … Proc Serviço n; Begin Serviço i1; Serviço in End. Serviços Isto significa que, no caso dos específicos, são formados por serviços pré-definidos voltados para uma determinada aplicação. Para uma nova aplicação, pode ser necessário o desenvolvimento de um outro programa, ou seja, de um novo programa. Já os genéricos apresentam diversos serviços, mesmo que não sejam utilizados pela maioria das aplicações. Nestes dois casos, a funcionalidade do sistema está definida dentro do seu código. Funcionalidade

21 Configuração Metadados Serviços Funcionalidade Program P;
Type R = Record C1 : T1; C2 : T2; ….. Cn : Tn end; Proc Serviço 1; Proc Serviço 2; … Proc Serviço n; Begin Serviço i1; Serviço in End. Catálogo Metadados Serviços Os sistemas de bancos de dados tradicionais, incluindo os SGBDHS, extrairam a definição dos dados do sistema (metadados), armazenando-os em um catálogo, o que proporciona uma maior flexibilidade na definição e utilização dos dados. Funcionalidade

22 Configuração Metadados Configuração Física (Serviços) Configuração
Program P; Type R = Record C1 : T1; C2 : T2; ….. Cn : Tn end; Proc Serviço 1; Proc Serviço 2; … Proc Serviço n; Begin Serviço i1; Serviço in End. Catálogo Metadados Configuração Física (Serviços) De modo análogo, no CoDIMS, além da extração da definição dos dados (metadados) do sistema, propomos a extração da definição dos serviços e da funcionalidade do sistema, através dos mecanismos de configuração física e lógica. Isso permite uma maior flexibilidade na definição e utilização dos serviços e das funcionalidades do sistema, permitindo, assim, gerar sistemas configurados moldados para uma aplicação específica. Configuração Lógica (Funcionalidade) ? S N

23 Configuração Física Seleção dos componentes DIMS adequados;
Customização dos componentes; Integração destes componentes; Registro dos componentes no sistema: (nome, serviços oferecidos e requisitados). No processo de configuração física é realizada a seleção...

24 Configuração Lógica Registra o mapeamento entre as funcionalidades oferecidas pelo sistema e as operações dos componentes DIMS; Faz o escalonamento das operações dos componentes DIMS durante a execução do sistema configurado; Baseada no conceito de workflow. No processo de configuração lógica é registrado o mapeamento... Em tempo de execução, o sistema faz o escalonamento das operações dos componentes DIMS de acordo com a requisição global. O mecanismo de configuração lógica é baseado no conceito de workflow.

25 Especificação do CoDIMS
Bem, agora vamos apresentar a especificação do CoDIMS, iniciando pelo diagrama de componentes. A especificação é em UML, usando uma notação extendida proposta na tese do Mafé. O CoDIMS é um ambiente orientado a objetos baseado em componentes. Cada componente é um framework. A comunicação entre os componenets é realizada pelo componente Controle. A arquitetura do CoDIMS permite a utilização de componentes já existentes, inclusive remotos.

26 Interfaces dos Componentes
Como podemos obervar o Componente Controle é um broker para a comunicação entre os componentes. A comunicação entre eles é realizada através de suas interfaces, que são modeladas pelo pattern facade.

27 Controle O componente Controle apresenta 3 módulos principais:
O módulo Configuração para registrar a configuração física do sistema configurado. O módulo workflow para registrar a configuração lógica. E o módulo Escalonador para em tempo de execução identificar a requisição global submetida e escalonar as operações necessárias à execução. O Controle disponibiliza uma API para a aplicação cliente. O Controle é um framework e permite diferentes formas de comunicação entre os componentes do CoDIMS. No nosso caso utilizamos RMI, mas poderiam ser utilizados outros padrões.

28 Configuração Física Para o processo de configuração física é necessário criar um arquivo de script, contendo os componentes e as operações oferecidas e as requisitadas, e submete-lo através da operação definir-configuração. O sistema verifica se todas as operações a serem requisitadas foram devidamente oferecidas.

29 Configuração Lógica Para o processo de configuração lógica, também é necessário criar um arquivo de script, contendo as funcionalidades oferecidas pelo sistema com o respectivo workflow. Este arquivo deve ser submetido através da operação definir-workflow. O sistema verifica se todas as operações constantes do workflow estão devidamente oferecidas e registradas na configuração física.

30 Execução de Consulta Por fim, o usuário submete uma consulta, o escalonador consulta o workflow para determinar o escalonamento e postriormente invocar as respectivas operações.

31 Arquitetura de Metadados
Aplicações c/ visão integrada … BDs Legados Internet Outros Antes de apresentar-mos o componente gerência de metadados, vamos a apresentar a arquitetura de metadados do CoDIMS. A arquitetura é em 4 níveis. Cada fonte de dados possui seus próprios metadados. Um subconjunto destes é disponibilidado para integração. Estes são então transformados em metadados de exportação, no modelo de dados do sistema configurado. Os metadados de exportação são então integrados formando o metadados global. As diferentes visões sobre os metadados global formam os esquemas externos, tal como nos SGBDs. Fontes de Dados

32 Gerência de Metadados …
Aqui podemos ver a especificação do componente gerência de metadados. Sua fachada é extensível, o que permite a definição de novas operações, bastando definí-las na configuração física e lógica. Vemos os 3 níveis de metadados: exportação, global e externo. Por ser um framework, podemos definir diferentes tipos de modelos de dados para diferentes sistemas configurados, mas apenas 1 por sistema: temos uma dependência semântica entre os diferentes níveis de metadados.

33 Processamento de Consulta
Aqui temos o componente processamento de consulta com seus módulos. A fachada é extensível, permitindo a definição de novos módulos. Por ser um framework, permite ser customizado para diferentes modelos de dados. Cada módulo pode ser customizado de acordo com os requisitos da aplicação e modelo de dados usado. Dada uma consulta global, o módulo análise realiza a análise léxica e sintática, gerando um grafo da consulta. O módulo reescritor agrupa os dados a serem acessados or fonte de dados, gerando uma árvore de operação. Esta árvore é otimizada pelo módulo otimização que gera uma árvore de execução a ser executada pelo módulo de processamento.

34 Acesso Aos Dados O componente Acesso aos Dados, como o nome diz, faz o acesso aos dados das fontes de dados. Para cada fonte de dados existe um wrapper que converte as sub-consultas e os dados do modelo de dados utilzado pelo sistema configurado para o modelo definido na fonte de dados. Podem existir várias formas de comunicação com as foontes de dados. Utilizamos RMI e JDBC.

35 Casos de Uso Vamos agora apresentar os caso de uso do ambiente CoDIMS:
O implementador, ou seja, o projetista do sistema configurado, define o projeto do sistema a ser configurado, seleciona e customiza os componentes de acordo com a aplicação. O configirador do sistema gera os arquivos de script e realiza o processo de configuração física e lógica. O Projetista da aplicação (DBA), define os metadados do sistema. E por fim o usuário final submete as consultas.

36 Estudo de Caso Uma aplicação necessita integrar dados de duas fontes de dados: Uma base de dados XML, contendo dados sobre pesca. Um banco de dados Relacional contendo dados sobre espécies de peixes.

37 Documento XML - Pesca

38 Banco de Dados - Espécie

39 Características da Aplicação
A aplicação requer consultas tais como: ”Obter local, data de desembarque, código da espécie e quantidade pescada, das espécies em período de reprodução”. Além disso deverá ser possível decidir sobre as formas de executar as consultas.

40 Aplicação requer somente consultar os dados
Projeto do Sistema Aplicação requer somente consultar os dados

41 Configuração Física - Exemplo
Define Component Metadados Offered-Operations definir-metadados ( string tipo-MD , arq-script int CR ); exibir-metadados arq obter-objeto-MD id nome-obj obj End-Component.

42 executar-sub-consulta
Configuração Física - Exemplo Define Component AcessoAosDados Offered-Operations executar-sub-consulta ( int id , string nome-FD , string sub-cons arq-res , int CR ); obter-próximo-dado (int dados End-Component.

43 Configuração Física - Exemplo
Define Component ProcessamentoDeConsulta Offered-Operations analisar-consulta ( int id , string cons grafo-cons , int CR ); reescrever-consulta (int arv-op otimizar-consulta (in t, string arv-exec processar-consulta arq-res ) Requested-Operations Metadados, obter-objeto-MD tipo-MD nome-obj , string obj , int AcessoAosDados, executar-sub-consulta nome-FD sub-cons AcessoAosDados, obter-próximo-dado dados End-Component.

44 ProcessamentoDeConsulta ( reescrever-consulta);
Configuração Lógica - Exemplo Define Workflow Select Operations ProcessamentoDeConsulta ( analisar-consulta); reescrever-consulta); otimizar-consulta); processar-consulta) End-Operations . Define um escalonamento para cada tipo de funcionalidade do sistema.

45 Configuração Lógica - Exemplo
Define Workflow Show Plan Operations ProcessamentoDeConsulta ( analisar-consulta); ProcessamentoDeConsulta ( reescrever-consulta); ProcessamentoDeConsulta ( otimizar-consulta) End-Operations . Define Workflow No Optmize Operations ProcessamentoDeConsulta ( analisar-consulta); ProcessamentoDeConsulta ( reescrever-consulta); ProcessamentoDeConsulta (processar-consulta) End-Operations . Define Workflow Compile Operations ProcessamentoDeConsulta (analisar-consulta) End-Operations .

46 Definição de Metadados

47 Definição de Metadados

48 Consulta

49 Implementação Desenvolvimento de um protótipo no TecBD para o estudo de caso. Foi utilizada a linguagem Java no ambiente Windows-NT. Os componentes foram desenvolvidos e compilados separadamente, sendo a comunicação entre eles via RMI. Como instrumento de validação do ambiente proposto, realizamos a implementação de um protótipo para o estudo de caso apresentado.

50 Conclusões O CoDIMS é um ambiente flexível para gerar sistemas configurados para integração de dados heterogêneos; O ambiente é baseado na seleção e integração de um conjunto adequado de componentes DIMS; Os componentes foram desenvolvidos utilizando a técnica de frameworks.

51 Conclusões O CoDIMS permite usar componentes e/ou serviços já disponíveis, inclusive remotos, como: Wrappers, Analisadores e Otimizadores de consulta etc.. Usar componentes já existentes aumenta a qualidade do software e diminui o tempo de desenvolvimento.

52 Conclusões Os mecanismos de configuração, física e lógica, permitem disponibilizar diferentes serviços e funcionalidades, de acordo com os requisitos da aplicação, como por exemplo: Linguagem de consulta; Modelo de dados integrador; Escalonamentos específicos.

53 Conclusões A abordagem CoDIMS é: “What you need is only what you get”.
(wynwyg)

54 Tópicos de Pesquisa Banco de Dados Flexíveis: Frameworks:
Flexibilidade e extensibilidade, integração de dados e integração com a Web. Frameworks: Sistemas configuráveis, arquitetura, reuso, componentes. Instanciação; Integração. Aplicações Web: Metadados, dados estruturados, semi-estruturados e não estruturados, XML. O desenvolvimento deste trabalho está relacionado aos seguinte tópicos de pesquisas: Na área de ...

55 Contribuições O desenvolvimento de um ambiente flexível e configurável para integração de dados heterogêneos; Implementação de um protótipo; Uma proposta de arquitetura dentro do contexto do projeto ECOBASE.

56 Publicações ECOHOOD: Constructing Configured DBMSs based on Frameworks. Melo, R.N.; Porto, F.A.M.; Lima, F. & Barbosa, A.C.P. XIII Simpósio Brasileiro de Banco de Dados, Maringá-PR, Brasil, Outubro 1998. Configurable Data Integration Middleware System. Barbosa, A.C.P. & Porto, F.A.M Proceedings of International Workshop on Information Integration on the Web: Technologies and Applications (WIIW2001), Rio de Janeiro, Abril 2001.

57 Trabalhos Futuros Especificação e desenvolvimento dos componentes Gerência de Regras, Gerência de Transação, Controle de Concorrência... Integração semântica dos componentes DIMS; Especificação do mecanismo de troca de mensagens entre os componentes;

58 Trabalhos Futuros Alteração do escalonamento (workflow) em tempo de execução; Desenvolvimento e reuso de componentes e de wrappers.

59 Tese de Doutorado Middleware para Integração de Dados Heterogêneos Baseado em Composição de Frameworks Aluno: Alvaro Cesar P Barbosa Orientador: Prof. Rubens Nascimento Melo Co-Orientador: Prof. Carlos José Pereira de Lucena

60 FIM

61 HEROS: HEteRogeneous Object System
Sistema HEROS HEROS: HEteRogeneous Object System Regra Esquema Consulta Interface usuário Transação Comunicação SBD locais

62 Sistema HEROS A necessidade da presença de todos os módulos em qualquer aplicação; A grande interconexão dos seus módulos, o que dificulta o processo de adaptação; Processo de instanciação por extensão e não por componentização; Impossibilidade de trocar componentes: Por exemplo, o modelo de dados sempre OO.

63 Processo de Configuração

64 Definição do Workflow

65 Diagrama de Seqüência

66 Diagrama de Seqüência

67 Frameworks Algumas questões sobre desenvolvimento de software:
Por que não existem catálogos de componentes de software tal como os de hardware? Por que não construir software escolhendo e combinando componentes de software? Por que não reusar software? Reuso é o processo de criar software a partir de software já existente, reduzindo o esforço de desenvolvimento. Framework é uma das técnicas de reuso, permitindo o reuso de análise, de projeto e de código.

68 Frameworks A técnica de reuso necessita de uma arquitetura para guiar a integração dos componentes. Arquitetura de software é uma descrição dos subsistemas e componentes de um sistema de software e dos relacionamentos entre eles. Framework é uma arquitetura semi-completa, que pode ser instanciada para produzir aplicações customizadas, permitindo construir sistemas flexíveis e configuráveis. Framework é uma forma particular de representar arquitetura de software na comunidade de Orientação a Objetos.

69 Frameworks Componentes de software são unidades de produção, aquisição e desenvolvimento independente que interagem para formar um sistema. Construir novas soluções a partir de componentes (criados ou adquiridos) aumenta a qualidade e diminui o tempo de desenvolvimento. Componentes em frameworks podem padronizar interfaces e código genérico para vários tipos de abstrações de software.

70 Frameworks Frameworks são formados por frozen spots e hot spots.
Frozen spots definem a arquitetura global do sistema, seus componentes básicos e os relacionamentos entre eles, ficando imutáveis. Hot spots são as partes específicas para cada sistema, sendo genéricos para poderem ser adaptados de acordo com a aplicação.

71 Frameworks A forma mais comum de se instanciar um framework é através de extensão (herança e escrita e código). Neste caso o framework é chamado whitebox. A instanciação de um framework por componentes é mais complexa pois estes podem ter interdependências, serem opcionais ou até mesmo serem conflitantes. Neste caso o framework é chamado blackbox. Componentes, por sua vez, podem ser frameworks. Integração de frameworks é um assunto novo e aberto na comunidade científica.

72 Frameworks Segundo Fayad & Schmidt, frameworks podem ser classificados em: Frameworks de Infra-Estrutura de Sistemas (sistemas operacionais, comunicação, interface, linguagens); Frameworks de Integração [Middleware] (integração de informações distribuídas e componentes). Permite modularizar, reusar e estender software de infra-estrutura. Utiliza algum tipo de framework de infra-estrutura. Frameworks de Aplicação (telecomunicações, manufatura, financeiro, saúde, educação).

73 Definição de Metadados