Orientador: Cecília Mary Fischer Rubira / Dissertação (mestrado) - Universidade Estadual de Campinas, Instituto de Computação / Made available in DSpace on 2018-08-17T14:44:52Z (GMT). No. of bitstreams: 1 Leite_DouglasSiqueira_M.pdf: 1797650 bytes, checksum: ce96fe468509c785b633e1cde43729dd (MD5) Previous issue date: 2010 / Resumo: Arquitetura Orientada a Serviços (Service-Oriented Architecture - SOA) _e um modelo arquitetural que visa melhorar a eficiência, agilidade e a produtividade de aplicações empresariais através do uso de serviços e composições de serviços, as quais podem ser executadas tanto de forma síncrona quanto assíncrona. Diferentes tecnologias de software podem ser usadas para implementar SOA, tais como Web services e Arquitetura de Componentes de Serviços (Service Component Architecture - SCA). A primeira _e baseada em padrões XML, ao passo que a segunda provê um modelo de componentes para implementação de serviços e composições de serviços. Em particular, quando composições de serviços assíncronos são executadas, um ou mais erros podem ocorrer concorrentemente nos diferentes serviços, possivelmente ao mesmo tempo, afetando a dependabilidade da composição. Dessa forma, mecanismos de tolerância a falhas são necessários a _m de prevenir que um defeito se manifeste na composição. Neste trabalho, apresentamos o projeto e implementação de um mecanismo de tratamento de exceções coordenadas para arquiteturas orientadas a serviços que permite a criação de composições de serviços assíncronos tolerante a falhas de uma forma flexível. Mais especifiçamente, nossa solução _e baseada em um mecanismo de tratamento de exceções global, definido pelo modelo Guardian, já que este oferece uma solução mais geral e flexível quando comparado com outras abordagens, tais como soluções baseadas em ações atômicas coordenadas. Nosso framework, denominado Guardian-SCA, foi implementado como parte do projeto Apache Tuscany SCA, usando o modelo de extensão do Tuscany e programação orientada a aspectos, aumentando assim a flexibilidade do framework / Abstract: Service-Oriented Architecture (SOA) is an architectural model that aims to enhance the efficiency, agility, and productivity of an enterprise by structuring services in terms of services compositions, which can be executed either synchronously or asynchronously. Different software technologies can be used to implement SOA, such as Web services and Service Component Architecture (SCA). The former is based on XML-based standards, while the latter provides a component model for implementing services and service compositions. In particular, when asynchronous services compositions are executed, one or more errors can occur concurrently, possibly at same time, affecting the composition's dependability. In this way, fault tolerance mechanisms are necessary in order to prevent the services compositions from reaching a failure state. In this work, we present the design and implementation of a coordinated exception handling mechanism, applicable to service-oriented architectures, which allows the creation of fault-tolerant asynchronous service compositions. More specifically, our solution is based on a global exception handling mechanism defined by the Guardian model, since it is more general and flexible when compared to other approaches, like CA Actions-based solutions. Our framework, named Guardian-SCA, was implemented as a part of the Apache Tuscany SCA project, using the Tuscany extension model and aspect-oriented programming with the aim to increase the framework's exibility / Mestrado / Sistemas de Informação / Mestre em Ciência da Computação

