Engenharia de Software. Prof. Raquel Silveira

Transcrição

1 Engenharia de Software Prof. Raquel Silveira

2 MOTIVAÇÃO Você já perdeu alguma versão anterior do arquivo do projeto? Já teve problemas em manter diferentes versões do sistema rodando ao mesmo tempo? Alguém já sobrescreveu o seu código por acidente e você acabou perdendo seu arquivo? Você tem dificuldades em saber quais as alterações que foram efetuadas e quando foram feitas e quem fez?

3 MOTIVAÇÃO

4 INICIANDO... GESTÃO DE CONFIGURAÇÃO Em qualquer time, um certo grau de confusão é inevitável. O objetivo é minimizar a confusão de modo que mais trabalho possa ser feito. A arte de coordenar o desenvolvimento de software para minimizar esse tipo particular de confusão é chamada de Gerência de Configuração W.A. BabichSoftware Configuration Management. Addison-Wesley, 1986.

5 O QUE É GERÊNCIA DE CONFIGURAÇÃO? Gerência de configuração (GC) é o processo de identificar, organizar e controlar modificações ao software sendo construído. A idéia é maximizar a produtividade minimizando os enganos.

6 OBJETIVOS DA GERÊNCIA DE CONFIGURAÇÃO? Definir o ambiente de desenvolvimento. Definir políticas para controle de versões, garantindo a consistência (constância, estabilidade) dos artefatos produzidos. Definir procedimentos para solicitações de mudanças. Administrar o ambiente e auditar mudanças. Facilitar a integração das partes do sistema.

7 O QUE É GERÊNCIA DE CONFIGURAÇÃO? Em outras palavras, a Gerência de Configuração de Software tem como objetivo responder as seguintes perguntas: O que mudou e quando? (Controle de Versões) Por que mudou? (Controle de Mudanças) Quem fez a mudança? (Auditoria) Podemos reproduzir esta mudança? (Auditoria)

8 O QUE FAZ?

9 Controle de Versão: dá um controle maior sobre tudo o que se altera no software (histórico de mudanças) Controle de Mudanças: motivo de uma configuração ter sido mudada para outra configuração Integração Contínua: atualização junto ao repositório

10 Ferramentas de Apoio

11 CONCEITOS BÁSICOS GESTÃO DE CONFIGURAÇÃO CONFIGURAÇÃO Um projeto de desenvolvimento de software produz os seguintes itens: Programas (código fonte, programas executáveis, bibliotecas de componentes, etc.) Documentação (manuais do usuário, documento de requisitos, modelo de análise e projeto, etc.) Dados (dados de teste e do projeto) Esses conjuntos de itens são chamados, coletivamente, de configuração do software.

12 ITENS DE CONFIGURAÇÃO Um conjunto de itens de hardware e/ou software vistos como uma entidade única para fins de gerência de configuração Um item de configuração está sujeito a mudanças e essas devem obedecer às políticas estabelecidas Normalmente, um item de configuração é estabelecido para cada pedaço de software que pode ser projetado, implementado e testado de forma independente

13 REPOSITÓRIO Local (físico e lógico) onde os itens de um sistema são guardados Pode conter diversas versões do sistema Utiliza mecanismos de controle de acesso Desenvolvedor Repositório

14 Exercício Uma equipe está desenvolvendo um sistema de automação comercial. No desenvolvimento já foram gerados os requisitos (especificação de requisitos funcionais e não-funcionais, casos de uso e glossário) e a implementação (código-fonte) A equipe está armazenando os dados numa máquina denominada SERVIDOR/PROJETO. - O que seria a configuração, os itens de configuração e o repositório?

15 CHECK-OUT / UPDATE Check-out cliente Repositório

16 CHECK-OUT / UPDATE Recupera a (última) versão de um item de configuração guardada no repositório Escrita Cria uma cópia, para edição, no cliente. Leitura Cria uma cópia no cliente.

17 CHECK-IN / COMITT Check-in cliente Repositório

18 CHECK-IN / COMITT Ação de inserir/atualizar um item de configuração no repositório Verifica o lock do item de configuração, caso o mesmo já exista Verifica e incrementa a versão do item Registra informações das mudanças (autor, data, hora, comentários) Inclui/atualiza o item

19 MERGE

20 MERGE Unificação de diferentes versões de um mesmo item de configuração Integração dos itens de configuração de um branch com os itens de configuração do fluxo principal Check-out atualizando a área local Algumas ferramentas fornecem um mecanismo automático para realização de merges Mesmo com o uso de ferramentas, em vários casos há necessidade de intervenção humana (atualização no mesmo trecho de código requer executar o merge entre as versões: repositório e local)

