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

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

Gerência de configuração aplicada ao DBC: estado da arte

Apresentações semelhantes


Apresentação em tema: "Gerência de configuração aplicada ao DBC: estado da arte"— Transcrição da apresentação:

1 Gerência de configuração aplicada ao DBC: estado da arte
Vanilson Burégio

2 Reuse in Software Engineering Group
Roteiro História Contexto Gerenciamento de componentes GCS no DBC Motivação Questões Abordagens Ferramentas Conclusão Referências Estrutura da apresentação Motivação (Por que GC em DBC??) Engenharia de software baseada em componentes (Szyperski, 1998) está se tornando amplamente aceita como uma abordagem eficaz em termos de custos para o desenvolvimento de software Ex de uso bem-sucedido.: Visual Basic, Visual C++ com componentes, Java com JavaBeans Existem custos e problemas associados com o reuso que podem inibir a introdução desse método e significar que as reduções no custo total de desenvolvimento, com o reuso, serão menores do que as previstas. Problemas com reuso: Falta de ferramentas de apoio Aumento nos custos de manutenção Manutenção de uma biblioteca de componentes Encontrar e adaptar componentes reutiulizáveis Crescimento na adoção de DBC na indústria de SW Produtividade Qualidade Competitividade Novas abordagens => Novos problemas [Voas, 1998] muito mais difíceis de manter, certificar e validar preciso repensar as técnicas atuais de manutenção [Voas, 1998] uso de componentes implica em uma nova definição de operações e objetos que devem ser tratados em um modelo de gerência de configuração para componentes Mei[2001] Quais os principais problemas? Que soluções existem? Será que funcionam? Técnicas tradicionais de GCS não suportam DBC DBC Abordagem baseada em reuso para o desenvolvimento de sistemas cada vez mais cada vez mais adotada na indústria de software Motivação: frustação na utilização da OO... Novos problemas Necessitam de gerenciamento Dificuldade de gerenciar componentes Técnicas existentes na GC não são adequadas ao modelo de componentes Emergiu no final da década de 90 O que existe em termos de GC aplicada a DBC??? GCS Surgiu na crise de SW Hoje: bem madura e estável no desenvolvimento de SW tradicional Conceitos Básicos Elementos operações - não existe um padrão para definição de componente - Definição bem utilizada: Sipersski As CBD becomes more widely accepted as the way to build todays distributed applications, concern shifts from component technology to component-based development approaches Making the Move from Component Technology to Component-Based Development, Alan Brown Article in Component Strategies – April 1999 They have changed the way applications are being developed, maintained, and upgraded In the past, application systems were used primarily to support core business functions DIFERENCIAL ENTRE EMPRESAS: Today, application systems are also often the means by which a company differentiates itself from its competitors CBD provides a view of application development as an assembly process based on well-defined pieces of system functionality GCS no DBC {problemas Atuais} - listar os problemas citados nos resumos Soluções existentes Fazer um agrupamento das soluções de acordo com os problemas citados - Versionamento (O q temos hj) (Process Model for Application Development ) Microsoft : Versioned releases enable the project team to respond to continuous changes in scope, schedule, and project risk. - SOFA - DCUP - ... Browser .... - Update de componentes - .... Conclusão Reuse in Software Engineering Group

3 Reuse in Software Engineering Group
História {anos 60} Desenvolvimento de software em larga escala Programação não é tudo!! Estrutura do software (Arquitetura?) Building? Evolução? Crise de Software Reuse in Software Engineering Group

4 Reuse in Software Engineering Group
História {anos 70} Busca de soluções… Notações Técnicas Ferramentas Case Surgimento do gerenciamento de configuração “A arte de coordenar o desenvolvimento de software para minimizar …a confusão…” [Babich, 1986] Reuse in Software Engineering Group

5 Reuse in Software Engineering Group
História {anos 80} Gerência de Configuração de Software (GCS) Versionamento Rebuilding Composição Primeiros sistemas “caseiros” para controle de arquivos Scripts Unix sobre RCS (ferramenta simples de controle de versão) e Make Reuse in Software Engineering Group

