Sistemas distribuídos já são de amplo uso atualmente e seu crescimento tende a se acentuar devido a popularização da Internet. Cada vez mais computadores se interligam e trocam informações entre si. Nestes sistemas, requerimentos como confiabilidade, disponibilidade e desempenho são de fundamental importância para a satisfação do usuário. Estes requerimentos podem ser atendidos aproveitando-se da redundância já existente com as maquinas interligadas. Mas para atingir os requisitos de confiabilidade e disponibilidade, protocolos tolerantes a falhas devem ser construídos. Tolerância a falhas visa continuar a fornecer o serviço de algum protocolo, aplicação ou sistema a despeito da ocorrência de falhas durante a sua execução. Tolerância a falhas pode ser implementada por hardware ou por software através de mascaramento ou recuperação de falhas. Recentemente, a injeção de falhas implementada por software tem sido um dos principais métodos utilizados para validar protocolos tolerantes a falhas em sistemas distribuídos, e muitas ferramentas tem sido construídas. Contudo, não ha nenhuma biblioteca de classes orientada a objetos para auxiliar novos pesquisadores na construção da sua própria ferramenta de injeção de falhas. Este trabalho apresenta uma proposta de uma arquitetura orientada a objetos escrita em C++ para sistemas operacionais UNIX usando sockets, de modo a alcançar aquele objetivo. Esta arquitetura é chamada de AFIDS (Architecture for Fault Injection in Distributed Systems). AFIDS pretende fornecer uma estrutura básica que aborda as questões principais no processo de injeção de falhas implementada por software: a) a Geraldo de parâmetros de falhas para o experimento, b) o controle da localização, tipo e tempo da injeção de falhas, c) a coleta de dados do experimento, d) a injeção efetiva da falha e a análise dos dados coletados de modo a obter medidas de dependabilidade sobre o protocolo tolerante a falhas. Ou seja, AFIDS pretende ser um framework para a construed° de ferramentas de injeção de falhas. Segundo [BOO 961: "Através do uso de frameworks maduros, o esforço de desenvolvimento torna-se mais fácil, porque os principais elementos funcionais podem ser reutilizados". AFIDS leva em consideração várias questões de projeto que foram obtidas através da analise de oito ferramentas de injeção de falhas por software para sistemas distribuídos: FIAT [SEG 88], EFA [ECH 92. ECH 94], SFI [ROS 93], DOCTOR [HAN 93], PFI [DAW 94], CSFI [CAR 95a], SockPFI [DAW 95] e ORCHESTRA [DAW 96]. Para auxiliar a construção de AFIDS, é apresentada uma ferramenta de injeção de falhas que utiliza um objeto injetor de falhas por processo do protocolo sob teste. AFIDS e esta ferramenta são implementadas em C++ usando sockets em Linux. Para que AFIDS se tome estável e consistente e necessário que outras ferramentas sejam construídas baseadas nela. Isto é enfatizado porque, segundo [BOO 96]: "Um framework são começa a alcançar maturidade apos a sua aplicação em pelo menos três ou mais aplicações distintas". / Currently, distributed systems are already in wide use. Because of the Internet popularization their growth tend to arise. More and more computers interconnect and share information. In these systems, requirements such as reliability, availability and performance are fundamental in order to satisfy the users. These requirements can be reached taking advantage of the redundancy already associated with the computers interconnected. However, to reach the reliability and availability requirements, fault tolerant protocols must be built. Fault tolerance aims to provide continuous service of some protocol, application or system in despite of fault occurrence during its execution. Fault tolerance can be implemented in hardware or software using fault masking or recovery. Recently, the software-implemented fault injection has been one of the main methods used to validate fault tolerant protocols in distributed systems, and many tools has been built. However, there is no object-oriented class library to aid new researchers on the buildin g of own fault injection tool. This work presents a proposal of an objectoriented architecture written in C++ for UNIX operating systems using sockets, in order to reach that purpose. This architecture is called AFIDS (Architecture for Fault Injection in Distributed Systems). AFIDS intends to provide a basic structure that addresses the main issues of the process of software-implemented fault injection: a) the generation of fault parameters for the experiment, b) the control of the location, type and time of the fault injection, c) the data collection of the experiment, d) the effective injection of the faults, and e) the analysis of collected data in order to obtain dependability measures about the fault tolerant protocol sob test. According to [BOO 96]: "By using mature frameworks, the effort of the development team is made even easier, because now major functional elements can be reused.". AFIDS regards various design issues that were obtained from the analysis of eight tools of software-implemented fault injection for distributed systems: FIAT [SEG 88], EFA [ECH 92, ECH 94], SFI EROS 93], DOCTOR [HAN 93], PFI [DAW 94], CSFI [CAR 95a], SockPFI [DAW 95] e ORCHESTRA [DAW 96]. In order to aid the AFIDS building, a fault injection tool that uses one injector object in each process of protocol under test is shown. AFIDS and this tool are implemented in C++ using sockets on Linux operating system. AFIDS will become stable and consistent after the building of others tools based on it. This is emphasized because, according to [BOO 96]: "A framework does not even begin to reach maturity until it has been applied in at least three or more distinct applications".

