With the aim of evaluating the internal and external of eggs of quality quail stored under refrigeration and at room temperature, we used 440 eggs Japanese quail collected after laying. The eggs were distributed in a completely randomized design in factorial 2x11 (2 storage temperature x 11 storage periods) with 20 repetitions. Analyses were performed on eggs at 0, 3, 6, 9, 12, 15, 18, 21, 24, 27 and 30 days of storage. The variables analyzed were weight loss (%), specific gravity (g / ml), yolk index and albumen percentages (%) of yolk, albumen and shell, shell thickness (mm), yolk color, pH albumen and yolk and Haugh Unit. Statistical analysis was performed using the System Analysis Statistical and Genetic (SAEG) and means compared by Newman Keuls test at 5% probability. Observed effect was (P<0,05) linear weight loss of eggs (%), specific gravity (g / ml), yolk index, albumen index, albumen percentage, yolk percentage, pH and yolk Haugh unit, in both storage temperatures. However, the pH of the albumen had an effect (P<0,05) quadratic for eggs stored at both storage temperatures. To eggshell percentage, shell thickness and yolk color not found a significant effect (P>0,05) among treatments. We conclude that Japanese quail eggs can be stored for up to 18 days at room temperature and 30 days under refrigeration. / Fundação de Amparo a Pesquisa do Estado de Alagoas / Com o objetivo de avaliar a qualidade interna e externa de ovos de codornas armazenados sob refrigeração e à temperatura ambiente, utilizou-se 440 ovos de codornas japonesas coletados após a postura. Os ovos foram distribuídos em um delineamento inteiramente casualizado em esquema fatorial 2x11 (2 temperaturas de armazenamento x 11 períodos de armazenamento) com 20 repetições. As análises foram efetuadas nos ovos com 0, 3, 6, 9, 12, 15, 18, 21, 24, 27 e 30 dias de armazenamento. As variáveis analisadas foram: perda de peso (%), gravidade específica (g/ml), índice de gema e de albúmen, porcentagens (%) de gema, albúmen e casca, espessura de casca (mm), coloração da gema, pH do albúmen e da gema e a Unidade Haugh. As análises estatísticas foram realizadas, utilizando o Sistema para Análises Estatísticas e Genética (SAEG) e as médias comparadas pelo teste Newman Keuls a 5% de probabilidade. Observou-se efeito (P<0,05) linear para perda de peso dos ovos (%), gravidade especifica (g/ml), índice de gema, índice de albúmen, porcentagem de albúmen, pH da gema e unidade Haugh, em ambas as temperaturas de estocagem e porcentagem de gema para os ovos armazenados sob refrigeração. Contudo, o pH do albúmen apresentou efeito (P<0,05) quadrático para os ovos armazenados em ambas as temperaturas de estocagem e a porcentagem de gema para os ovos armazenados em temperatura ambiente. Para porcentagem de casca, espessura da casca e coloração da gema não se constatou efeito significativo (P>0,05) entre os tratamentos. Concluiu-se que ovos de codornas japonesas podem ser armazenados por até 18 dias em temperatura ambiente e 30 dias sob refrigeração.