6 Reuse in Software Engineering Group
História {anos 90} Surgimento de produtos reais de GCS Sem suporte a processo, apenas controle de arquivo Suporte a workspace Líderes de mercado: ClearCase, Continuus Segunda metade dos anos 90… Consagração da GCS essencial no desenvolvimento de software tecnologia bem estabelecida suporte a processo 1998: mais de $1bilhão de vendas! [Estublier, 2000] Uso de banco de dados relacionais Reuse in Software Engineering Group

7 Reuse in Software Engineering Group
História {anos 90} Por outro lado... Surge o DBC (Desenvolvimento Baseado em Componentes) Produtividade Qualidade Competitividade Estrutura da apresentação Motivação (Por que GC em DBC??) Engenharia de software baseada em componentes (Szyperski, 1998) está se tornando amplamente aceita como uma abordagem eficaz em termos de custos para o desenvolvimento de software Ex de uso bem-sucedido.: Visual Basic, Visual C++ com componentes, Java com JavaBeans Existem custos e problemas associados com o reuso que podem inibir a introdução desse método e significar que as reduções no custo total de desenvolvimento, com o reuso, serão menores do que as previstas. Problemas com reuso: Falta de ferramentas de apoio Aumento nos custos de manutenção Manutenção de uma biblioteca de componentes Encontrar e adaptar componentes reutiulizáveis Crescimento na adoção de DBC na indústria de SW Produtividade Qualidade Competitividade Novas abordagens => Novos problemas [Voas, 1998] muito mais difíceis de manter, certificar e validar preciso repensar as técnicas atuais de manutenção [Voas, 1998] uso de componentes implica em uma nova definição de operações e objetos que devem ser tratados em um modelo de gerência de configuração para componentes Mei[2001] Quais os principais problemas? Que soluções existem? Será que funcionam? Técnicas tradicionais de GCS não suportam DBC DBC Abordagem baseada em reuso para o desenvolvimento de sistemas cada vez mais cada vez mais adotada na indústria de software Motivação: frustação na utilização da OO... Novos problemas Necessitam de gerenciamento Dificuldade de gerenciar componentes Técnicas existentes na GC não são adequadas ao modelo de componentes Emergiu no final da década de 90 O que existe em termos de GC aplicada a DBC??? GCS Surgiu na crise de SW Hoje: bem madura e estável no desenvolvimento de SW tradicional Conceitos Básicos Elementos operações - não existe um padrão para definição de componente - Definição bem utilizada: Sipersski As CBD becomes more widely accepted as the way to build todays distributed applications, concern shifts from component technology to component-based development approaches Making the Move from Component Technology to Component-Based Development, Alan Brown Article in Component Strategies – April 1999 They have changed the way applications are being developed, maintained, and upgraded In the past, application systems were used primarily to support core business functions DIFERENCIAL ENTRE EMPRESAS: Today, application systems are also often the means by which a company differentiates itself from its competitors CBD provides a view of application development as an assembly process based on well-defined pieces of system functionality GCS no DBC {problemas Atuais} - listar os problemas citados nos resumos Soluções existentes Fazer um agrupamento das soluções de acordo com os problemas citados - Versionamento (O q temos hj) (Process Model for Application Development ) Microsoft : Versioned releases enable the project team to respond to continuous changes in scope, schedule, and project risk. - SOFA - DCUP - ... Browser .... - Update de componentes - .... Conclusão Novas abordagens => Novos problemas Reuse in Software Engineering Group

8 Reuse in Software Engineering Group
História {Resumo} GCS 1960 1970 1980 1990 2000 Crise de Software DBC Evolução do Software Produto de Software Software customizado (distribuição limitada) Sistemas distribuídos Hardware de baixo custo Tecnologias orientadas a objetos computação paralela GCS aplicada ao DBC "Software developers’principle tasks will shift from coding to designing and integrating“ [Voas, 1998] Reuse in Software Engineering Group