Orientador: Cecilia Mary Fischer Rubira / Dissertação (mestrado) - Universidade Estadual de Campinas, Instituto de Computação / Made available in DSpace on 2018-08-05T04:18:48Z (GMT). No. of bitstreams: 1 Brito_PatrickHenriquedaSilva_M.pdf: 1701733 bytes, checksum: c2009f5302dc57e1c6d8e2d4a0c95c85 (MD5) Previous issue date: 2005 / Resumo: Devido a grande popularização do Desenvolvimento Baseado em Componentes (DBC), ele vem sendo empregado inclusive no desenvolvimento de sistemas computacionais críticos. O emprego do DBC na construção de sistemas confiáveis evidencia a necessidade de se desenvolver componentes de software que sejam robustos e que possuam uma garantia maior do seu funcionamento correto. Tratamento de exceções é uma técnica bastante conhecida para a verificação e tratamento de erros em sistemas de software. Por'em, apesar da sua popularidade, o seu projeto e a implementação são constituídos de tarefas muito complexas que não recebem uma atenção adequada dos processos de desenvolvimento existentes. A situação É ainda mais crítica se levarmos em considera¸c¿ao os métodos para DBC. Este trabalho propõe um método para auxiliar a modelagem do comportamento excepcional de sistemas baseados em componentes, chamado MDCE+. Baseado no refinamento da metodologia MDCE, o MDCE+ apresenta dois diferenciais importantes, que reforçam o seu aspecto robusto: (i) o fato dele combinar as abordagens top-down e botton-up para o desenvolvimento de sistemas confiáveis; e (ii) o fato dele ser centrado na arquitetura. O foco na arquitetura de software contribui para uma melhor definição e análise do fluxo de exceções entre os componentes do sistema. Essa maneira estruturada de detectar e tratar exceções no contexto da ocorrência de falhas é particularmente relevante para sistemas que apresentam requisitos de confiabilidade extrema. O método MDCE+ é um método genérico que pode ser aplicada a processos de desenvolvimento modernos. Em particular, nesta dissertação o método MDCE+ foi adaptado ao processo UML Components e a uma metodologia de testes. Como maneira de avaliar esse método, foi desenvolvido um estudo de caso de um sistema financeiro real, com requisitos de tolerância a falhas. Dada a sua importância, o processo de avaliação do método MDCE+ foi dividido em tr¿es etapas: (i) preparação; (ii) execução; e (iii) análise dos resultados. Nesse estudo foi necessário tratar exceções na arquitetura do sistema, com o intuito de aumentar a disponibilidade dos serviços / Abstract: Due to the large adoption of the Component-Based Development (CBD), it has also been employed in the development of critical software systems. The development of dependable systems using the CBD paradigm evidences the necessity of developing software components that are robust and dependable. Exception handling is a well known technique for verify and treat errors in software systems. However, despite its popularity, its design and implementation are constituted of very complex tasks that do not receive the adequate attention from the existing development processes. This is still more critical in the context of CBD processes. This work presents the MDCE+, a method that assists the modeling of the exceptional behavior in component-based software development. Based in the refinement of the MDCE methodology, the MDCE+ presents two important differentials, that strengthen its robustness: (i) it combines the top-down and bottom-up strategies for the development of dependable systems; and (ii) it is centered in the software architecture. As a consequence of the focus given to the software architecture, the exceptions that flow between the system components are better defined and analyzed. This structured way to detect and to treat exceptions in the context of the occurrence of imperfections is particularly needed for developing dependable systems. The MDCE+ is a generic method that can be applied together with modern development processes. In particular, in this master thesis MDCE+ was adapted to the UML Components process and to a software test methodology. In order to evaluate this method, a case study of a real financial system with fault-tolerance requirements was developed. Given its importance, the evaluation process of the MDCE+ method was decomposed in three stages: (i) preparation; (ii) execution; and (iii) results analysis. In order to increase the services availability, in this study it was necessary to deal with exceptions in the software architecture / Mestrado / Engenharia de Software / Mestre em Ciência da Computação