Desenvolvimento Guiado por Testes (TDD) e uma das praticas sugeridas na Programacao Extrema. A mecanica da pratica e simples: o programador escreve o teste antes de escrever o codigo. E, portanto, possivel inferir que a pratica de TDD e uma pratica de testes de software. Entretanto, muitos autores de livros conhecidos pela industria e academia afirmam que os efeitos da pratica vao alem. Segundo eles, TDD ajuda o desenvolvedor durante o processo de criacao do projeto classes, fazendo-os criar classes menos acopladas e mais coesas. Entretanto, grande parte dos trabalhos da literatura sao voltados a descobrir se a pratica faz diferenca na qualidade do codigo gerado, mas poucos sao os autores que discutem como a pratica realmente auxilia. Mesmo os proprios praticantes nao entendem ou conseguem expressar bem como a pratica os guia. Este trabalho tem por objetivo compreender melhor os efeitos de TDD e como sua pratica influencia o desenvolvedor durante o processo de projeto de sistemas orientados a objetos. Para entende-las, neste trabalho optamos por um estudo exploratorio essencialmente qualitativo, no qual participantes foram convidados a resolver exercicios pre-preparados utilizando TDD e, a partir dos dados colhidos nessa primeira parte, nos levantamos detalhes sobre como a pratica influenciou as decisoes de projeto de classes dos participantes por meio de entrevistas. Ao final, observamos que a pratica de TDD pode guiar o desenvolvedor durante o processo de criacao do projeto de classes por meio de constantes feedbacks sobre a qualidade do projeto. Esses feedbacks alertam desenvolvedores sobre possiveis problemas, como alto acoplamento ou baixa coesao. Os desenvolvedores, por sua vez, devem interpretar e melhorar o projeto de classes. Este trabalho catalogou e nomeou os padroes de feedback percebidos pelos participantes. / Test-Driven Development (TDD) is one of the suggested practices in Extreme Programming (XP). The mechanical is simple: the developer writes a test before writing the implementation. Thus, TDD is often seen as a software testing technique. However, many famous book authors suggest that TDD can help developers during the class design creation process, enabling developers to create less coupled highly cohesive classes. Most of the academic studies are interested on finding the difference between a TDDd and a non-TDDd code. Only a few of them discuss how the practice really supports class design. Even practitioners do not understand how the practice guides them. This work aims to understand better the effects of TDD and how the practice influences the practitioner during the class design process in object-oriented systems. To better understand them, we did a essencially qualitative explorative study, in which participants were invited to solve a set of pre-prepared exercises using TDD and, based on the gathered data, we retrieved details of how the practice influenced the developers class design decisions through interviews. At the end, we observed that the practice of TDD can guide developers during the class design creation process through constant feedback about its quality. These feedbacks alert developers about possible problems, such as high coupling or low cohesion. Developers then should interpret and improve the class design accordingly. This study also catalogues the TDD feedback patterns perceived by the participants.