Interação homem-máquina, também difundida com o nome de Interface com o Usuário (ou simplesmente interface), é uma área de pesquisa relativamente recente e evidentemente multidisciplinar. Um importante critério para projeto de interfaces é a separação de um programa interativo em seu componente computacional (aplicação) e seu componente de diálogo (que implementa a interface) • Esta separação, denominada independência de diálogo, . cr1a o papel do projetista de interfaces separado do programador da aplicação e a necessidade de novas comunicações entre os componentes do programa e o usuário. O componente de diálogo é usualmente construído usando-se alguma Ferramenta para Desenvolvimento de Interfaces com o Usuário (abreviadas FIUs) para definição e manipulação de interfaces. As FIUs comercialmente disponíveis atualmente (na sua maioria "toolboxes" como MicroSoft Windows e Macintosh Toolbox, entre outras), no entanto, não são tão facilmente utilizáveis, contendo literalmente centenas de rotinas e confundindo freqüentemente os papéis do projetista de interfaces e do programador da aplicação. Isto acarreta prejuízos à almejada independência de diálogo .Além disto, devido às idiossincrasias de cada FIU, o p r ograma interativo é desenvolvido direcionado para o uso de uma FIU específica, necessitando de uma série de reformulações em caso de mudanças de FIU. O objetivo da dissertação é a proposta de uma FIU Canônica que permite: a) uma definição de interface de maneira mais adequada aos usuários projetistas, programador da aplicação; e mais notadamente ao b) a portabilidade de programas interativos entre diferentes FIUs. O componente principal da FIU Canônica é o seu modelo representacional orientado a objetos, o Canonicus, que contém as abstrações necessárias para o uso adequado dos usuários projetistas. A portabilidade vem do fato da FIU Canônica ser, na verdade, uma camada intermediária entre a aplicação e uma FIU. Sua implementação consiste na tradução de seus objetos e operações para objetos e operações de alguma FIU subjacente. Nesta dissertação sao apresentados a arquitetura da FIU Canônica e o seu modelo representacional Canonicus assim como a sua implementação sobre duas FIUs tipo "toolbox" comerciais, o MicroSoft Windows e o Macintosh Toolbox. / Human-computer interactionf interface f lS a mul tidisciplinary and research issue. also named use r relatively recent An important criteria to user interface design is the separation of interactive program in two components: computational component (application) and dialogue component (which implements the user interface). This separationf interface named dialogue independencef independent creates the user designer role of application programmer role and new components-user communications. The dialogue component is usually constructed by using some User Interface Development Tool (abreviated FIU) to both user interface definition and manipulation. The comercial FIUs available (most of them are toolboxes like MicroSoft Windows and Macintosh Toolbox) f howeverf are often not so easily usable, since they contain literally hundreds of procedures and they confuse the interface designer and application programmer roles. Thus the desirable dialogue independence is prejudiced. Furthermore, an one interactive program is developed directed to use only one specific FIU, since each FIU has its idiosycrasies. In case o f FIU change, several reformulations are needed. The dissertation goal is the purpose of the Canonical FIU. The Canonical FIU allows: a) an user interface definition in more adequate way to its designer-users, more notably the application programmer; and b) interactive programs portability between diferent FIUs. The Canonical FIU main component is its objectoriented representational model, the Canonicus, which contains the needed abstractions to user interface designers. Portability is obtained slnce the Canonical FIU lS an intermediate level between the application and a FIU. The Canonical FIU lS implemented by a translation mechanism, mapping its objects and operations to some subjacent FIU's objects and operations. In this dissertation, the Canonical FIU architecture, its representational model Canonicus and its implementations over two FIUs (MicroSoft Windows and Macintosh Toolbox) are presented.