9 Contexto {Gerenciamento de componentes}
[Apperly, 2001] Processo de produção-gerência-consumo Produtor: implementa componentes Consumidor: busca e usa componentes Gerenciador de componentes: interface entre produtor e consumidor Mais que um repositório estático de componentes Deve possuir interfaces com os serviços necessários aos produtores e consumidores de componentes Gerenciador de componentes Similar à um pátio de construção na engenharia civil Reuse in Software Engineering Group

10 Contexto {Gerenciamento de componentes}
Processo de Produção Processo de gerência Processo de Consumo Repositório de componentes Gerência de configuração O gerenciador de componentes deverá possuir serviços disponíveis nas suas interfaces com os produtores e consumidores Como por exemplo: publicação de componentes; busca de componentes, etc.... Produtor Gerenciador de componentes Consumidor Implementação de componentes Documentação de componentes (Re)Publicação de componentes Notificar consumidores sobre novos componentes ou problemas Gerência do repositório Gerência dos usuários do repositório Controle de qualidade Controle da disponibilidade Gerência de componentes Gerência de versões dos componentes Busca de componentes Especificação de componentes a serem produzidos Uso/reuso de componentes Deploy de componentes Registrar interesse em componentes Escopo Reuse in Software Engineering Group

11 Reuse in Software Engineering Group
GCS no DBC {Motivação} [Voas, 1998] “Without revision control, the component maintenance process will bring more disaster than benefit to your application development process” [Mei, 2001] “More and more software development organizations have noticed the importance of SCM, and viewed SCM as their infrastructure for software development.” Estrutura da apresentação Motivação (Por que GC em DBC??) Engenharia de software baseada em componentes (Szyperski, 1998) está se tornando amplamente aceita como uma abordagem eficaz em termos de custos para o desenvolvimento de software Ex de uso bem-sucedido.: Visual Basic, Visual C++ com componentes, Java com JavaBeans Existem custos e problemas associados com o reuso que podem inibir a introdução desse método e significar que as reduções no custo total de desenvolvimento, com o reuso, serão menores do que as previstas. Problemas com reuso: Falta de ferramentas de apoio Aumento nos custos de manutenção Manutenção de uma biblioteca de componentes Encontrar e adaptar componentes reutiulizáveis Crescimento na adoção de DBC na indústria de SW Produtividade Qualidade Competitividade Novas abordagens => Novos problemas [Voas, 1998] muito mais difíceis de manter, certificar e validar preciso repensar as técnicas atuais de manutenção [Voas, 1998] uso de componentes implica em uma nova definição de operações e objetos que devem ser tratados em um modelo de gerência de configuração para componentes Mei[2001] Quais os principais problemas? Que soluções existem? Será que funcionam? Técnicas tradicionais de GCS não suportam DBC DBC Abordagem baseada em reuso para o desenvolvimento de sistemas cada vez mais cada vez mais adotada na indústria de software Motivação: frustação na utilização da OO... Novos problemas Necessitam de gerenciamento Dificuldade de gerenciar componentes Técnicas existentes na GC não são adequadas ao modelo de componentes Emergiu no final da década de 90 O que existe em termos de GC aplicada a DBC??? GCS Surgiu na crise de SW Hoje: bem madura e estável no desenvolvimento de SW tradicional Conceitos Básicos Elementos operações - não existe um padrão para definição de componente - Definição bem utilizada: Sipersski As CBD becomes more widely accepted as the way to build todays distributed applications, concern shifts from component technology to component-based development approaches Making the Move from Component Technology to Component-Based Development, Alan Brown Article in Component Strategies – April 1999 They have changed the way applications are being developed, maintained, and upgraded In the past, application systems were used primarily to support core business functions DIFERENCIAL ENTRE EMPRESAS: Today, application systems are also often the means by which a company differentiates itself from its competitors CBD provides a view of application development as an assembly process based on well-defined pieces of system functionality GCS no DBC {problemas Atuais} - listar os problemas citados nos resumos Soluções existentes Fazer um agrupamento das soluções de acordo com os problemas citados - Versionamento (O q temos hj) (Process Model for Application Development ) Microsoft : Versioned releases enable the project team to respond to continuous changes in scope, schedule, and project risk. - SOFA - DCUP - ... Browser .... - Update de componentes - .... Conclusão Reuse in Software Engineering Group