Submitted by Celso Magalhaes (celsomagalhaes@ufrrj.br) on 2017-06-05T13:02:46Z No. of bitstreams: 1 2007 - Ana Paula Carvalho Magalh?es.pdf: 895321 bytes, checksum: 5c79ed9139248935b594927ccbd21bb4 (MD5) / Made available in DSpace on 2017-06-05T13:02:47Z (GMT). No. of bitstreams: 1 2007 - Ana Paula Carvalho Magalh?es.pdf: 895321 bytes, checksum: 5c79ed9139248935b594927ccbd21bb4 (MD5) Previous issue date: 2007-09-27 / The aim of this work was evaluate the internal and external quality of table eggs (unfertile) with or without microfissures, packed in conventional cardboard pulps or with plastic films (PVC), and stored for one or 14 days. Were used 160 white table eggs of Light Layers (Hy line-W36), collected in four different periods. Each fifteen days, 40 eggs from the same portion, separated by weight (between 52 and 58 grams), and selected according with the shell integrity, were classified as fissured or not fissured, by macroscopic visualization (twenty eggs per category). The evaluations that the present work handles, were carried out in the 1st and in the 14th day, after the laying, respectively. The experimental design was randomized blocks, with factorial arrangement (2x2x 2). The variables studied were: Haugh Unit (UH), yolk index (YI), albumen index (AI), Yolk pH (YpH), pH albumen (pHA), fungus incidence (FI), shell percentage (SP), shell thickness (ST) and air chamber (AC). There was effect (P<0.05) of the shell integrity on the SP and FI. Was observed an increase (P<0.05) in the SP to the eggs without fissure when compares to those with fissures, probably because of the higher water loss, promoted by the fissures. For the results of FI it was seen that there was a decrease (P<0.05) on fungus values to the eggs without shell fissure in relation to the fissured eggs. It was observed effect (P<0.05) of the packaging type on the variables UH and TS, with higher results seen in these variables when eggs were revested by PVC film. The time storage influenced (P<0.05) the UH, AC, YpH, ApH, YI and AI. Presenting higher results for (UG, YI and AI), and lower results for (AC, YpH, ApH) in the first day of storage.There was interaction of the packaging type time X of storage, when the eggs aconditionated in open packaging for 14th days presented higher values for fungus incidence, due to environment exposition and excess of humidity, allowing proliferation of these microorganisms. / Um experimento foi conduzido com o objetivo de se avaliar a qualidade interna e externa de ovos de mesa ?ntegros de casca ou com microfissuras, em embalagens convencionais de polpas de papel?o ou cobertos com filmes pl?sticos (PVC), armazenados por um ou 14 dias. Foram utilizados 160 ovos de mesa (inf?rteis) brancos, de poedeiras da linhagem Hy line- W36, coletados em 4 ?pocas diferentes. Quinzenalmente 40 ovos, provenientes sempre do mesmo lote foram separados por peso (entre 52 e 58 gramas ) para comporem os diversos tratamentos em igualdade de peso, no conjunto. Vinte desses ovos foram selecionados tamb?m de acordo com a integridade da casca, classificados como fissurados, por visualiza??o macrosc?pica e os restantes constitu?dos de casca integra. De cada uma dessas categorias descritas acima, 10 ovos foram acondicionados em embalagens de polpa de papel?o revestida por filme pl?stico (PVC) e os outros 10 no mesmo tipo de embalagem por?m sem filme de cobertura. As avalia??es de que trata o objetivo do presente trabalho, foram realizadas no 1? e no 14? dia ap?s a postura, respectivamente, com metade dos ovos de cada uma das embalagens citadas.O delineamento utilizado foi em blocos casualizados em esquema fatorial (2x2x2): 2 tipos de integridade de casca x 2 tipos de embalagens x 2 per?odos de armazenamento com 4 repeti??es cada um. As vari?veis estudadas foram: Unidade Haugh (UH), indice de gema (IG), indice de alb?mem (IA), pH gema (pHG), pH alb?mem (pHA), incid?ncia de fungos (IC), porcentagem de casca (PC), espessura de casca (EC) e tamanho da c?mara de ar (CA). Foi observado efeito significativo (P<0,05) da integridade da casca sobre as vari?veis PC e IC. Houve aumento significativo (P<0,05) na PC dos ovos sem fissura em rela??o aos ovos com fissuras, provavelmente decorrente da maior perda de ?gua, promovida pelas fissuras. Para os valores de IC, observou-se que houve decr?scimo de fungos na casca dos ovos sem fissura em rela??o aos ovos fissurados. Foi observado efeito (P<0,05) do tipo de embalagem sobre as vari?veis UH e EC, com maiores valores observados nessa variaveis quando revestidas por filme de PVC. P?de ser observado tamb?m, efeito (P<0,05) do tempo de armazenamento sobre as vari?veis UH, CA, pHG, pHA, IG e IA. Apresentando maiores valores para (UH, IG e IA) e menores valores para (CA, pHG e pHA) no 1? dia de armazenamento. Houve intera??o do tipo de embalagem X tempo de armazenamento, quando nos ovos acondicionados por 14 dias e embalagem aberta apresentaram maior contamina??o de fungos devido sua exposi??o ao ambiente e ao excesso de umidade, permitindo assim uma maior prolifera??o desses microoganismos.

Desenvolvimento Guiado por Testes (TDD) e uma das praticas sugeridas na Programacao Extrema. A mecanica da pratica e simples: o programador escreve o teste antes de escrever o codigo. E, portanto, possivel inferir que a pratica de TDD e uma pratica de testes de software. Entretanto, muitos autores de livros conhecidos pela industria e academia afirmam que os efeitos da pratica vao alem. Segundo eles, TDD ajuda o desenvolvedor durante o processo de criacao do projeto classes, fazendo-os criar classes menos acopladas e mais coesas. Entretanto, grande parte dos trabalhos da literatura sao voltados a descobrir se a pratica faz diferenca na qualidade do codigo gerado, mas poucos sao os autores que discutem como a pratica realmente auxilia. Mesmo os proprios praticantes nao entendem ou conseguem expressar bem como a pratica os guia. Este trabalho tem por objetivo compreender melhor os efeitos de TDD e como sua pratica influencia o desenvolvedor durante o processo de projeto de sistemas orientados a objetos. Para entende-las, neste trabalho optamos por um estudo exploratorio essencialmente qualitativo, no qual participantes foram convidados a resolver exercicios pre-preparados utilizando TDD e, a partir dos dados colhidos nessa primeira parte, nos levantamos detalhes sobre como a pratica influenciou as decisoes de projeto de classes dos participantes por meio de entrevistas. Ao final, observamos que a pratica de TDD pode guiar o desenvolvedor durante o processo de criacao do projeto de classes por meio de constantes feedbacks sobre a qualidade do projeto. Esses feedbacks alertam desenvolvedores sobre possiveis problemas, como alto acoplamento ou baixa coesao. Os desenvolvedores, por sua vez, devem interpretar e melhorar o projeto de classes. Este trabalho catalogou e nomeou os padroes de feedback percebidos pelos participantes. / Test-Driven Development (TDD) is one of the suggested practices in Extreme Programming (XP). The mechanical is simple: the developer writes a test before writing the implementation. Thus, TDD is often seen as a software testing technique. However, many famous book authors suggest that TDD can help developers during the class design creation process, enabling developers to create less coupled highly cohesive classes. Most of the academic studies are interested on finding the difference between a TDDd and a non-TDDd code. Only a few of them discuss how the practice really supports class design. Even practitioners do not understand how the practice guides them. This work aims to understand better the effects of TDD and how the practice influences the practitioner during the class design process in object-oriented systems. To better understand them, we did a essencially qualitative explorative study, in which participants were invited to solve a set of pre-prepared exercises using TDD and, based on the gathered data, we retrieved details of how the practice influenced the developers class design decisions through interviews. At the end, we observed that the practice of TDD can guide developers during the class design creation process through constant feedback about its quality. These feedbacks alert developers about possible problems, such as high coupling or low cohesion. Developers then should interpret and improve the class design accordingly. This study also catalogues the TDD feedback patterns perceived by the participants.