Este trabalho apresenta um mecanismo para evolução de esquemas para bancos de dados orientados a objetos. A necessidade de alteração do esquema conceitual de dados pode surgir em qualquer momento da vida de um sistema, por motivos como incorporar novas especificações e necessidades do usuário, reaproveitamento de classes em outros sistemas a correção de falhas de modelagem. Uma ferramenta deste tipo deve permitir ao usuário a maior variedade possível de alterações e, ao mesmo tempo, possibilitar um alto grau de independência lógica de dados, para reduzir ao máximo possível a necessidade de alteração dos programas de aplicação que utilizam o esquema. O modelo de dados utilizado está baseado nos modelos de outros sistemas orientados a objetos, como Orion é O2. Ele permite a definição de classes, atributos simples e construídos pelo usuário, métodos, como forma de encapsular os objetos e herança múltipla de atributos e métodos para subclasses. Além disso, para manter o histórico de modificações realizadas, versões de instâncias, classes e métodos são utilizadas. Versões de um objeto formam um grafo acíclico, sendo a versão mais recente a "default". Como forma de manter a coerência no uso de versões de diferentes objetos, o conceito de contextos de esquemas é definido. A proposta baseia-se no conceito de invariantes, condições básicas para a base de dados ser considerada válida e consistente pelo sistema. Invariantes estruturais e comportamentais são definidos e mantidos. Diversas operações que podem ser realizadas sobre um esquema são descritas, detalhando para cada uma as suas opções e efeitos. Alguns mecanismos auxiliares para aumentar a transparência de alterações de esquemas são esboçados. Como uma aplicação específica do mecanismo genérico apresentado, outro é desenvolvido para o ambiente STAR. Seu modelo de dados e os gerentes de versões e metodologia são explicados, tendo suas características mais relevantes para este trabalho detalhadas. Tomando o esquema de objeto como um esquema de dados e as tarefas do gerente de metodologias como métodos, o mecanismo também se baseia em invariantes que são utilizados para validar a correção das modificações realizadas, cuja semântica está descrita detalhadamente. O mecanismo definido revelou-se extremamente flexível e capaz de manter não só o histórico do desenvolvimento de determinada aplicação, como também alternativas de um mesmo sistema que esteja sendo construído utilizando um banco de dados orientado a objetos, tendo atendido satisfatoriamente aos requisitos básicos definidos inicialmente. / This work presents a schema evolution mechanism, based on an object oriented data model. Conceptual schema modifications are needed al any moment in the life cycle of a system, for example, to incorporate new specifications and users' solicitations, to reuse classes developed for other system and to correct modeling errors. This mechanism has to allow a great number of different operations and, at the same time, a high data logic independence to reduce the number of changes in applications programs. For this proposal we are considering an object oriented data model, similar to those existing in Orion and O2. Class definitions, simple attributes and attributes constructed by the user, methods to encapsulate objects and multiple inheritance of attributes and methods to subclasses are allowed. Instances, classes and methods are versionable. Connected directed acyclic graphs organize the versions of an object. There is one current version, which either is the most recent (the default) or one defined by the user. Schema contexts are introduced to keep track of the correspondence that exists among all the versions created, assuring the selection of a method version adequate for a version instance. The mechanism is based on schema invariants, that are basic conditions that always must be satisfied in order to insure that the schema is in a correct state. Structural and behavioral invariants are defined and checked by the system. The designer can use a complete set of operations to change the schema. The semantic of all operations is described, with its options and effects. Some auxiliary mechanisms are incorporated to facilitate schema change transparency. As an application, a generic mechanism for schema evolution is developed to the STAR framework. The data model, version and methodology managers of STAR are explained. The mechanism is based on invariants to validated changes considering an object schema as conceptual schema. and the methodology manager tasks like methods. The mechanism is extremely flexible and capable of maintaining the history of schema development and alternatives of classes ; methods and instances' descriptions. The previously defined characteristics are allowed in a satisfactorily way, resulting in a very useful tool for software design.