21 BRANCH

22 BRANCH

23 BRANCH Criação de um fluxo alternativo para atualização de versões de itens de configuração Recurso muito poderoso Devem existir regras bem definidas para criação de branches Por que e quando devem ser criados? Quais os passos? Quando retornar ao fluxo principal? Existe pelo menos um branch em um projeto. Qual?

24 BUILD Representa uma versão ainda incompleta do sistema em desenvolvimento, mas com certa estabilidade Costuma apresentar limitações conhecidas Espaço para integração de funcionalidades Inclui não só código fonte, mas documentação, arquivos de configuração, base de dados, etc. A política de geração dos builds deve ser bem definida na estruturação do ambiente

25 Exercício O desenvolvedor A necessita atualizar o projeto de desenvolvimento com o repositório para começar a trabalhar. No entanto, verifica que existe dois segmentos no repositório. O desenvolvedor B gera um novo código e deseja atualizar o repositório. No entanto, verifica que o desenvolvedor A também alterou o mesmo arquivo. O que seria check-in, check-out, build, branch e merge?

26 BASELINE Uma especificação ou produto que foi formalmente revisado e aceito: Serve como base para os passos posteriores do desenvolvimento A configuração do software em um ponto discreto no tempo. Só pode ser modificado através de procedimentos formais (solicitações de mudança). Um artefato ou conjunto de artefatos só se torna um item de configuração depois que um baseline é estabelecido. item fluxo de desenvolvimento REQ 1 IMPL 1 TESTE 1 tempo

27

28 RELEASE Identificação e empacotamento de artefatos entregues ao cliente (interno ou externo) ou ao mercado Um release implica no estabelecimento de um novo baseline de produto Produto de software supostamente sem erros Versão do sistema validada após os diversos tipos de teste Garantia de que todos os itens de configuração foram devidamente testados, avaliados, aceitos e estão disponíveis no novo baseline Processo iterativo/incremental produz, em geral, mais de um release

29 TAGS Rótulos que são associados a conjuntos de arquivos Um tag referencia um ou mais arquivos em um ou mais diretórios Costuma-se usar tags para: Denominar projeto rotulando todos os arquivos associados ao projeto Denominar uma versão do projeto (um build ou release) rotulando todos os arquivos associados ao build ou release

30 Exercício O analista de requisitos levanta todas as funcionalidades e escreve os casos de uso, denominando inicialmente de REQ_1. Os requisitos são enviados para o cliente com o nome REQ_CLIENTE_1. O cliente solicita modificações que são nomeadas para REQ_2. O caso de uso é finalizado provisoriamente para início da implementação com o nome REQ_FINAL_1. Quais das nomeações se refere a tag, release e baseline?

31 PROBLEMAS COM DADOS COMPARTILHADOS Desenvolvedor A Desenvolvedor B Programa de A A1 A2 A3 Componente Compartilhado Programa de B B1 B2 B3

32 PROBLEMAS COM DADOS COMPARTILHADOS O desenvolvedor A modifica o componente compartilhado; Mais tarde, o desenvolvedor B realiza algumas alterações no mesmo componente; Ao tentar compilar o componente, erros são apontados pelo compilador, mas nenhum deles ocorre na parte que B alterou; O desenvolvedor B não tem a menor idéia sobre a causa do problema.

33 PROBLEMAS COM MANUTENÇÃO MÚLTIPLA Desenvolvedor A Desenvolvedor B Programa de A Componente Compartilhado Componente Compartilhado Programa de B A1 A2 A3 B1 B2 B3 Versão de A do Componente Compartilhado Versão de B do Componente Compartilhado

34 PROBLEMAS COM MANUTENÇÃO MÚLTIPLA Ocorre quando cada desenvolvedor trabalha com uma cópia local do que seria o mesmo componente. Dificuldade para saber: Que funcionalidades foram implementadas em quais versões do componente Que defeitos foram corrigidos

35 PROBLEMAS COM ATUALIZAÇÃO SIMULTÂNEA Biblioteca Central de Recursos Compartilhados Desenvolvedor A Desenvolvedor B Programa de A Versão de A do Componente A1 A2 A3 B1 B2 B3 Compartilhado Componente Compartilhado Versão de B do Componente Compartilhado Programa de B

36 PROBLEMAS COM ATUALIZAÇÃO SIMULTÂNEA O desenvolvedor A encontra e corrige um defeito em sua versão do componente compartilhado; Uma vez corrigido, o componente modificado é copiado para a biblioteca central; O desenvolvedor B encontra e corrige o mesmo defeito em sua versão do componente por não saber que A já tinha feito isso; O trabalho de A é desperdiçado.

37 COMO RESOLVER?