[pt] A refatoração de código é uma transformação de código que visa aprimorar a estrutura interna do código. Uma refatoração isolada raramente é suficiente para remover completamente uma estrutura de código ruim, como uma anomalia de código. Os desenvolvedores então aplicam refatorações compostas para remover totalmente uma anomalia de código. Uma refatoração composta consiste em duas ou mais refatorações inter-relacionadas. Um refatoração composta é considerada completa quando elimina totalmente a anomalia de código alvo. Estudos relatam que os desenvolvedores geralmente falham em remover completamente as anomalias de código alvo por meio de refatorações compostas. Refatorações compostas concluídas podem não ser totalmente benéficas para a estrutura do código. Pois, estas podem induzir efeitos colaterais, como a introdução de anomalias de código ou a propagação de anomalias existentes. Há uma compreensão limitada sobre a completude das refatorações compostas e seus possíveis efeitos colaterais. Esta tese investiga como as refatorações compostas removem totalmente as anomalias de código sem induzir efeitos colaterais. Descobrimos que 64 por cento das refatorações compostas completas são formadas por tipos de refatoração não recomendados anteriormente. Dessa forma, derivamos um catálogo de recomendações para apoiar os desenvolvedores na aplicação de refatorações compostas. Na avaliação do catálogo, 85 por cento de 21 desenvolvedores relataram que usariam as recomendações do catálogo e que suas próprias soluções de refatoração teriam induzido efeitos colaterais. Também avaliamos qualitativamente três abordagens existentes para recomendar automaticamente refatorações compostas. Nesse estudo, a maioria (80 por cento) dos 10 desenvolvedores relatou que as abordagens existentes frequentemente induzem efeitos colaterais. No geral, as descobertas e o catálogo proposto podem ajudar os desenvolvedores a realizar refatorações compostas completas. / [en] Code refactoring is a code transformation that aims to enhance the internal code structure. A single refactoring is rarely sufficient to achieve the full removal of a poor code structure, such as a code smell. Developers then apply composite refactorings to fully remove a code smell. A composite refactoring (or, simply, composite) consists of two or more interrelated single refactorings. A composite is considered complete when it fully eliminates the target smell. However, studies report that developers often fail in completely removing target code smells through composites. Even when composite refactorings are complete they may still not be entirely beneficial to the code structure. They may induce side effects, such as the introduction of new smells or the propagation of existing ones. There is a limited understanding of the completeness of composite refactorings and their possible effects on structural quality. This thesis investigates whether and how composite refactorings fully remove smells without inducing side effects. We found that 64 per cent of complete composites in several software projects are formed of refactoring types not previously recommended in the literature. Based on this study, we derived a catalog of recommendations for supporting developers in applying composite refactorings. Out of twenty one developers evaluating our catalog, 85 per cent reported that they would use the catalog recommendations and that their own refactoring solutions would have induced side effects. We also qualitatively evaluated three existing approaches to automatically recommend composite refactorings. In our study with ten developers, most (80 per cent) developers reported that existing approaches frequently induce side effects. Overall, the findings and the proposed catalog can help developers to perform complete composite refactorings with better awareness of possible side effects.