Sistemas distribuídos já são de amplo uso atualmente e seu crescimento tende a se acentuar devido a popularização da Internet. Cada vez mais computadores se interligam e trocam informações entre si. Nestes sistemas, requerimentos como confiabilidade, disponibilidade e desempenho são de fundamental importância para a satisfação do usuário. Estes requerimentos podem ser atendidos aproveitando-se da redundância já existente com as maquinas interligadas. Mas para atingir os requisitos de confiabilidade e disponibilidade, protocolos tolerantes a falhas devem ser construídos. Tolerância a falhas visa continuar a fornecer o serviço de algum protocolo, aplicação ou sistema a despeito da ocorrência de falhas durante a sua execução. Tolerância a falhas pode ser implementada por hardware ou por software através de mascaramento ou recuperação de falhas. Recentemente, a injeção de falhas implementada por software tem sido um dos principais métodos utilizados para validar protocolos tolerantes a falhas em sistemas distribuídos, e muitas ferramentas tem sido construídas. Contudo, não ha nenhuma biblioteca de classes orientada a objetos para auxiliar novos pesquisadores na construção da sua própria ferramenta de injeção de falhas. Este trabalho apresenta uma proposta de uma arquitetura orientada a objetos escrita em C++ para sistemas operacionais UNIX usando sockets, de modo a alcançar aquele objetivo. Esta arquitetura é chamada de AFIDS (Architecture for Fault Injection in Distributed Systems). AFIDS pretende fornecer uma estrutura básica que aborda as questões principais no processo de injeção de falhas implementada por software: a) a Geraldo de parâmetros de falhas para o experimento, b) o controle da localização, tipo e tempo da injeção de falhas, c) a coleta de dados do experimento, d) a injeção efetiva da falha e a análise dos dados coletados de modo a obter medidas de dependabilidade sobre o protocolo tolerante a falhas. Ou seja, AFIDS pretende ser um framework para a construed° de ferramentas de injeção de falhas. Segundo [BOO 961: "Através do uso de frameworks maduros, o esforço de desenvolvimento torna-se mais fácil, porque os principais elementos funcionais podem ser reutilizados". AFIDS leva em consideração várias questões de projeto que foram obtidas através da analise de oito ferramentas de injeção de falhas por software para sistemas distribuídos: FIAT [SEG 88], EFA [ECH 92. ECH 94], SFI [ROS 93], DOCTOR [HAN 93], PFI [DAW 94], CSFI [CAR 95a], SockPFI [DAW 95] e ORCHESTRA [DAW 96]. Para auxiliar a construção de AFIDS, é apresentada uma ferramenta de injeção de falhas que utiliza um objeto injetor de falhas por processo do protocolo sob teste. AFIDS e esta ferramenta são implementadas em C++ usando sockets em Linux. Para que AFIDS se tome estável e consistente e necessário que outras ferramentas sejam construídas baseadas nela. Isto é enfatizado porque, segundo [BOO 96]: "Um framework são começa a alcançar maturidade apos a sua aplicação em pelo menos três ou mais aplicações distintas". / Currently, distributed systems are already in wide use. Because of the Internet popularization their growth tend to arise. More and more computers interconnect and share information. In these systems, requirements such as reliability, availability and performance are fundamental in order to satisfy the users. These requirements can be reached taking advantage of the redundancy already associated with the computers interconnected. However, to reach the reliability and availability requirements, fault tolerant protocols must be built. Fault tolerance aims to provide continuous service of some protocol, application or system in despite of fault occurrence during its execution. Fault tolerance can be implemented in hardware or software using fault masking or recovery. Recently, the software-implemented fault injection has been one of the main methods used to validate fault tolerant protocols in distributed systems, and many tools has been built. However, there is no object-oriented class library to aid new researchers on the buildin g of own fault injection tool. This work presents a proposal of an objectoriented architecture written in C++ for UNIX operating systems using sockets, in order to reach that purpose. This architecture is called AFIDS (Architecture for Fault Injection in Distributed Systems). AFIDS intends to provide a basic structure that addresses the main issues of the process of software-implemented fault injection: a) the generation of fault parameters for the experiment, b) the control of the location, type and time of the fault injection, c) the data collection of the experiment, d) the effective injection of the faults, and e) the analysis of collected data in order to obtain dependability measures about the fault tolerant protocol sob test. According to [BOO 96]: "By using mature frameworks, the effort of the development team is made even easier, because now major functional elements can be reused.". AFIDS regards various design issues that were obtained from the analysis of eight tools of software-implemented fault injection for distributed systems: FIAT [SEG 88], EFA [ECH 92, ECH 94], SFI EROS 93], DOCTOR [HAN 93], PFI [DAW 94], CSFI [CAR 95a], SockPFI [DAW 95] e ORCHESTRA [DAW 96]. In order to aid the AFIDS building, a fault injection tool that uses one injector object in each process of protocol under test is shown. AFIDS and this tool are implemented in C++ using sockets on Linux operating system. AFIDS will become stable and consistent after the building of others tools based on it. This is emphasized because, according to [BOO 96]: "A framework does not even begin to reach maturity until it has been applied in at least three or more distinct applications".

