Made available in DSpace on 2014-12-17T15:48:02Z (GMT). No. of bitstreams: 1 HugoFM_DISSERT.pdf: 1847783 bytes, checksum: 58d9312a629dabdd3fe4b15c8dc44101 (MD5) Previous issue date: 2012-07-26 / The Exception Handling (EH) is a widely used mechanism for building robust systems. In Software Product Line (SPL) context it is not different. As EH mechanisms are embedded in most of mainstream programming languages (like Java, C# and C++), we can find exception signalers and handlers spread over code assets associated to common and variable SPL features. When exception signalers and handlers are added to an SPL in an unplanned way, one of the possible consequences is the generation of faulty family instances (i.e., instances on which common or variable features signal exceptions that are mistakenly caught inside the system). In this context, some questions arise: How exceptions flow between the optional and alternative features an LPS? Aiming at providing answers to these questions, this master thesis conducted an exploratory study, based on code inspection and static analysis code, whose goal was to categorize the main ways which exceptions flow in LPSs. To support the study, we developed an static analysis tool called PLEA (Product Line Exception Analyzer) that calculates the exceptional flows of LPSs, and categorize these flows according to the features associated with handlers and signalers. Preliminary results showed that some types of exceptional flows have more potential to yield failures in exceptional behavior of SLPs / O mecanismo de tratamento de exce??es ? amplamente utilizado para a constru??o de sistemas robustos. No contexto de Linhas de Produto de Software (LPSs) n?o ? diferente. Uma vez que mecanismos de tratamento de exce??es est?o embutidos nas principais linguagens de programa??o da atualidade (como Java, C# e C++), podemos encontrar sinalizadores e tratadores de exce??es espalhados entre os artefatos de c?digo associados a caracter?sticas (do ingl?s: features) opcionais e obrigat?rias de uma LPS. Quando tratadores ou sinalizadores de exce??es s?o adicionados a uma LPS de forma n?o planejada, uma das poss?veis conseq??ncias ? a gera??o de produtos falhos (i.e., produtos em que exce??es lan?adas por features vari?veis ou obrigat?rias s?o erroneamente tratadas). Neste contexto, surge a pergunta: Quais as consequ?ncias de se usar o mecanismo de tratamento de exce??es em LPSs? Com o objetivo de responder a esta pergunta, este trabalho conduz um estudo explorat?rio, baseado em inspe??o de c?digo e an?lise est?tica de c?digo, cujo objetivo foi caracterizar as principais formas em que exce??es fluem em LPSs. Para apoiar a realiza??o deste estudo desenvolvemos a PLEA (Product Line Exception Analyzer), uma ferramenta baseada em analise est?tica de c?digo que calcula os fluxos excepcionais de uma LPS e os classifica de acordo com as features associadas aos seus tratadores e sinalizadores. Resultados preliminares mostraram que alguns tipos de fluxos excepcionais tem mais potencial para originarem falhas no comportamento excepcional das LPSs

Submitted by Automa??o e Estat?stica (sst@bczm.ufrn.br) on 2018-02-15T13:38:34Z No. of bitstreams: 1 JoaoVictorDeOliveiraNeto_DISSERT.pdf: 2906470 bytes, checksum: 5e5f0824ff4be1201d9af45aac2ed119 (MD5) / Approved for entry into archive by Arlan Eloi Leite Silva (eloihistoriador@yahoo.com.br) on 2018-02-20T21:02:12Z (GMT) No. of bitstreams: 1 JoaoVictorDeOliveiraNeto_DISSERT.pdf: 2906470 bytes, checksum: 5e5f0824ff4be1201d9af45aac2ed119 (MD5) / Made available in DSpace on 2018-02-20T21:02:12Z (GMT). No. of bitstreams: 1 JoaoVictorDeOliveiraNeto_DISSERT.pdf: 2906470 bytes, checksum: 5e5f0824ff4be1201d9af45aac2ed119 (MD5) Previous issue date: 2017-08-31 / A necessidade de evolu??o nos softwares tornou-se cada vez mais frequente e a engenharia de software precisou se adaptar para entregar produtos de qualidade em prazos cada vez menores. Para que o software continue sendo ?til ao longo do tempo, para o prop?sito ao qual foi desenvolvido, ? necess?rio que sejam realizadas mudan?as ou inclu?das novas funcionalidades para que este acompanhe as mudan?as no contexto do neg?cio. Com essas mudan?as, ? inevit?vel que o software passe a aumentar de tamanho e, consequentemente, em complexidade. Essa expans?o do software cria relacionamentos de depend?ncia entre componentes do c?digo-fonte e essas depend?ncias se propagam em uma cadeia de depend?ncias ? medida que a aplica??o cresce. Reescrever o mesmo trecho de c?digo ? uma pr?tica n?o recomendada no desenvolvimento de software, pois implica em replicar c?digo de forma distribu?da e desordenada. Ao fazer o reuso, o mesmo trecho j? escrito ? referenciado em diferentes funcionalidades do sistema atrav?s da cadeia de depend?ncia e chamadas de m?todos, fazendo com que diferentes partes do c?digo que estejam associadas a diferentes funcionalidades passem a depender de um mesmo componente. Altera??es de trechos de c?digo que possuem rela??o direta ou indireta com diferentes casos de uso podem levar a falhas imprevistas da aplica??o, pois dependendo do n?mero de artefatos envolvidos e da extens?o da cadeia de depend?ncias relacionada ao c?digo alterado, uma mudan?a pode impactar um outro caso de uso que aparentemente n?o tem rela??o com o trecho de c?digo modificado. Prever impactos decorrentes de altera??es em um artefato ? uma tarefa que exige tempo para an?lise, profundo conhecimento do c?digo-fonte e esfor?o de teste. Este trabalho apresenta uma abordagem para automatizar a identifica??o de poss?veis conflitos indiretos atrav?s de uma ferramenta, capaz de determinar quais casos de uso possuem maior probabilidade de serem impactados por mudan?as no c?digo-fonte, podendo assim direcionar os esfor?os de testes de forma mais eficaz. Foi elaborado um estudo para avaliar um projeto real de dimens?o extensa que n?o possui uma su?te de testes automatizados e a ferramenta desenvolvida mostrou-se eficiente para detectar conflitos indiretos em diferentes cen?rios e tamb?m provou, atrav?s de um experimento emp?rico, que a maior parte das falhas decorrentes de conflitos indiretos teriam sido evitadas caso a ferramenta tivesse sido utilizada ainda na fase de desenvolvimento. / The necessity of software evolution for those which solve daily problems became even more frequent and the software engineering had to be adapted in order to be able to delivery products with good quality in tight dead lines. In order to the software continues being useful during its life cycle, to the main purpose whose was developed, its necessary to apply changes or include new features due to changes which happens in the business. Rewrite the same block of code is not a recommended approach on software development, because it spreads code in a distributed and disordered way. Applying the code reuse, the same block of code already wrote is referenced by different use cases through the dependency chain and method calls, where different parts of the code, which are being relate to differents funcionalitys, going to depend to the same component. Changes applyed to a block of code which has direct or indirect relation with differents use cases may lead to umpredictable fails, depending on the number of different artifacts related and the extension of dependency chain related to the artifact which was modified, this change may cause a impact on another use case which, by a first look, does not have any relation which the modified block of code. Predict impacts from in a specific artifact is a task which demands time to analysis, deep knowledge of the source-code and test effort. This paper presents an approach to automatize the identification of possible indirect conflicts using the developed tool, whose can determinate which use cases are more defect prone by source-code changes, providing a more effective direction to the test?s efforts. A Study Case was elaborated, assessing a real project of extensive dimension whose doesn?t have a automatized test case suite, and the developed tool was able to identify the indirect conflicts on differents cenarios and besides, the tool was able to proof in a empiric experiment which the major failures, caused by indirect conflicts could be avoided if the tool were be used during the development fase.

Submitted by Automa??o e Estat?stica (sst@bczm.ufrn.br) on 2017-10-18T19:35:37Z No. of bitstreams: 1 DemostenesSantosDeSena_TESE.pdf: 4593790 bytes, checksum: 3e0845d816f16e3a8f7659744e28f8ad (MD5) / Approved for entry into archive by Arlan Eloi Leite Silva (eloihistoriador@yahoo.com.br) on 2017-10-19T19:11:29Z (GMT) No. of bitstreams: 1 DemostenesSantosDeSena_TESE.pdf: 4593790 bytes, checksum: 3e0845d816f16e3a8f7659744e28f8ad (MD5) / Made available in DSpace on 2017-10-19T19:11:30Z (GMT). No. of bitstreams: 1 DemostenesSantosDeSena_TESE.pdf: 4593790 bytes, checksum: 3e0845d816f16e3a8f7659744e28f8ad (MD5) Previous issue date: 2017-02-13 / Os mecanismos de tratamento de exce??es s?o recursos fornecidos pelas principais linguagens de programa??o para auxiliar no desenvolvimento de sistemas robustos. A pol?tica de tratamento de exce??es corresponde ao conjunto de regras de design do tratamento excepcional e definem os elementos de c?digo (m?todos, classes ou pacotes) respons?veis pela sinaliza??o, propaga??o, captura das exce??es e as respectivas a??es de tratamento. Alguns estudos emp?ricos demonstraram que o tratamento inadequado de exce??es, consequ?ncia da falta da pol?tica documentada, ? uma poss?vel fonte de defeitos. Por outro lado, devido ? natureza impl?cita dos fluxos de exce??es, a identifica??o e corre??o dos tratamentos de exce??es tornam-se tarefas complexas. Para amenizar os problemas decorrentes do tratamento inadequado devido ? falta de documenta??o do tratamento de exce??es, algumas abordagens definiram linguagens de especifica??o das regras de tratamento com suporte ferramental para auxiliar na defini??o e checagem das regras. Entretanto, historicamente, as pol?ticas de tratamento de exce??es dos sistemas s?o postergadas ou ignoradas no processo de desenvolvimento. Adicionalmente, nenhuma das abordagens propostas oferece suporte ? defini??o das regras, de forma a auxiliar o arquiteto a extrair as regras a partir da an?lise de c?digo fonte pr?-existente, e este ? o objetivo da abordagem apresentada neste trabalho. Para apoiar a execu??o da abordagem proposta, foi desenvolvida uma ferramenta de an?lise est?tica que permite: (i) a coleta dos fluxos excepcionas e das respectivas a??es de tratamentos; (ii) a identifica??o e defini??o dos agrupamentos, que s?o os elementos de c?digo que possuem os mesmos comportamentos em rela??o ao tratamento de exce??es; (iii) a extra??o das regras; e, (iv) a checagem das regras e identifica??o das causas das viola??es ? pol?tica. A abordagem ? demonstrada em dois estudos emp?ricos. No primeiro estudo emp?rico foram analisadas 656 bibliotecas (libs) Java do reposit?rio central Maven com objetivo de extrair e caracterizar a pol?tica de tratamento de exce??es destas libs. Este estudo revelou que 80,9% das bibliotecas possuem fluxos excepcionais que implementam pelo menos um anti-pattern do tratamento excepcional. O segundo estudo emp?rico teve como objetivo investigar os benef?cios da extra??o das regras excepcionais a partir do c?digo pr?-existente no processo de defini??o e checagem da pol?tica de tratamento de exce??es. Dois sistemas de informa??o Web (i.e., IProject e SIGAA) foram utilizados neste segundo estudo. Neste estudo pudemos observar que todas as regras reportadas pelos arquitetos foram extra?das pelo suporte ferramental, e que os resultados do processo de extra??o permitiram que novas regras fossem adicionadas pelos arquitetos. Essas regras adicionadas foram as regras n?o definidas pelos arquitetos e corresponderam ? 57,1% (IProject) e 52,8% (SIGAA/Gradua??o) das regras da pol?tica dos sistemas analisados. O processo de checagem das regras definidas com o apoio da abordagem mostrou que 35,6% e 45,7% dos fluxos excepcionais do IProject e SIGAA/Gradua??o, respectivamente, violavam alguma das regras de tratamento de exce??es. / The Exception handling (EH) mechanism is a technique embedded in most of the mainstream programming languages to support the development of robust systems. The exception handling policy is composed by the set of exception handling design rules and which specify the elements (methods, classes and packages) or that contains the elements responsible for raising, propagating and catching of exceptions as well as the handling actions. Empirical studies have demonstrated that an inappropriate exception handling as consequence of undocumented exception handling policy is a source of bug hazards. On the other hand, due to the implicit nature of exception flows, the identification of exception handling code is a complex task. To address the problems resulting from the not-understood or inadequate exception handling, some approaches have been proposed languages to specify exception handling rules as well as a set of support tool to verify the constraints and checking the rules. However, historically, the exception handling policies are postponed or ignored in the software process development. Additionally, none of the proposed approaches provide support to the phase of exception policy definition. This work proposes an approach that helps the architect to extract the EH rules by performing an analysis on the existing code. Doing so, this approach fills the previous gap the EH policy definition. To support the proposed approach, a static tool suite was developed, which performs: (i) the discovery of exception flows and its handling actions; (ii) the definition of compartments; (iii) the semi-automatic rule extraction process; and (iv) the rule checking and identification of rule violation causes. This approach was assessed in two empirical studies. In the first study, 656 libraries from Maven central repository were analyzed. The main goal of this study was to reveal and to characterize the exception handling policy of the analyzed libraries. This study revealed that 80.9% of the analyzed libraries have exception flows that implement at least one exception handling anti-pattern. In the second study, we investigated the benefits of rule extraction process in the definition and checking of exception handling rules. Two web information systems (i.e., IProject and SIGAA) were analyzed in this second study. We found that all set of rules reported by the architects were extracted by our tool and the result of extraction process allowed that new rules were added to the policy. These added rules were not defined by architects and they corresponded to 57.1% (IProject) and 52.8% (SIGAA/Gradua??o) of the rules of analyzed systems. The checking process of defined rules supported by our approach verified that 35.6% (IProject) and 45.7% (SIGAA/Gradua??o) of exception flows violated some defined rule.