[pt] Mesmo com o processo de refatoração sendo investigado cada vez mais nos últimos anos, muitas de suas características se mantém pouco compreendidas. Refatoração de software é o processo de melhorar a manutenibilidade de um sistema por meio de mudanças estruturais que não alteram seu comportamento. Estudos recentes revelaram que projetos de software frequentemente recebem refatorações compostas. Em tais refatorações, desenvolvedores aplicam uma série de transformações únicas em conjunção e em um único commit, e se espera que estas refatorações tenham um efeito maior e mais positivo do que refatorações singulares. Porém, refatorações frequentemente causam mudanças que ou mantém a qualidade do software da mesma forma, ou causam a piora do mesmo, levando trabalhos recentes a procurar causas em potencial para este comportamento. Porém, o porquê da complexidade destas mudanças compostas frequentemente afetarem seus resultados de alguma forma positiva ou (inesperadamente) negativa continua não investigado. O mesmo ocorre com o potencial efeito das preocupações dos desenvolvedores durante a aplicação de refatorações. Sobre estas preocupações, alguns trabalhos anteriores foram desenvolvidos em torno da caracterização e detecção de discussões de desenvolvedores relacionadas a refatorações. Porém, não se sabe se e como estas preocupações de desenvolvedores com refatorações, tornando-se explícitas em tais discussões, podem influenciar os efeitos de refatorações em um sistema. Portanto, este trabalho apresenta dois estudos com o objetivo de preencher a lacuna no conhecimento de que causas levam aos efeitos não-positivos frequentemente encontrados em refatorações, procurando entender: (i) se refatorações mais complexas realmente são mais efetivas do que refatorações simples, como esperado; (ii) em que situações desenvolvedores tendem a explicitar suas preocupações com refatoração do código; e (iii) qual é o impacto de tais preocupações na efetividade de uma refatoração em melhorar a qualidade estrutural do código. Nós analisamos estas características e atingimos os seguintes resultados: Primeiro, conforme a complexidade das refatorações aumenta, a efetividade das mesmas aumenta conjuntamente. Segundo, há uma relação entre a efetividade de refatorações e preocupações explícitas com refatorações, onde a possibilidade de efeitos negativos é menor quando desenvolvedores estão explicitamente preocupados com refatoração. Finalmente, desenvolvedores tendem a explicitar mais frequentemente suas preocupações com o processo de refatoração quando deparados com tarefas de refatoração mais complexas. / [en] Even though the refactoring process has been increasingly investigated in the last years, many of its characteristics remain poorly understood. Software refactoring is the process of improving the maintainability of a system through structural changes that do not alter its behaviour. Recent studies revealed that software projects frequently have to undergo composite refactorings. In such refactorings, developers perform a series of single transformations in conjunction and in a single commit, which are expected to have a larger and more positive impact than single refactorings. However, refactorings frequently cause changes that either keep the software quality the same, or cause it to worsen, which lead recent works to look for potential causes of this behavior. However, the complexity of these composite changes often affecting their outcomes in some positive or (unexpectedly) negative way remains not investigated, much like the developers concerns while performing refactoring. For the latter, some previous work was performed around characterizing and detecting refactoring-related developer discussions. However, it is unknown whether and how developers refactoring concerns made explicit in such discussions can influence the refactorings effects on a system. Thus, this work reports two studies aimed at bridging some of those gaps in knowledge in which causes lead to the non-positive effects frequently found in refactoring, by understanding: (i) if more complex refactorings are indeed more effective than simple refactorings, as one would expect; (ii) in which situations developers tend to have explicit concerns while refactoring the code; and (iii) what is the impact of such concerns on the effectiveness of a refactoring to improve structural quality. We analyze these characteristics and reach the following results: First, as refactoring complexity increases, the effectiveness of such refactorings increases as well. Second, there is a relationship between refactoring effectiveness and explicit refactoring concerns, in which the possibility of negative effects is lower when developers are explicitly concerned about refactoring. Finally, developers tend to be more explicit about their concerns on the refactoring process when they are faced with more complex refactoring tasks.