Este trabalho apresenta um mecanismo para evolução de esquemas para bancos de dados orientados a objetos. A necessidade de alteração do esquema conceitual de dados pode surgir em qualquer momento da vida de um sistema, por motivos como incorporar novas especificações e necessidades do usuário, reaproveitamento de classes em outros sistemas a correção de falhas de modelagem. Uma ferramenta deste tipo deve permitir ao usuário a maior variedade possível de alterações e, ao mesmo tempo, possibilitar um alto grau de independência lógica de dados, para reduzir ao máximo possível a necessidade de alteração dos programas de aplicação que utilizam o esquema. O modelo de dados utilizado está baseado nos modelos de outros sistemas orientados a objetos, como Orion é O2. Ele permite a definição de classes, atributos simples e construídos pelo usuário, métodos, como forma de encapsular os objetos e herança múltipla de atributos e métodos para subclasses. Além disso, para manter o histórico de modificações realizadas, versões de instâncias, classes e métodos são utilizadas. Versões de um objeto formam um grafo acíclico, sendo a versão mais recente a "default". Como forma de manter a coerência no uso de versões de diferentes objetos, o conceito de contextos de esquemas é definido. A proposta baseia-se no conceito de invariantes, condições básicas para a base de dados ser considerada válida e consistente pelo sistema. Invariantes estruturais e comportamentais são definidos e mantidos. Diversas operações que podem ser realizadas sobre um esquema são descritas, detalhando para cada uma as suas opções e efeitos. Alguns mecanismos auxiliares para aumentar a transparência de alterações de esquemas são esboçados. Como uma aplicação específica do mecanismo genérico apresentado, outro é desenvolvido para o ambiente STAR. Seu modelo de dados e os gerentes de versões e metodologia são explicados, tendo suas características mais relevantes para este trabalho detalhadas. Tomando o esquema de objeto como um esquema de dados e as tarefas do gerente de metodologias como métodos, o mecanismo também se baseia em invariantes que são utilizados para validar a correção das modificações realizadas, cuja semântica está descrita detalhadamente. O mecanismo definido revelou-se extremamente flexível e capaz de manter não só o histórico do desenvolvimento de determinada aplicação, como também alternativas de um mesmo sistema que esteja sendo construído utilizando um banco de dados orientado a objetos, tendo atendido satisfatoriamente aos requisitos básicos definidos inicialmente. / This work presents a schema evolution mechanism, based on an object oriented data model. Conceptual schema modifications are needed al any moment in the life cycle of a system, for example, to incorporate new specifications and users' solicitations, to reuse classes developed for other system and to correct modeling errors. This mechanism has to allow a great number of different operations and, at the same time, a high data logic independence to reduce the number of changes in applications programs. For this proposal we are considering an object oriented data model, similar to those existing in Orion and O2. Class definitions, simple attributes and attributes constructed by the user, methods to encapsulate objects and multiple inheritance of attributes and methods to subclasses are allowed. Instances, classes and methods are versionable. Connected directed acyclic graphs organize the versions of an object. There is one current version, which either is the most recent (the default) or one defined by the user. Schema contexts are introduced to keep track of the correspondence that exists among all the versions created, assuring the selection of a method version adequate for a version instance. The mechanism is based on schema invariants, that are basic conditions that always must be satisfied in order to insure that the schema is in a correct state. Structural and behavioral invariants are defined and checked by the system. The designer can use a complete set of operations to change the schema. The semantic of all operations is described, with its options and effects. Some auxiliary mechanisms are incorporated to facilitate schema change transparency. As an application, a generic mechanism for schema evolution is developed to the STAR framework. The data model, version and methodology managers of STAR are explained. The mechanism is based on invariants to validated changes considering an object schema as conceptual schema. and the methodology manager tasks like methods. The mechanism is extremely flexible and capable of maintaining the history of schema development and alternatives of classes ; methods and instances' descriptions. The previously defined characteristics are allowed in a satisfactorily way, resulting in a very useful tool for software design.

A manutenção de software a uma realidade presente em todos os sistemas de computação, gerando a necessidade de novas versões que alterem as funcionalidades existentes no software ou adicionem novas. Particularmente, sistemas de tempo-real nem sempre podem ser descontinuados tomando-se indisponíveis para realizar a instalação de uma nova versão. Tais sistemas evidenciam a necessidade de substituição de componentes, representados por funções, procedimentos, módulos ou objetos, durante o processo de execução do programa ou sistema. Outrossim, apos ser realizada a substituição da versão, o componente não pode apresentar falha sob pena de comprometer o fornecimento dos seus serviços. Portanto. constata-se a importância de novas técnicas de manutenção de software que não prejudiquem a sua disponibilidade e confiabilidade. A abordagem aqui proposta a utilizar uma arquitetura reflexiva aliada a técnicas típicas do domínio da tolerância a falhas para promover a separação entre as atividades de substituição e validação de componentes e as funcionalidades executadas pelo pr6prio componente. No decorrer deste trabalho são apresentados diversos cenários de sistemas que podem se beneficiar da troca dinâmica de componentes e abordadas varias facetas do problema de substituição. A proposta a apoiada por um estudo de caso, implementado na linguagem de programação Java e seus diferentes protocolos de reflexão computacional. / Software maintenance is a present reality in all computational systems. This demands the frequent installation of new versions. Usually, real-time systems cannot be interrupted to install a new version. For such systems, the replacement of components, represented by functions, procedures, modulus or objects, must be performed during the execution of the program or system. Even when the old version has been replaced, the new one should not contain faults that could invalidate its services. Therefore, we need new software maintenance techniques that can mantain the system availability and realibility. The approach proposed here consists in using a reflective architecture along with techniques which are typical of the fault tolerant domain. The procedure is carried out by keeping a clear separation between validation activities and the functions executed by the component itself. We present several scenarios to which the dynamical exchange of components can be applied. Different aspects of the replacing issue are also addressed. The proposal is supported by a specific application which has been implemented in the Java language and its different protocols of computational reflection.