12 Reuse in Software Engineering Group
GCS no DBC {Motivação} [Apperly, 2001] “One of the primary ways to enable a successful component development life cycle is to implement a process that includes an integrated configuration management and component library environment.” Reuse in Software Engineering Group

13 Reuse in Software Engineering Group
GCS no DBC {Questões} [Mei, 2001] Visualizar um componente como um item de configuração (IC) e operar sobre componentes e não sobre arquivos individuais Controlar modificações concorrentes em cada componente Gerenciar a composição e relacionamentos entre componentes [Apperly, 2001] Suportar os níveis de abstração de um componente [Larsson, 2001] manter o rastreamento de componentes e seus inter-relacionamentos Técnicas tradicionais de GCS não suportam DBC Gerenciador de componentes Similar à um pátio de construção na engenharia civil Técnicas tradicionais de GCS não suportam DBC Reuse in Software Engineering Group

14 Reuse in Software Engineering Group
GCS no DBC {Questões} Gerenciamento de versões Identificação de versões Estabelecer nomenclatura padrão Informações a serem consideradas? Evolução dos componentes relacionamentos internos relacionamentos externos Gerenciamento de Mudanças Manter a consistência Diferentes níveis de compatibilidade Análise de impactos controle de dependências rastreabilidade Gerenciador de componentes Similar à um pátio de construção na engenharia civil Reuse in Software Engineering Group

15 GCS no DBC {Abordagens}
Níveis de abstração [Apperly, 2001] Modelo de GCS para DBC [Mei, 2001] Modelo de versionamento [Gergic, 2003] Atualização de componentes [Plasil, 1997] [Cook, 1999] [Vandewoude, 2002] Controle de dependências [Lucas, 1997] [Larsson, 2001] Reuse in Software Engineering Group

16 GCS no DBC {Abordagens}
Níveis de abstração [Apperly, 2001] Especificação Java C# C++ ... Uma especificação pode possuir mais de uma implementação Implementação .exe .dll .jar ... Uma implementação pode possuir mais de um executável Executável Deploy 1 Deploy 2 Deploy 3 ... Um executável pode possuir mais de um deploy Deployment Componente Problema: gerenciar os links (dependências) existentes entre cada nível de abstração do componente Reuse in Software Engineering Group

17 GCS no DBC {Abordagens}
Gerência de componentes [Apperly, 2001] Tarefa difícil! Grande necessidade de ferramentas Componente deve ser visto sob seus diferentes níveis de abstração Gerenciamento de versões [Apperly, 2001] Identificação de versão Cada nível de abstração também precisa ser identificado Exemplo: Gerência de componentes Não é tarefa fácil Repositório deve ser capaz de armazenar informações distintas dos 4 níveis de abstração de um componente Ideal (ferramenta): links entre cada um dos níveis ser mostrado e visualizado como gráfico V 1.0 V 1.1 V. 1.1 V 1.0 V 1.2 V. 1.2 Componente vr. 1.1 Componente vr. 1.2 Reuse in Software Engineering Group

18 GCS no DBC {Abordagens}
Modelo de GCS para DBC [Mei, 2001] Conceitos básicos File: unidades de armazenamento, não representam constituintes lógicas Component: constituinte lógica do sistema (componentes primitivos e componentes compostos) Configuration: configurations representam componentes compostos (conjunto de configuration item). Configuration item (CI): componente primitivo ou configuração existente Baseline: versão de uma configuração (configuration). Formada pela seleção de uma versão ou baseline de cada CI na configuração. Relationship: representa as relações entre componentes. Ex.: relação de dependência Conceitos básicos §         File: unidades de armazenamento, não representam constituintes lógicas §         Component: constituinte lógica do sistema (componentes primitivos e componentes compostos) §         Configuration e configuration item: configurations são usados para representar componentes compostos Uma configuration como um item de configuração em outra configuration é chamada de sub-configuration §         Baseline: uma nova baseline de uma configuration pode é criada a partir da seleção de uma versão ou baseline de cada componente da configuração. Praticamente representa a versão de uma configuração §         Relationship: representa as relações entre componentes. Ex.: relação de dependência Configuration Componente primitivo Sub-configuration Reuse in Software Engineering Group