Orientador: Eliane Martins / Dissertação (mestrado) - Universidade Estadual de Campinas, Instituto de Computação / Made available in DSpace on 2018-08-18T15:53:22Z (GMT). No. of bitstreams: 1 Ferreira_Jeferson_M.pdf: 10344068 bytes, checksum: f13e5d139255d50754dc668d1bbf3fc6 (MD5) Previous issue date: 2011 / Resumo: Para a construção de sistemas robustos, devem ser utilizadas técnicas de tolerância a falhas que podem ser implementadas através de mecanismos de tratamento de exceções. Esses mecanismos possibilitam o tratamento de possíveis exceções, ou até mesmo a continuação da execução das funcionalidades do sistema mesmo na presença de uma exceção. O uso dos mecanismos de tratamento de exceções para desenvolver sistemas de software em larga escala, juntamente com o fato de ser implementado por diversas linguagens modernas, confirma a importância desta prática de desenvolvimento. Por outro lado, o uso desses mecanismos tem suas desvantagens, impactando principalmente na complexidade dos sistemas. Um problema que ocorre com muita frequência é efetuar a validação do fluxo excepcional somente na fase de implementação. A detecção de um problema de especificação nesta etapa do processo, pode acarretar em um aumento nos custos e prazos para a entrega do software. Este trabalho apresenta uma abordagem que utiliza as técnicas de análise estática, normalmente empregadas para detectar falhas no código fonte, para antecipar a validação do fluxo excepcional de um componente de software durante o ciclo de desenvolvimento. A solução proposta utiliza as informações do fluxo de controle e fluxo de dados obtidas a partir de um modelo comportamental. O modelo utilizado nesta abordagem é o diagrama de atividades da UML, que passa por uma série de transformações até gerar um grafo de fluxo de controle interprocedimental. Durante este processo são executadas análises de fluxo de dados para inferir com precisão quais são os tipos de exceções podem ser lançadas em dado ponto do modelo. Também faz parte deste trabalho a apresentação de uma ferramenta de apoio para o processo de validação do fluxo excepcional. Esta ferramenta, denominada ADEX (Activity Diagram EXceptional flow analyzer), implementa os algoritmos utilizados para a conversão do diagrama de atividades no grafo de fluxo de controle interprocedimental. A ferramenta também oferece recursos para a visualização do fluxo de controle normal e excepcional do modelo / Abstract: In order to develop robust software, should be used fault tolerant techniques that can be implemented by exception handling mechanisms. These mechanisms allow the handling of possible exceptions or even the continued of execution of the system's functionalities, even in the presence of an exception. The use of exception handling mechanisms to develop large scale software systems together with the fact that several modern programming languages provide these mechanisms, confirm the importance of these mechanisms in practice. On the other hand, the use of these mechanisms has some disadvantages, principally impacting on the complexity of the systems. One problem that occurs very often is performing the validation of the exceptional flow only during the implementation phase. The detection of a specification problem at this stage of the process can lead the increasing of costs and delays to delivery the software. This paper presents an approach that uses static analysis techniques, usually used to detect anomalies in the source code, to antecipate the validation of the exceptional flow of a software component in the development cycle. The proposed solution uses the information of control flow and data flow gathered from a behavioral model. The model used in this approach is the UML activity diagram, which undergoes a series of transformations to generate a interprocedural control flow graph. During this process are performed data flow analysis to inferring precisely what kind of exceptions can be thrown at a specific point of the model. The presentation of a tool to support the validation of the exceptional flow, also is part of this work. This tool, called ADEX (Activity Diagram EXceptional flow analyzer), implements the algorithms used to convert the activity diagram in the interprocedural control flow graph. The tool also provides features for visualization of normal and exceptional control flow of the model / Mestrado / Ciência da Computação / Mestre em Ciência da Computação

Atualmente, diversas empresas e organizações estão cada vez mais empreendendo esforços para transformar rapidamente as suas potenciais ideias em produtos e serviços. Esses esforços também têm estimulado a evolução dos sistemas de informação que passaram a ser apoiados por modelos de alto nível de abstração para descrever a lógica do processo. Neste contexto, destaca-se o sucesso dos Sistemas de Informação cientes de Processos (PAIS, do inglês Process-Aware Information Systems) para o gerenciamento de processos de negócios e automação de processos científicos de larga escala (e-Science). Grande parte do sucesso dos PAIS é devido à capacidade de prover funcionalidades genéricas para modelagem, execução e monitoramento dos processos. Essas características são bem-sucedidas quando os modelos de processos têm um caminho bem-comportado no sentido de atingir os seus objetivos. No entanto, situações anômalas que desviam a execução desse caminho bem-comportado ainda representam um significativo desafio para os PAIS. Por causa dos vários tipos de falhas que desviam a execução do comportamento esperado, prover uma execução robusta e confiável é uma tarefa complexa para os atuais PAIS, uma vez que nem todas as situações de falha podem ser eficientemente descritas dentro da estrutura do fluxo tradicional. Como consequência, o tratamento de tais situações geralmente envolve intervenções manuais nos sistemas por operadores humanos, o que resulta em custos adicionais e significativos para as empresas. Neste trabalho é introduzido um método de composição para recuperação ciente de custos e benefícios que é capaz de encontrar e seguir caminhos alternativos que reduzam os prejuízos financeiros do tratamento de exceções. Do ponto de vista prático, esse método provê o tratamento de exceção automatizado e otimizado ao calcular os custos e benefícios de cada caminho de recuperação e escolher o caminho com a melhor relação custo-benefício disponível. Mais especificamente, o método de recuperação proposto estende a abordagem WED-flow (Workflow, Event processing and Data-flow) para permitir a composição ciente de custos e benefícios de passos de recuperação transacionais backward e forward. Por fim, os experimentos mostram que esse método de recuperação pode ser adequadamente incorporado para manipular exceções em uma ampla variedade de processos. / Nowadays, many corporations and organizations are increasingly making efforts to transform quickly and effectively their potential ideas into products and services. These efforts have also stimulated the evolution of information systems that are now supported by higher-level abstract models to describe the process logic. In this context, several sophisticated Process-Aware Information Systems (PAIS) have successfully been proposed for managing business processes and automating large-scale scientific (e-Science) processes. Much of this success is due to their ability to provide generic functionality for modeling, execution and monitoring processes. These functionalities work well when process models have a well-behaved path towards achieving their objectives. However, anomalous situations that fall outside of the well-behaved execution path still pose a significant challenge to PAIS. Because of the many types of failures that may deviate execution away from expected behaviors, provision of robust and reliable execution is a complex task for current PAIS, since not all failure situations can be efficiently modeled within the traditional flow structure. As a consequence, the treatment for such situations usually involves interventions in systems by human operators, which result in significant additional cost for businesses. In this work, we introduce a cost/benefit-aware recovery composition method that is able to find and follow alternative paths to reduce the financial side effects of exception handling. From a practical point of view, this method provides the automated and optimized exception handling, by calculating the cost and benefits of each recovery path, and choosing the recovery path with the best cost/benefits available. More specifically, our recovery method extends the WED-flow (Workflow, Event processing and Data-flow) approach for enabling cost/benefit-aware composition of forward and/or backward transactional recovery steps. Finally, the experiments point out that this recovery method can be suitably incorporated into exception handling within a wide variety of processes.