Interação homem-máquina, também difundida com o nome de Interface com o Usuário (ou simplesmente interface), é uma área de pesquisa relativamente recente e evidentemente multidisciplinar. Um importante critério para projeto de interfaces é a separação de um programa interativo em seu componente computacional (aplicação) e seu componente de diálogo (que implementa a interface) • Esta separação, denominada independência de diálogo, . cr1a o papel do projetista de interfaces separado do programador da aplicação e a necessidade de novas comunicações entre os componentes do programa e o usuário. O componente de diálogo é usualmente construído usando-se alguma Ferramenta para Desenvolvimento de Interfaces com o Usuário (abreviadas FIUs) para definição e manipulação de interfaces. As FIUs comercialmente disponíveis atualmente (na sua maioria "toolboxes" como MicroSoft Windows e Macintosh Toolbox, entre outras), no entanto, não são tão facilmente utilizáveis, contendo literalmente centenas de rotinas e confundindo freqüentemente os papéis do projetista de interfaces e do programador da aplicação. Isto acarreta prejuízos à almejada independência de diálogo .Além disto, devido às idiossincrasias de cada FIU, o p r ograma interativo é desenvolvido direcionado para o uso de uma FIU específica, necessitando de uma série de reformulações em caso de mudanças de FIU. O objetivo da dissertação é a proposta de uma FIU Canônica que permite: a) uma definição de interface de maneira mais adequada aos usuários projetistas, programador da aplicação; e mais notadamente ao b) a portabilidade de programas interativos entre diferentes FIUs. O componente principal da FIU Canônica é o seu modelo representacional orientado a objetos, o Canonicus, que contém as abstrações necessárias para o uso adequado dos usuários projetistas. A portabilidade vem do fato da FIU Canônica ser, na verdade, uma camada intermediária entre a aplicação e uma FIU. Sua implementação consiste na tradução de seus objetos e operações para objetos e operações de alguma FIU subjacente. Nesta dissertação sao apresentados a arquitetura da FIU Canônica e o seu modelo representacional Canonicus assim como a sua implementação sobre duas FIUs tipo "toolbox" comerciais, o MicroSoft Windows e o Macintosh Toolbox. / Human-computer interactionf interface f lS a mul tidisciplinary and research issue. also named use r relatively recent An important criteria to user interface design is the separation of interactive program in two components: computational component (application) and dialogue component (which implements the user interface). This separationf interface named dialogue independencef independent creates the user designer role of application programmer role and new components-user communications. The dialogue component is usually constructed by using some User Interface Development Tool (abreviated FIU) to both user interface definition and manipulation. The comercial FIUs available (most of them are toolboxes like MicroSoft Windows and Macintosh Toolbox) f howeverf are often not so easily usable, since they contain literally hundreds of procedures and they confuse the interface designer and application programmer roles. Thus the desirable dialogue independence is prejudiced. Furthermore, an one interactive program is developed directed to use only one specific FIU, since each FIU has its idiosycrasies. In case o f FIU change, several reformulations are needed. The dissertation goal is the purpose of the Canonical FIU. The Canonical FIU allows: a) an user interface definition in more adequate way to its designer-users, more notably the application programmer; and b) interactive programs portability between diferent FIUs. The Canonical FIU main component is its objectoriented representational model, the Canonicus, which contains the needed abstractions to user interface designers. Portability is obtained slnce the Canonical FIU lS an intermediate level between the application and a FIU. The Canonical FIU lS implemented by a translation mechanism, mapping its objects and operations to some subjacent FIU's objects and operations. In this dissertation, the Canonical FIU architecture, its representational model Canonicus and its implementations over two FIUs (MicroSoft Windows and Macintosh Toolbox) are presented.