19 GCS no DBC {Abordagens}
Modelo de GCS para DBC [Mei, 2001] The Construction and Evolution of Composite Components Composite Components The evolution of primitive components Primitive Components Component Adaptation Component Development Component Composition Advanced Evolution Configuration Criation Baseline Criation Configuration Modification Configuration Branching Checkout and Checkin of Primitive Components Branching and Merging of Primitive Components Concurrency of Primitive Components Relationship creation and Tracing SCM Support Questões chaves do modelo proposto o        Manutenção de consistência §         para componentes primitivos: qualquer versão do componente deve ser logicamente um componente; a verificação da consistência depende do modelo de componentes adotado §         para configurações: 1 - em qualquer baseline da configuração os componentes devem estar logicamente compostos (isso pode ser verificado a partir das descrições dos componentes); 2 – logicamente qualquer baseline da configuração deve ser um componente, a verificação disso dependerá do modelo de componentes adotado §         consistência entre versões/baselines vizinhas: qualquer versão/baseline vizinha deverá estar de acordo com as versões das mesmas especificações de projeto e requisitos dos componentes correspondentes. (não entendi??) o        Estratégia de concorrência: exclusive-write para arquivos, isso evitará a modificação simultânea de um determinado arquivo do componente. O estilo de adotado para modificação do componente é então o de checkout-edit-checkin. o        Merging horizontal e vertical: o horizontal faz o merge de versões do componente em linhas de desenvolvimento diferentes, sendo o resultado final a união dos arquivos “mergiados” (se necessário) de cada versão do componente. O merge vertical: merge de várias versões vizinhas do componente em uma única versão; ameniza o problema de crescimento rápido da árvore de versões de um componente primitivo. Reuse in Software Engineering Group

20 GCS no DBC {Abordagens}
Questões chaves do modelo [Mei, 2001] Manutenção de consistência Qualquer versão/baseline deve ser logicamente um componente Estratégia de concorrência Para arquivos: exclusive-write modificação do componente: estilo checkout-edit-checkin Merging horizontal e vertical Árvore de versão de um componente primitivo 1.0 1.1 1.2 1.3 1.4 Antes do merge Merge Vertical 1.5 1.0 1.1 1.4 Depois do merge 1.5 Merge 1.0 Questões chaves do modelo proposto o        Manutenção de consistência §         para componentes primitivos: qualquer versão do componente deve ser logicamente um componente; a verificação da consistência depende do modelo de componentes adotado §         para configurações: 1 - em qualquer baseline da configuração os componentes devem estar logicamente compostos (isso pode ser verificado a partir das descrições dos componentes); 2 – logicamente qualquer baseline da configuração deve ser um componente, a verificação disso dependerá do modelo de componentes adotado §         consistência entre versões/baselines vizinhas: qualquer versão/baseline vizinha deverá estar de acordo com as versões das mesmas especificações de projeto e requisitos dos componentes correspondentes. (não entendi??) o        Estratégia de concorrência: exclusive-write para arquivos, isso evitará a modificação simultânea de um determinado arquivo do componente. O estilo de adotado para modificação do componente é então o de checkout-edit-checkin. o        Merging horizontal e vertical: o horizontal faz o merge de versões do componente em linhas de desenvolvimento diferentes, sendo o resultado final a união dos arquivos “mergiados” (se necessário) de cada versão do componente. O merge vertical: merge de várias versões vizinhas do componente em uma única versão; ameniza o problema de crescimento rápido da árvore de versões de um componente primitivo. Componentes são formados por vários arquivos, modificação em cada arquivo deve gerar uma nova versão do componente.... Logo, a frequência de geração de versões de um componente pode ser MUITO grande... O merge vertical deve ser utilizado nesses casos... Unificar versões, agrupar versões verticalmente 1.1 A B C Branch 1.2 1.3 B C D 1.4 1.5 Merge A B C D Merge Horizontal Reuse in Software Engineering Group