Objectives: In many medical domains investigator-initiated clinical trials are used to introduce new treatments and hence act as implementations of guideline-based therapies. Trial protocols contain detailed instructions to conduct the therapy and additionally specify reactions to exceptional situations (for instance an infection or a toxicity). To increase quality in health care and raise the number of patients treated according to trial protocols, a consultation system is needed that supports the handling of the complex trial therapy processes efficiently. Our objective was to design and evaluate a consultation system that should 1) observe the status of the therapies currently being applied, 2) offer automatic recognition of exceptional situations and appropriate decision support and 3) provide an automatic adaptation of affected therapy processes to handle exceptional situations. Methods: We applied a hybrid approach that combines process support for the timely and efficient execution of the therapy processes as offered by workflow management systems with a knowledge and rule base and a mechanism for dynamic workflow adaptation to change running therapy processes if induced by changed patient condition. Results and Conclusions: This approach has been implemented in the AdaptFlow prototype. We performed several evaluation studies on the practicability of the approach and the usefulness of the system. These studies show that the AdaptFlow prototype offers adequate support for the execution of real-world investigator-initiated trial protocols and is able to handle a large number of exceptions.

Formal characterization of the memory used by a program is an important basis for security analyses, compositional verification, and identification of noninterference. However, soundly proving memory usage requires operating on the assembly level due to the semantic gap between high-level languages and the code that processors actually execute. Automated methods, such as model checking, would not be able to handle many interesting functions due to the undecidability of memory usage. Fully-interactive methods do not scale well either. Sound control flow recovery (CFR) is also important for binary decompilation, verification, patching, and security analysis. It lifts raw unstructured data into a form that allows reasoning over behavior and semantics. However, doing so requires interpreting the behavior of the program when indirect or dynamic control flow exists, creating a recursive dependency. This dissertation tackles the first property with two contributions that perform proof generation combined with interactive theorem proving in a semi-automated manner: an untrusted tool extracts as much information as it can from the functions under test and then generates all the necessary proofs to be completed in a theorem prover. The first, Floyd-style approach still requires significant manual effort but provides good flexibility and ensures no paths are analyzed more than once. In contrast, the second, Hoare-style approach sacrifices some flexibility and avoidance of repeated path evaluation in order to achieve much greater automation. However, neither approach can handle the dynamic control flow caused by indirect branching. The second property is handled by the second set of contributions of this dissertation. These two contributions provide fully-automated methods of recovering control flow from binaries even in the presence of indirect branching. When such dynamic control flow cannot be overapproximatively resolved, it is clearly noted in the resultant output. In the first approach to control flow recovery, a structured memory representation allows for general analysis of control flow in the presence of indirection, gaining scalability by utilizing context-free function analysis. It supports various aliasing conditions via the usage of nondeterminism, with multiple output states potentially being produced from a given input state. The second approach adds function context and abstract interpretation-inspired modeling of the C++ exception handling (EH) application binary interface (ABI), allowing for the discovery of previously-unknown paths while maintaining or increasing automation. / Doctor of Philosophy / Modern computer programs are so complicated that individual humans cannot manually check all but the smallest programs to make sure they are correct and secure. This is even worse if you want to reduce the trusted computing base (TCB), the stuff that you have to assume is working right in order to say a program will execute correctly. The TCB includes your computer itself, but also whatever tools were used to take the programs written by programmers and transform them into a form suitable for running on a computer. Such tools are often called compilers. One method of reducing the TCB is to examine the lowest-level representation of that program, the assembly or even machine code that is actually run by your computer. This poses unique challenges, because operating on such a low level means you do not have a lot of the structure that a more abstract, higher-level representation provides. Also, sometimes you want to formally state things about a program's behavior; that is, say things about what it does with a high degree of confidence based on mathematical principles. You may also want to verify that one or more of those statements are true. If you want to be detailed about that behavior, you may need to know all of the chunks, or regions, in random-access memory (RAM) that are used by that program. RAM, henceforth referred to as just ``memory'', is your computer's first place of storage for the information used by running programs. This is distinct from long-term storage devices like hard disk drives (HDDs) or solid-state drives (SSDs), which programs do not normally have direct access to. Unfortunately, there is no one single approach that can automatically determine with absolute certainty for all cases the exact regions of memory that are read or written. This is called undecidability, and means that you need to approximate those memory regions a lot of the time if you want to have a significant degree of automation. An underapproximation, an approach that only gives you some of the regions, is not useful for formal statements as it might miss out on some behavior; it is unsound. This means that you need an overapproximation, an approach that is guaranteed to give you at least the regions read or written. Therefore, the first contribution of this dissertation is a preliminary approach to such an overapproximation. This approach is based on the work of Robert L. Floyd, focusing on the direct control flow (where the steps of a program go) in an individual function (structured program component). It still requires a lot of user effort, including having to manually specify the regions in memory that were possibly used and do a lot of work to prove that those regions are (overapproximatively) correct, so our tests were limited in scope. The second contribution automated a lot of the manual work done for the first approach. It is based on the work of Charles Antony Richard Hoare, who developed a verification approach focusing on the syntax (the textual form) of programs. This contribution produces what we call formal memory usage certificates (FMUCs), which are formal statements that the regions of memory they describe are the only ones possibly affected by the functions under test. These statements also come with proofs, which for our work are like scripts used to verify that the things the FMUCs assert about the corresponding functions can be shown to be true given the assumptions our FMUCs have. Sometimes those proofs are incomplete, though, such as when there is a loop (repeated bit of code) in a function under test or one function calls (executes) another. In those cases, a user has to finish the proof, in the first case by weakening (removing information from) the FMUC's statements about the loop and in the second by composing, or combining, the FMUCs of the two functions. Additionally, this second approach cannot handle dynamic control flow. Such control flow occurs when the low-level instructions a program uses to move to another place in that program do not have a pre-stored location to go to. Instead, that location is supplied as the program is running. This is opposed to direct control flow, where the place to go to is hard-coded into the program when it is compiled. The tool also cannot not deal with aliasing, which is when different state parts (value-holding components) of a program contain the same value and that value is used as the numeric address or identifier of a location in memory. Specifically, it cannot deal with potential aliasing, when there is not enough information available to determine if the state parts alias or not. Because of that, we had to add extra assumptions to the FMUCs that limited them to those cases where ambiguous memory-referencing state parts referred to separate memory locations. Finally, it specifically requires assembly as input; you cannot directly supply a binary to it. This is also true of the first contribution. Because of this, we were able to test on more functions than before, but not a lot more. Not being able to deal with dynamic control flow is a big problem, as almost all programs use it. For example, when a function reaches its end, it has to figure out where to return to based on the current state of the program (in the previous contribution, this was done manually). This means that control flow recovery (CFR) is very important for many applications, including decompilation (converting a program back into a higher-level form), patching (updating a program in place without modifying the original code and recompiling it), and low-level analysis or verification in general. However, as you may have noticed from earlier in this paragraph, in order to deal with such dynamic control flow you need to figure out what the possible destinations are for the individual control flow transfers. That can require knowing where you came from in the program, which means that analysis of dynamic control flow requires context (in this context, information previously obtained in the program). Even worse, it is another undecidable problem that requires overapproximation. To soundly recover control flow, we developed Hoare graphs (HGs), the third contribution of this dissertation. HGs use memory models that take the form of forests, or collections of tree data structures. A single tree represents a region in memory that may have multiple symbolic references, or abstract representations of a value. The children of the tree represent regions used in the program that are enclosed within their parent tree elements. Now, instead of assuming that all ambiguous memory regions are separate, we can use them under various aliasing conditions. We have also implemented support for some forms of dynamic control flow. Those that are not supported are clearly marked in the resultant HG. No user interaction is required even when loops are present thanks to a methodology that automatically reduces the amount of information present at a re-executed instruction until the information stabilizes. Function composition is also automatic now thanks to a method that treats each function as its own context in a safe and automated way, reducing memory consumption of our tool and allowing larger programs to be examined. In the process we did lose the ability to deal with recursion (functions that call themselves or call other functions that call back to the original), though. Lastly, we provided the ability to directly load binaries into the tool, no external disassembly (converting machine code into human-readable instructions) needed. This all allowed much greater testing than before, with applications to multiple programs and program libraries. The fourth and final contribution of this dissertation iterates on the HG work by narrowing focus to the concept of exceptional control flow. Specifically, it models the kind of exception handling used by C++ programs. This is important as, if you want to explore a program's behavior, you need to know all the places it goes to. If you use a tool that does not model exception handling, you may end up missing paths of execution caused by unwinding. This is when an exception is thrown and propagates up through the program's current stack of function calls, potentially reaching programmer-supplied handling for that exception. Despite this, commonplace tools for static, low-level program analysis do not model such unwinding. The control flow graph (CFG) produced by our exception-aware tool are called exceptional interprocedural control flow graphs (EICFGs). These provide information about the exceptions being thrown and what paths they take in the program when they are thrown. Additional improvements are a better methodology for handling dynamic control flow as well adding back in support for recursion. All told, this allowed us to explore even more programs than ever before.