Sistemas distribuídos já são de amplo uso atualmente e seu crescimento tende a se acentuar devido a popularização da Internet. Cada vez mais computadores se interligam e trocam informações entre si. Nestes sistemas, requerimentos como confiabilidade, disponibilidade e desempenho são de fundamental importância para a satisfação do usuário. Estes requerimentos podem ser atendidos aproveitando-se da redundância já existente com as maquinas interligadas. Mas para atingir os requisitos de confiabilidade e disponibilidade, protocolos tolerantes a falhas devem ser construídos. Tolerância a falhas visa continuar a fornecer o serviço de algum protocolo, aplicação ou sistema a despeito da ocorrência de falhas durante a sua execução. Tolerância a falhas pode ser implementada por hardware ou por software através de mascaramento ou recuperação de falhas. Recentemente, a injeção de falhas implementada por software tem sido um dos principais métodos utilizados para validar protocolos tolerantes a falhas em sistemas distribuídos, e muitas ferramentas tem sido construídas. Contudo, não ha nenhuma biblioteca de classes orientada a objetos para auxiliar novos pesquisadores na construção da sua própria ferramenta de injeção de falhas. Este trabalho apresenta uma proposta de uma arquitetura orientada a objetos escrita em C++ para sistemas operacionais UNIX usando sockets, de modo a alcançar aquele objetivo. Esta arquitetura é chamada de AFIDS (Architecture for Fault Injection in Distributed Systems). AFIDS pretende fornecer uma estrutura básica que aborda as questões principais no processo de injeção de falhas implementada por software: a) a Geraldo de parâmetros de falhas para o experimento, b) o controle da localização, tipo e tempo da injeção de falhas, c) a coleta de dados do experimento, d) a injeção efetiva da falha e a análise dos dados coletados de modo a obter medidas de dependabilidade sobre o protocolo tolerante a falhas. Ou seja, AFIDS pretende ser um framework para a construed° de ferramentas de injeção de falhas. Segundo [BOO 961: "Através do uso de frameworks maduros, o esforço de desenvolvimento torna-se mais fácil, porque os principais elementos funcionais podem ser reutilizados". AFIDS leva em consideração várias questões de projeto que foram obtidas através da analise de oito ferramentas de injeção de falhas por software para sistemas distribuídos: FIAT [SEG 88], EFA [ECH 92. ECH 94], SFI [ROS 93], DOCTOR [HAN 93], PFI [DAW 94], CSFI [CAR 95a], SockPFI [DAW 95] e ORCHESTRA [DAW 96]. Para auxiliar a construção de AFIDS, é apresentada uma ferramenta de injeção de falhas que utiliza um objeto injetor de falhas por processo do protocolo sob teste. AFIDS e esta ferramenta são implementadas em C++ usando sockets em Linux. Para que AFIDS se tome estável e consistente e necessário que outras ferramentas sejam construídas baseadas nela. Isto é enfatizado porque, segundo [BOO 96]: "Um framework são começa a alcançar maturidade apos a sua aplicação em pelo menos três ou mais aplicações distintas". / Currently, distributed systems are already in wide use. Because of the Internet popularization their growth tend to arise. More and more computers interconnect and share information. In these systems, requirements such as reliability, availability and performance are fundamental in order to satisfy the users. These requirements can be reached taking advantage of the redundancy already associated with the computers interconnected. However, to reach the reliability and availability requirements, fault tolerant protocols must be built. Fault tolerance aims to provide continuous service of some protocol, application or system in despite of fault occurrence during its execution. Fault tolerance can be implemented in hardware or software using fault masking or recovery. Recently, the software-implemented fault injection has been one of the main methods used to validate fault tolerant protocols in distributed systems, and many tools has been built. However, there is no object-oriented class library to aid new researchers on the buildin g of own fault injection tool. This work presents a proposal of an objectoriented architecture written in C++ for UNIX operating systems using sockets, in order to reach that purpose. This architecture is called AFIDS (Architecture for Fault Injection in Distributed Systems). AFIDS intends to provide a basic structure that addresses the main issues of the process of software-implemented fault injection: a) the generation of fault parameters for the experiment, b) the control of the location, type and time of the fault injection, c) the data collection of the experiment, d) the effective injection of the faults, and e) the analysis of collected data in order to obtain dependability measures about the fault tolerant protocol sob test. According to [BOO 96]: "By using mature frameworks, the effort of the development team is made even easier, because now major functional elements can be reused.". AFIDS regards various design issues that were obtained from the analysis of eight tools of software-implemented fault injection for distributed systems: FIAT [SEG 88], EFA [ECH 92, ECH 94], SFI EROS 93], DOCTOR [HAN 93], PFI [DAW 94], CSFI [CAR 95a], SockPFI [DAW 95] e ORCHESTRA [DAW 96]. In order to aid the AFIDS building, a fault injection tool that uses one injector object in each process of protocol under test is shown. AFIDS and this tool are implemented in C++ using sockets on Linux operating system. AFIDS will become stable and consistent after the building of others tools based on it. This is emphasized because, according to [BOO 96]: "A framework does not even begin to reach maturity until it has been applied in at least three or more distinct applications".