21 GCS no DBC {Abordagens}
Modelo de versionamento [Gergic, 2003] SOFA/DCUP Versões com mais informações (atributos/relações) apache mdk-i586.rpm Repositório de versões Contém informações de todas entidades versionadas Busca com MQL (M-Cube Query Language) SELECT component_implementations HAVING (OS successor "Win95") Modelo de versionamento Modelo desenvolvido para o SOFA/DCUP mas que, segundo o autor, pode ser aplicado em qualquer modelo de componentes Apresenta um bom overview a respeito das questões a serem consideradas no versionamento de componentes e também Como podemos acrescentar mais informações nas versões, tornando-as mais legíveis e com mais semântica Informações de versões: atributos e relações, taxonomias, etc.... Exemplo: apache mdk-i586.rpm entidade=apache, revisão=1.3.9, release=8mdk, processador=i586 Relação: descreve conexões entre componentes versionados Exemplo de relação: OS=linux Questões de versionamento de componentes: . Estabelecer nomenclatura padrão para identificação de versões . Como descrever entidades versionadas usando atributos de versão e como capturar relações entre entidades Relacionadas - Quais os atributos uma versão deve conter? - Que informações devem ser consideradas? Solução tratada no paper: criação de um repositório de versões, onde o usuário poderá realizar buscas de componentes através da linguagem de consulta: M-cube (MQL) O meta-repositorio possui informações especificas do modelo de componente a ser utilizado Reuse in Software Engineering Group

22 GCS no DBC {Abordagens}
Atualização de componentes DCUP [Plasil, 1997] Dynamkic Component Updating (Java/CORBA) Framework Hercules [Cook, 1999] Atualização de componentes com suporte a múltiplas versões simultâneas em tempo de execução Atualizações dinâmicas [Vandewode, 2002] SEESCOA – sistema de componentes em Java com suporte a atualizações dinâmicas Informações de versão incluídas nas classes Java quando carregadas Controle de dependências Contratos de reuso [Lucas, 1997] Dependências controladas através de documentação Especificação de dependências [Larsson, 2001] Dependency Browser Questões chaves do modelo proposto o        Manutenção de consistência §         para componentes primitivos: qualquer versão do componente deve ser logicamente um componente; a verificação da consistência depende do modelo de componentes adotado §         para configurações: 1 - em qualquer baseline da configuração os componentes devem estar logicamente compostos (isso pode ser verificado a partir das descrições dos componentes); 2 – logicamente qualquer baseline da configuração deve ser um componente, a verificação disso dependerá do modelo de componentes adotado §         consistência entre versões/baselines vizinhas: qualquer versão/baseline vizinha deverá estar de acordo com as versões das mesmas especificações de projeto e requisitos dos componentes correspondentes. (não entendi??) o        Estratégia de concorrência: exclusive-write para arquivos, isso evitará a modificação simultânea de um determinado arquivo do componente. O estilo de adotado para modificação do componente é então o de checkout-edit-checkin. o        Merging horizontal e vertical: o horizontal faz o merge de versões do componente em linhas de desenvolvimento diferentes, sendo o resultado final a união dos arquivos “mergiados” (se necessário) de cada versão do componente. O merge vertical: merge de várias versões vizinhas do componente em uma única versão; ameniza o problema de crescimento rápido da árvore de versões de um componente primitivo. Componentes são formados por vários arquivos, modificação em cada arquivo deve gerar uma nova versão do componente.... Logo, a frequência de geração de versões de um componente pode ser MUITO grande... O merge vertical deve ser utilizado nesses casos... Unificar versões, agrupar versões verticalmente Reuse in Software Engineering Group