This dissertation investigates current trends concerning exceptions. Exceptions influence the reliability of software systems. In order to develop software systems that are most robust, thus delivering higher availability at a lower development and operating cost, the occurence of exceptions needs to be reduced and the effects of the exceptions controlled. In order to do this, issues such as detection, identification, classification, propagation, handling, language implementation, software testing and reporting of exceptions must be attended to. Although some of these areas are well researched there are remaining problems. The quest is to establish if a unified exception-handling framework is possible and viable, which can address the issues and problems throughout the software development life cycle, and if so, the requirements for such a framework. / Computing / M.Sc. (Information Systems)

[pt] Tratamento de erros em aplicações móveis sensíveis ao contexto não é uma tarefa trivial devido às características peculiares destes sistemas, como mobilidade, comunicação assíncrona e aumento de imprevisibilidade. Mecanismos convencionais de tratamento de exceções não podem ser utilizados por vários motivos. Primeiro, a propagação de erros deve considerar as mudanças contextuais que ocorrem constantemente nestes sistemas. Segundo, as atividades de recuperação de erros e a estratégia de tratamento de exceções também precisam freqüentemente ser selecionadas de acordo com as informações de contexto. Terceiro, a própria caracterização de uma exceção pode depender do contexto dos dispositivos envolvidos. Embora vários middlewares orientados a contexto ofereçam suporte ao desenvolvimento de aplicações móveis, estes sistemas raramente fornecem suporte adequado ao tratamento de exceções. Este trabalho realiza uma análise das soluções existentes para tratamento de exceções, considerando os requisitos de sensibilidade ao contexto. Além disso, são propostos um modelo para tratamento de exceções sensível ao contexto e um mecanismo implementado a partir de MoCA (Mobile Collaboration Architecture). MoCA é um middleware publish-subscribe que oferece suporte ao desenvolvimento de aplicações móveis colaborativas através da incorporação de serviços de contexto. Finalmente, este trabalho avalia o mecanismo de exceções proposto através de sua utilização em alguns protótipos de aplicações colaborativas desenvolvidas a partir de MoCA. Através do mecanismo, foram implementadas diferentes estratégias de tratamento de exceções que consideram as informações de contexto das aplicações. / [en] Context-sensitive exception handling on mobile systems is not a trivial task due to their intrinsic characteristics: mobility, asynchrony and increased unpredictability. Conventional mechanisms of exception handling can not be used for many reasons. First, error propagation needs considering the contextual changes that often occur in these systems. Second, error recovery and exception handling strategies also frequently need to be selected according to contextual information. Third, the characterization of an exception may depend on the contextual situation of involved devices. Even though there are now several context-oriented middleware systems that provide support for the development of mobile applications, they rarely provide explicit and adequate features for contextsensitive exception handling. This work presents an analysis of existing exception handling mechanisms, which to some extent consider the context-awareness requirements. Besides, it proposes a general model for context-sensitive exception handling and a supporting mechanism implemented using the MoCA (Mobile Collaboration Architecture) infrastructure. MoCA is a publish-subscribe middleware supporting the development of collaborative mobile applications by incorporating explicit services to empower software agents with contextsensitiveness. Finally, this paper reports our experience in implementing contextaware exception handling strategies in some prototype collaborative applications built with the MoCA system.

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

