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

1. Gerência de configuração aplicada ao DBC: estado da arte Vanilson Burégio vaab@cin.ufpe.br

2. Roteiro • História • Contexto • Gerenciamento de componentes • GCS no DBC • Motivação • Questões • Abordagens • Ferramentas • Conclusão • Referências Reuse in Software Engineering Group

3. 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. 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. 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. História {anos 90} • Surgimento de produtosreais 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] Reuse in Software Engineering Group

7. História {anos 90} • Por outro lado... • Surge o DBC (Desenvolvimento Baseado em Componentes) • Produtividade • Qualidade • Competitividade Novas abordagens => Novos problemas Reuse in Software Engineering Group

8. GCS GCS Crise de Software GCS aplicada ao DBC 1960 1980 1990 DBC 1970 2000 Software customizado(distribuição limitada) Sistemas distribuídosHardware de baixo custo Tecnologias orientadas a objetoscomputação paralela DBC Produto de Software Evolução do Software História {Resumo} "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 Reuse in Software Engineering Group

10. Gerência de configuração Escopo Contexto {Gerenciamento de componentes} • Implementação de componentes • Documentação de componentes • (Re)Publicação de componentes • Notificar consumidores sobre novos componentes ou problemas Processo de Produção Processo de gerência Processo de Consumo Repositório de componentes Gerenciador de componentes Produtor Consumidor • 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 Reuse in Software Engineering Group

11. GCS no DBC {Motivação} • [Voas, 1998] • “Withoutrevision 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.” Reuse in Software Engineering Group

12. 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 integratedconfiguration management and component library environment.” Reuse in Software Engineering Group

13. 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 Reuse in Software Engineering Group

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

17. V 1.0 V 1.0 V 1.1 V 1.2 V. 1.1 V. 1.2 V 1.1 V 1.2 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: Componente vr. 1.1 Componente vr. 1.2 Reuse in Software Engineering Group

18. Sub-configuration Configuration Componente primitivo 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). • Configurationitem (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 Reuse in Software Engineering Group

19. The Construction and Evolution of Composite Components CompositeComponents Component Composition Advanced Evolution ConfigurationCriation BaselineCriation Configuration Modification Configuration Branching Relationship creation and Tracing Checkout and Checkin of PrimitiveComponents Branching and Merging of PrimitiveComponents Concurrency of PrimitiveComponents SCM Support The evolution of primitive components Component Development Component Adaptation Primitive Components GCS no DBC {Abordagens} • Modelo de GCS para DBC [Mei, 2001] Reuse in Software Engineering Group

20. Antes do merge Depois do merge 1.0 1.0 1.1 1.1 A Branch B C Merge 1.2 1.2.1.0 1.2 1.1 1.3 1.2.1.1 B C D 1.3 1.4 1.4 1.4 Merge A B C D 1.5 1.5 1.5 Merge Vertical 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 Reuse in Software Engineering Group Merge Horizontal

21. GCS no DBC {Abordagens} • Modelo de versionamento [Gergic, 2003] • SOFA/DCUP • Versões com mais informações (atributos/relações) • apache-1.3.9-8mdk-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") 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 Reuse in Software Engineering Group

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

24. 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 GCS no DBC {Ferramentas} Reuse in Software Engineering Group

25. 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) GCS no DBC {Ferramentas} Reuse in Software Engineering Group

26. 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 GCS no DBC {Ferramentas} Reuse in Software Engineering Group

27. 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 Reuse in Software Engineering Group

28. 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 – SCM10 (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