Interação homem-máquina, também difundida com o nome de Interface com o Usuário (ou simplesmente interface), é uma área de pesquisa relativamente recente e evidentemente multidisciplinar. Um importante critério para projeto de interfaces é a separação de um programa interativo em seu componente computacional (aplicação) e seu componente de diálogo (que implementa a interface) • Esta separação, denominada independência de diálogo, . cr1a o papel do projetista de interfaces separado do programador da aplicação e a necessidade de novas comunicações entre os componentes do programa e o usuário. O componente de diálogo é usualmente construído usando-se alguma Ferramenta para Desenvolvimento de Interfaces com o Usuário (abreviadas FIUs) para definição e manipulação de interfaces. As FIUs comercialmente disponíveis atualmente (na sua maioria "toolboxes" como MicroSoft Windows e Macintosh Toolbox, entre outras), no entanto, não são tão facilmente utilizáveis, contendo literalmente centenas de rotinas e confundindo freqüentemente os papéis do projetista de interfaces e do programador da aplicação. Isto acarreta prejuízos à almejada independência de diálogo .Além disto, devido às idiossincrasias de cada FIU, o p r ograma interativo é desenvolvido direcionado para o uso de uma FIU específica, necessitando de uma série de reformulações em caso de mudanças de FIU. O objetivo da dissertação é a proposta de uma FIU Canônica que permite: a) uma definição de interface de maneira mais adequada aos usuários projetistas, programador da aplicação; e mais notadamente ao b) a portabilidade de programas interativos entre diferentes FIUs. O componente principal da FIU Canônica é o seu modelo representacional orientado a objetos, o Canonicus, que contém as abstrações necessárias para o uso adequado dos usuários projetistas. A portabilidade vem do fato da FIU Canônica ser, na verdade, uma camada intermediária entre a aplicação e uma FIU. Sua implementação consiste na tradução de seus objetos e operações para objetos e operações de alguma FIU subjacente. Nesta dissertação sao apresentados a arquitetura da FIU Canônica e o seu modelo representacional Canonicus assim como a sua implementação sobre duas FIUs tipo "toolbox" comerciais, o MicroSoft Windows e o Macintosh Toolbox. / Human-computer interactionf interface f lS a mul tidisciplinary and research issue. also named use r relatively recent An important criteria to user interface design is the separation of interactive program in two components: computational component (application) and dialogue component (which implements the user interface). This separationf interface named dialogue independencef independent creates the user designer role of application programmer role and new components-user communications. The dialogue component is usually constructed by using some User Interface Development Tool (abreviated FIU) to both user interface definition and manipulation. The comercial FIUs available (most of them are toolboxes like MicroSoft Windows and Macintosh Toolbox) f howeverf are often not so easily usable, since they contain literally hundreds of procedures and they confuse the interface designer and application programmer roles. Thus the desirable dialogue independence is prejudiced. Furthermore, an one interactive program is developed directed to use only one specific FIU, since each FIU has its idiosycrasies. In case o f FIU change, several reformulations are needed. The dissertation goal is the purpose of the Canonical FIU. The Canonical FIU allows: a) an user interface definition in more adequate way to its designer-users, more notably the application programmer; and b) interactive programs portability between diferent FIUs. The Canonical FIU main component is its objectoriented representational model, the Canonicus, which contains the needed abstractions to user interface designers. Portability is obtained slnce the Canonical FIU lS an intermediate level between the application and a FIU. The Canonical FIU lS implemented by a translation mechanism, mapping its objects and operations to some subjacent FIU's objects and operations. In this dissertation, the Canonical FIU architecture, its representational model Canonicus and its implementations over two FIUs (MicroSoft Windows and Macintosh Toolbox) are presented.

Esta tese propõe cinco construções para linguagens orientadas a objetos. Algumas delas podem ser implementadas por meio de pré-processadores. Estas construções são: visão de classe, adaptador, extensão de classe, Shell dinâmico e extensão dinâmica. Todas elas são baseadas no conceito de filtro, que e um objeto que intercepta as mensagens enviadas a um outro objeto. Visão de classe permite corrigir interpretações incorretas da semântica de uma classe no código de outras classes. Um filtro é usado para traduzir as mensagens para o significado correto. Adaptadores permitem mudar o tipo de um objeto através de um filtro e são usados para acoplar classes que, de outra forma, seriam incompatíveis quanto a tipos. Extensão de classe permite adicionar métodos e variáveis de instancia a classes sem a necessidade de edição do código fonte destas. Shell dinâmico e extensão dinâmica possuem algumas das características de meta-objetos e meta-classes, respectivamente. Eles formam um modelo reflexivo estaticamente tipado. Shell dinâmico permite redirecionar todas as mensagens enviadas a um objeto e extensão dinâmica permite substituir métodos de uma classe em tempo de execução. Todas as construções são originais, podem ser adicionadas em uma linguagem estaticamente tipada sem danificar o sistema de tipos e resolvem alguns problemas descritos na literatura de orientação a objetos. / This thesis proposes five constructions for object-oriented languages. Some of them can be implemented using a preprocessor. These constructions are: class view, adapter, class extension, dynamic shell, and dynamic extension. All of them are based in the concept of filter, that is an object that intercepts the messages sent to another object. Class view allows correcting misinterpretations about the semantics of a class in code of other classes. A filter is used to translate the messages to the correct semantics. Adapters allow changing the type of an object through a filter and are used to glue type incompatible classes. Class extension allows adding methods and instance variables to classes without editing the source code of these classes. Dynamic Shell and dynamic extension have some of the characteristics of meta-objects and meta-classes, respectively. They compose a statically typed reflective model. Dynamic shell allows to redirect all messages sent to an object and dynamic extension allows replacing methods of a class at run time. All constructs are original and can be added to a statically typed language. They solve some problems described in the object-oriented literature.