Made available in DSpace on 2014-12-17T15:48:06Z (GMT). No. of bitstreams: 1 RicardoJSJ_DISSERT.pdf: 4102063 bytes, checksum: 92b62a467283fb011a1258e8b80ca7b4 (MD5) Previous issue date: 2013-02-01 / Checking the conformity between implementation and design rules in a system is an important activity to try to ensure that no degradation occurs between architectural patterns defined for the system and what is actually implemented in the source code. Especially in the case of systems which require a high level of reliability is important to define specific design rules for exceptional behavior. Such rules describe how exceptions should flow through the system by defining what elements are responsible for catching exceptions thrown by other system elements. However, current approaches to automatically check design rules do not provide suitable mechanisms to define and verify design rules related to the exception handling policy of applications. This paper proposes a practical approach to preserve the exceptional behavior of an application or family of applications, based on the definition and runtime automatic checking of design rules for exception handling of systems developed in Java or AspectJ. To support this approach was developed, in the context of this work, a tool called VITTAE (Verification and Information Tool to Analyze Exceptions) that extends the JUnit framework and allows automating test activities to exceptional design rules. We conducted a case study with the primary objective of evaluating the effectiveness of the proposed approach on a software product line. Besides this, an experiment was conducted that aimed to realize a comparative analysis between the proposed approach and an approach based on a tool called JUnitE, which also proposes to test the exception handling code using JUnit tests. The results showed how the exception handling design rules evolve along different versions of a system and that VITTAE can aid in the detection of defects in exception handling code / Verificar a conformidade entre a implementa??o de um sistema e suas regras de design ? uma atividade importante para tentar garantir que n?o ocorra a degrada??o entre os padr?es arquiteturais definidos para o sistema e o que realmente est? implementado no c?digo-fonte. Especialmente no caso de sistemas dos quais se exige um alto n?vel de confiabilidade ? importante definir regras de design (design rules) espec?ficas para o comportamento excepcional. Tais regras descrevem como as exce??es devem fluir atrav?s do sistema, definindo quais s?o os elementos respons?veis por capturar as exce??es lan?adas por outros elementos do sistema. Entretanto, as abordagens atuais para verificar automaticamente regras de design n?o proveem mecanismos adequados para definir e verificar regras de design espec?ficas para a pol?tica de tratamento de exce??es das aplica??es. Este trabalho prop?e uma abordagem pr?tica para preservar o comportamento excepcional de uma aplica??o ou fam?lia de aplica??es, baseada na defini??o e verifica??o autom?tica em tempo de execu??o de regras de design de tratamento de exce??o para sistemas desenvolvidos em Java ou AspectJ. Para apoiar esta abordagem foi desenvolvida, no contexto deste trabalho, uma ferramenta chamada VITTAE (Verification and Information Tool to Analyze Exceptions) que estende o framework JUnit e permite automatizar atividades do teste de regras de design excepcionais. Foi realizado um estudo de caso preliminar com o objetivo de avaliar a efic?cia da abordagem proposta sobre uma linha de produto de software. Al?m deste, foi realizado um experimento cujo objetivo foi realizar uma an?lise comparativa entre a abordagem proposta e uma abordagem baseada na ferramenta JUnitE, que tamb?m prop?e testar o c?digo de tratamento de exce??es utilizando testes JUnit. Os resultados mostraram que as regras de design excepcionais evoluem ao longo de diferentes vers?es de um sistema e que a VITTAE pode auxiliar na detec??o de defeitos no c?digo de tratamento de exce??o