23 GCS no DBC {Ferramentas}
JBCM [Zhang, 2001] Sistema de gerenciamento de configuração de componentes Baseado no modelo proposto por Mei (2001) High-Level Management Function Change Control Build Support Audit Control Status Report Process Control Basic Management Function Version Control and Concurrency Control of Primitive Components Configuration Support Relationship Support Mechanism Mechanism of Version Control and Concurrency Control of Primitive Components Arquitetura Reuse in Software Engineering Group

24 GCS no DBC {Ferramentas}
Dependency Browser [Larsson, 2001] Ferramenta para análise de dependências Monta grafos de dependências Nós: componentes Arestas: dependências Protótipo analisou dependências ente os componentes do Windows 2000 Reuse in Software Engineering Group

25 GCS no DBC {Ferramentas}
Aonix Select component Manager Gerenciador de componentes Parte de um conjunto de soluções (Select Business Solution) Independente da tecnologia de componentes Suporta os níveis de abstração apresentados em Apperly (2001) Reuse in Software Engineering Group

26 GCS no DBC {Ferramentas}
Microsoft Visual component Manager Gerenciador de componentes integrado ao ambiente de desenvolvimento da MS (Visual Studio) Permite publicação, busca e reuso de componentes em um repositório Component-based software development is the newest and most powerful way to build complex business applications. Instead of constantly reinventing the wheel, developers of component-based applications can simply "plug in" existing components that contain the needed functionality. When the right component doesn't already exist, it can be written once, and then cataloged for future reuse and sharing with other applications. With Visual Component Manager you can publish components to a repository-based catalog, where they can easily be located, inspected, retrieved, and reused. The following sections provide information to acquaint you with the important concepts of Visual Component Manager. When you publish a component, you add it to a Microsoft Repository database. This can be a local (Microsoft Access) database on your own workstation, or it can be a shared Microsoft SQL Server database Reuse in Software Engineering Group

27 Reuse in Software Engineering Group
Conclusão Técnicas tradicionais de GC não podem ser aplicadas diretamente em componentes nova definição de operações e objetos GCS aplicada ao DBC Área de pesquisa recente Muitos problemas a serem resolvidos Controle de versão é apenas uma questão! Falta de ferramentas com uso prático comprovado Ferramentas dependentes de tecnologia de componentes específica Soluções ainda não foram testadas na prática Geralmente atendem a um modelo de componentes específicos ou ferramenta/ambiente de desenvolvimento Muitas questões/problemas ainda estão em aberto É difícil uma solução única pois muitas coisas dependem do modelo de componentes utilizado.... Possível tese: desenvolver um mecanismo de gerencia de configuração para um repositório de componentes E modelo de componentes definidos pelo RiSE!!! Reuse in Software Engineering Group

28 Reuse in Software Engineering Group
Referências [Estublier, 2000] Jacky Estublier, Software Configuration Management: A Roadmap, ACM Press, 2000. [Babich, 1986] W. A. Babich, Software Configuration Management, Addison-Wesley,1986. [Apperly, 2001] Hedley Apperly, Configuration Management and Component Libraries, In Component-Based Software Engineering: Putting the Pieces Together, Addison Wesley, 2001. [Gergic, 2003] Jaroslav Gergic, Towards a Versioning Model for Component-based Software Assembly, 2003. [Larsson, 2001] Magnus Larsson, Crnkovic Ivica, Configuration management for component-based systems, In the Tenth International Workshop on Software Configuration Management – SCM 10 (ICSE 2001), Toronto, Canada, May 2001 [Mei, 2001] Hong Mei, Lu Zhang, Fuqing Yang, A Software Configuration Management Model for Supporting Component-Based Software Development, Peking University, 2001 [Voas, 1998] Jeffrey Voas, Maintaining Component-Based Systems, IEEE Software,1998 Reuse in Software Engineering Group


Carregar ppt "Gerência de configuração aplicada ao DBC: estado da arte"

Apresentações semelhantes


Anúncios Google