Um mecanismo de introspecção para depurar o comportamento de sistemas distribuídos

Tamanho: px
Começar a partir da página:

Download "Um mecanismo de introspecção para depurar o comportamento de sistemas distribuídos"

Transcrição

1 Um mecanismo de introspecção para depurar o comportamento de sistemas distribuídos Thiago Araújo, Carla Wanderley e Arndt von Staa Departamento de Informática PUC-Rio Rio de Janeiro, Brazil {taraujo, cgaldino, Resumo Sistemas distribuídos são difíceis de depurar devido à dificuldade de coletar, organizar e relacionar informações sobre a sua execução. Quando uma falha é descoberta, inferir o estado do sistema e as operações que tenham alguma relação com ela costuma ser uma tarefa difícil, em que técnicas tradicionais de depuração costumam não ser aplicáveis, e quando são, tendem a ser pouco eficazes. Este trabalho apresenta um mecanismo baseado em logs de eventos anotados com informações de contexto, que permitem uma ferramenta de visualização exibir somente os eventos que forem do contexto de interesse do operador que estiver depurando o sistema. Nós aplicamos este mecanismo em um sistema real e seu esforço para detectar e diagnosticar a causa de falhas foi drasticamente reduzido. Abstract Distributed systems are hard to debug due to the difficulty to collect, organize and relate information about their behaviour. When a failure is detected the task to infer the system s state and the operations that have some connection with the problem is often quite difficult and usual debugging techniques often do not apply and, when they do, they are not very effective. This work presents a mechanism based on event logs annotated with contextual information, allowing visualization tools to organize events according to the context of interest for the system operator. We applied this mechanism to a real system and its the effort and cost to detect and diagnose the cause of problems was dramatically reduced. Index Terms Software quality, Software debugability, Software maintenance, Software recovery. I. INTRODUÇÃO Durante o desenvolvimento de sistemas distribuídos é comum necessitar-se de informações de introspecção para avaliar o comportamento do sistema, a fim de auxiliar um desenvolvedor ou mesmo um administrador no processo de análise e diagnóstico de falhas. Uma técnica comum é produzir logs com mensagens que descrevam o comportamento do sistema, associando-as, se possível, com o valor de variáveis do contexto. Entretanto, apesar desta técnica produzir algum resultado, o esforço empregado do ponto de vista de quem está depurando é muito grande [1]. Identificamos que os principais problemas são: Em um sistema real o conjunto de logs costuma ser muito extenso e apresenta informações de diferentes contextos misturadas em uma mesma dimensão, reduzindo a visibilidade das informações relevantes para o problema em questão. Os arquivos de log costumam estar distribuídos em diferentes máquinas, impondo a quem estiver depurando um esforço adicional para acessá-los. É difícil para a pessoa que estiver depurando interrelacionar os eventos, sejam eles do mesmo contexto ou de contextos diferentes, a fim de criar os elos lógicos que expliquem o comportamento faltoso. A forma de representar e exibir os logs são a chave para o problema em questão. O ideal para a pessoa que estiver depurando é poder selecionar somente os eventos do seu contexto de interesse e visualizá-los em uma lista temporal única. Também é interessante descobrir informações de localidade, como por exemplo, de qual máquina o evento foi emitido, executando qual processo, em qual componente, em qual procedimento, disparado por qual usuário, com quais variáveis locais e globais, em qual ponto da pilha de execução, etc. Também é desejável identificar relacionamentos não-explícitos entre os eventos, que muitas vezes podem fornecer pistas para determinar a causa da falha. Finalmente, é importante que somente as informações necessárias sejam apresentadas ao usuário, ressaltando que este pode incorporar diferentes perfis, cada um interessado em um conjunto diferente de informações. Podemos citar como perfis comuns: desenvolvedor da aplicação, desenvolvedor do middleware, administrador da aplicação, administrador da infra-estrutura, entre outros. Este trabalho apresenta um mecanismo de introspecção 1 que procura resolver os problemas citados através de um log em que os eventos são anotados com as informações do contexto em que foram criados. Cada entidade geradora de log (processo, thread, máquina) notifica seus eventos para um repositório central, que os armazena de forma estruturada. Com isso permitimos que, através de uma interface de consulta, um usuário seja capaz de estudar o comportamento do sistema filtrando os eventos a serem exibidos segundo um contexto de interesse. Este contexto é formado por um conjunto de tags que enriquecem a informação do evento e podem ser utilizadas para indicar o que se deseja visualizar. Como exemplo, considere um sistema composto por dispositivos móveis comunicando-se com um servidor em nu-

2 vem. Simplificando o mecanismo, definimos que cada evento gerado por este sistema deva conter uma tag name que representa a máquina de origem e uma tag action que representa a operação corrente. Suponha que cada dispositivo móvel dispara no servidor, dentre outras operações, uma de sincronia de dados. Sabemos que quando um determinado dispositivo dispara esta operação, o servidor apresenta uma falha, entretanto não sabemos o seu nome. Depurando da forma tradicional, ou seja, coletando manualmente os logs de cada dispositivo, teríamos que realizar um esforço muito grande para relacioná-los em uma linha temporal única, e ainda assim seria necessário filtrar esta lista deixando somente os eventos relacionados com a sincronia. Utilizando a interface de consulta proposta, um administrador do sistema precisaria somente especificar qual o contexto de interesse dele, neste caso informando a tag [action:sync], e após encontrar um evento que represente a falha, utilizar o nome do dispositivo de origem para refinar a busca, ou seja, fazer uma nova consulta utilizando as tags [action:sync][name:tablet 1]. Continuando este procedimento o administrador chegará a uma visão limpa do comportamento do sistema que exiba somente os eventos de seu interesse. A fim de avaliar a solução proposta realizamos um estudo de caso utilizando um sistema real de cardápios digitais, que possui um alto grau de complexidade devido à sua flexibilidade de configuração e às garantias de retrocompatibilidade que implementa, tornando-o interessante para o problema em questão. Avaliamos o mecanismo proposto de duas formas: (1) medindo o esforço para instrumentar o sistema e (2) em um experimento com usuários reais utilizando a interface de consulta para diagnosticar falhas, outrora descobertas no ambiente de produção. A expectativa era que o esforço de instrumentação fosse baixo e que os usuários conseguissem diagnosticar as falhas em um tempo inferior ao que foi necessário quando elas foram descobertas no ambiente de produção. Ambas as expectativas foram atendidas e o mecanismo proposto demonstrou ser uma ferramenta poderosa de depuração. O artigo esta organizado da seguinte forma: na seção 1 introduzimos o problema; na seção 2 apresentamos contexto de pesquisa em que foi realizado este trabalho; na seção 3 descrevemos a nossa solução; na seção 4 apresentamos o estudo de caso realizado sobre um sistema de cardápio digital; na seção 5 discutimos os trabalhos relacionados; e, finalmente, na seção 6 concluímos o trabalho e apresentamos os próximos passos desta pesquisa. II. CONTEXTO DE PESQUISA Este trabalho foi desenvolvido no contexto de uma pesquisa em sistemas orientados à recuperação [2]. Em tais 1 Capacidade do sistema conhecer a si mesmo, disponibilizando metainformações sobre a sua estrutura interna e seu comportamento durante a execução. sistemas assume-se que defeitos podem existir [3] [4] e que, em um primeiro momento, o sistema deve estar preparado para, em curto espaço de tempo, tratar as consequentes falhas a fim de evitar danos e manter os serviços disponíveis (MT- TRc 2 ), e num segundo momento, determinar as causas dessas falhas e removê-las (MTTRp 3 ). Esta abordagem permite que durante o tempo em que a falha está sendo diagnosticada para identificar o defeito e a seguir removê-lo o sistema continue em uso, ainda que com funcionalidades reduzidas. Desejamos que, a partir da criação de uma infra-estrutura para tratar da coleta e análise das informações de um sistema, sejamos capazes de identificar seus comportamentos anômalos, diagnosticá-los, e, quando se tratar de uma falha, possamos compensá-la e escolher a estratégia adequada para recuperar o sistema. Quando falamos em anomalias referimonos tanto a comportamentos inesperados, exceções, dados inconsistentes ou até mesmo falhas que comprometam a execução da aplicação como um todo, como por exemplo, uma falha de segmentação. Abordagens semelhantes a esta vêm sendo produzidas no contexto de computação autonômica [5] e seus avanços podem ser encontrados em trabalhos como [6], [7], [8], [9] e [10]. Para ser capaz de corrigir um sistema em tempo de execução, sua infra-estrutura deve apresentar alguns mecanismos, entre eles: Introspecção - O sistema deve ser capaz de conhecer a si mesmo, ou seja, deve disponibilizar para consulta informações sobre sua arquitetura, suas funcionalidades e seu estado em cada ponto de uma execução [11]. Coleta de eventos - As informações sobre a execução de um sistema devem ser coletadas e organizadas em uma base de dados para facilitar o raciocínio sobre a sua integridade. As consultas sobre esta base de dados devem poder ser realizadas a partir de agentes internos, como mecanismos de verificação e recuperação, ou externos, como desenvolvedores depurando a aplicação. Detecção de falhas - O sistema deve apresentar mecanismos para verificar os contratos da aplicação [12] e notificar as falhas encontradas. Entendemos como falha qualquer comportamento que impeça a execução de uma operação ou resulte em um estado inconsistente. Compensação de falhas - Capacidade de repor o sistema em um estado correto sem corrigir a falha. Dependendo da natureza da falha ela pode levar o sistema a um estado inconsistente, seja pela falha em si, ou pela execução incompleta da atividade interrompida. Logo, é necessário dispor de mecanismos para reverter os efeitos colaterais de uma falha e restaurar o sistema a um estado consistente mesmo que não se tenha corrigido as consequências da falha. 2 MTTRc - Mean Time To Recover 3 MTTRp - Mean Time To Repair

3 Recuperação de falhas - Capacidade de por o sistema em estado correto corrigindo o efeito da falha, ao invés de meramente por em algum estado correto. A partir da detecção de uma falha deve ser adotada uma estratégia que faça com que a aplicação volte à rotina normal de execução. Dentre estas estratégias, podemos citar, entre outras, a reexecução da atividade faltosa, a reinicialização ou substituição de componentes seguida da reexecução. Flexibilidade na arquitetura - A fim de aumentar a robustez do sistema, a sua infra-estrutura deve permitir que a aplicação continue operante ainda que possua módulos comprometidos ou inoperantes devido a falhas, e estes, possam ser restaurados a partir dos mecanismos de recuperação. O presente artigo tem foco nas etapas de introspecção e coleta de eventos e busca responder as seguintes questões: Qual o grau de introspecção que o sistema deve ter? O que deve ser coletado? Como estas informações devem ser armazenadas? Além disso, conhecemos a princípio quais pontos do código são mais propensos a falhas, logo devem ter um grau de introspecção maior? Certamente não, pois é impossível prever todos os casos de falha que um sistema está sujeito e quais informações serão necessárias para detectá-las, logo, os mecanismos citados devem permitir que a equipe de manutenção aprenda com as falhas ao longo da vida útil do software e insira novas informações de introspecção de forma incremental. Ainda que parte das falhas possa ser compensada ou mesmo recuperada com soluções gerais, como a reinicialização de um serviço, a reconexão de um componente ou a limpeza de um cache, existem outras que necessitam de intervenção humana para realizar seu diagnóstico e definir como deve ser a sua recuperação. Para estas, ao menos na primeira vez, o diagnóstico e a correção devem ser realizados por humanos, e, em seguida, estes podem ser implementados como rotinas de detecção e recuperação. Sendo assim, as etapas de introspecção e coleta de eventos devem ser projetadas de forma que atendam também às necessidades dos usuários humanos, a fim de reduzir seu esforço na depuração das falhas encontradas. adequada para a depuração?. Infelizmente não, pois a forma mais adequada depende do problema que está sendo tratado no momento. O mesmo evento pode ser interessante para dois perfis de depuração distintos. Por exemplo, um evento de falha na autenticação pode ser interessante tanto para o desenvolvedor que está verificando por que o seu componente não interage mais com o sistema, como para o administrador da infra-estrutura que está atendendo uma reclamação de um usuário que não consegue realizar o login. Observe que são contextos diferentes, e se ainda assim tentarmos gerar um log para cada um deles duplicando os eventos que forem interessantes a ambos, podemos cair no mesmo problema, em que o usuário deseja uma organização ligeiramente diferente. Idealmente o usuário deve ser capaz de visualizar somente os eventos de interesse para o problema em questão, portanto, propomos um modelo em que o evento deve sempre conter as propriedades do seu contexto atual, e a partir destas definir se ele é interessante ou não para a visualização corrente do depurador. Em nossa solução o evento é representado com uma mensagem, um identificador temporal e um conjunto de tags. Cada tag é representada por um par nome-valor, representando as propriedades contextuais do sistema no instante em que o evento foi criado. O valor de cada tag é opcional, dependendo da sua natureza. Um evento pode ser identificado unicamente no sistema a partir do par formado pelo seu identificador temporal e a máquina de origem. Na Figura 1 apresentamos a arquitetura desta solução, cuja explicação será dividida em três partes: (1) a escrita das informações de introspecção, (2) o fluxo dos eventos, e (3) a ferramenta para inspecionar o comportamento do sistema. III. UM LOG COM INFORMAÇÕES DE CONTEXTO Analisando o modelo mental de um desenvolvedor que está depurando logs de um sistema distribuído, a primeira pergunta que este se faz é: porque eles não estão todos em um mesmo arquivo? Devido à natureza deste tipo de sistema é comum o log estar distribuído em diferentes máquinas, separados por serviços, componentes ou ainda por intervalo de tempo. Portanto, estudar o comportamento deste tipo de sistema exige um esforço considerável. Assim que este desenvolvedor se conforma, a segunda pergunta que ele se faz é: poderiam ao menos estar separados de uma forma mais Figura 1. Arquitetura da solução

4 A. Escreva sua própria informação de introspecção O desenvolvedor terá maior eficácia na depuração se a semântica do sistema for incorporada à geração dos seus eventos. Em geral, não temos necessidade de saber cada função que foi executada, por outro lado, seria ótimo saber por quais etapas do procedimento ele passou. Como o próprio desenvolvedor define as etapas existentes em cada procedimento durante a fase de projeto do sistema, é importante que ele participe também do processo de construção das informações de introspecção, inserindo-as durante a codificação como uma instrumentação no código. Consequentemente, deverá ser implementada para cada plataforma uma biblioteca seguindo a interface a seguir: interface Tag { attribute string key; attribute string value; } typedef sequence<tag> TagList; interface TagDictionary { attribute TagList tags; } module EventMonitor { void notifyevent(in string message); void notifyevent( in string message, in TagDictionary dict); void pushtag(in string name); void pushtag( in string name, in string value); void poptag(); } O processo de instrumentação é tão simples quanto o de escrita de logs, inclusive deve ser encarado desta forma pelos desenvolvedores. Em cada ponto do código que seja interessante colocar uma notificação de log, deve ser inserida também a notificação de um evento para o mecanismo de introspecção (ou somente este último). Salientamos que a escrita da instrumentação deva ser realizada junto com a codificação do sistema, pois este é um dos momentos em que o desenvolvedor tem maior atenção sobre aquela parte do código. Descrevendo a interface apresentada, a principal primitiva é o método notifyevent que cria um novo evento e promove seu registro na linha temporal do sistema. Este método recebe como parâmetro uma mensagem e, opcionalmente, o conjunto de tags que representa o contexto em que o evento está inserido. Como exemplo, a mensagem Invalid client settings poderia estar associada a tags como platform, request id, step, com os valores: web server, 1234 e verifying client settings, respectivamente. Em Python, por exemplo, teríamos um código assim: logger.notify( Invalid client settings, { platform : web server, request_id : 1234, step : verifying client settings }) Por mais simples que seja este último exemplo podemos identificar que algumas tags terão uma frequência muito grande, como a tag request id, e em alguns casos estarão em todos os eventos gerados, como, por exemplo, a tag platform. Para reduzir o esforço do usuário na tarefa de instrumentação e viabilizar a utilização da técnica, a biblioteca deve fornecer as primitivas pushtag e poptag, que inserem e removem tags de uma pilha global, respectivamente. Esta pilha representa o contexto corrente da execução e suas tags são inseridas em todos os eventos gerados. Naturalmente, quando o desenvolvedor empilha ou desempilha alguma tag ele está informando ao mecanismo de introspecção que o contexto está sendo alterado, e, quando os próximos eventos forem notificados, eles serão anotados com este novo estado da pilha. Utilizando a pilha de contexto, podemos reescrever o exemplo anterior da seguinte forma: # Na função main da aplicação logger.push_tag( platform : web server )... # Na função que trata de novas requisições logger.push_tag( request_id : request.id)... # No ponto de notificação especificamente logger.notify( Invalid client settings, { step : verifying client settings }) No exemplo acima emitimos um evento com três tags, sendo as duas primeiras definidas através da pilha de contexto e a última definida durante a notificação. Como a tag platform deve estar presente em todos os eventos e seu valor é constante, ela pôde ser empilhada diretamente na função main da aplicação. Entretanto, apesar da tag request id estar presente em todos os eventos emitidos durante a execução de um tratamento de requisição, o seu valor muda a cada chamada, portanto, ela só pôde ser empilhada no escopo em que o valor deste identificador é definido. Além de evitar a reescrita de tags em cada notificação de evento, a pilha de tags resolve o problema de visibilidade das informações entre escopos: devido ao encapsulamento, é comum uma função não ter acesso a todas as variáveis que representam o seu contexto corrente, pois uma parte considerável pode estar definida em escopos superiores. Portanto, os eventos notificados nestas funções apresentariam um contexto incompleto, reduzindo a eficácia da inspeção. A pilha de tags resolve este problema mantendo armazenadas as tags dos escopos superiores, que são embutidas automaticamente em eventos criados nos escopos inferiores. Como exemplo, os eventos emitidos na camada de banco de dados terão uma tag com o identificador da requisição corrente, que foi definido na camada de controle. Naturalmente, as chamadas push tag e pop tag devem formar um par, ou seja, cada chamada a função push tag deve ter associada uma chamada pop tag para limitar o escopo

5 de atuação da tag. Continuando o exemplo anterior, as suas chamadas pop tag seriam inseridas da seguinte forma: # No final da função que trata de requisições logger.pop_tag()... # No final da função main da aplicação logger.pop_tag() A chamada pop tag remove a tag presente no topo da pilha. Observe que esta chamada não recebe parâmetros, pois assume que sempre removerá a tag inserida pelo seu par. Ou seja, se eu entrei em um contexto de sincronia e fiz a chamada push tag( sync ), espera-se que a chamada pop tag() ao final deste escopo remova, com precisão, a tag sync. Imediatamente consideramos que isso era um risco para a técnica, pois eventualmente o desenvolvedor esqueceria de desempilhar alguma tag, tornando a pilha inconsistente até o final da execução do sistema. Para contornar este problema sugerimos a implementação de açúcares sintáticos nas bibliotecas, cujo funcionamento deve ser definido de acordo com a linguagem de implementação. Na linguagem Objective-C por exemplo, criamos um envelope, que consiste em uma variável alocada na pilha cujo construtor empilha a tag (push tag) e o destrutor desempilha automaticamente pop tag ao término do escopo da variável. Em Python adotamos uma abordagem um pouco diferente: criamos um decorator de função que empilha uma nova tag ao entrar na função e a desempilha ao sair, tanto por retorno normal quanto um retorno de exceção. Envelope em Objective-C: - (void)myfunc { SCOPED_TAG( operation, processing request )... } Decorator em operation, processing request ) def processclientrequest():... É importante salientar que a biblioteca de apoio à instrumentação deve ser implementada com foco na linguagem de programação alvo e seguindo sua filosofia de utilização, a fim de produzir uma interface de interação mais amigável ao desenvolvedor. B. O fluxo de eventos Primeiramente, é importante definir o que é um evento: é uma mensagem com um conjunto de tags associadas e um identificador temporal. Cada tag por sua vez é um par <nome, valor>, em que o campo valor é opcional. A fim de garantir a interoperabilidade entre diferentes bibliotecas, cada evento é serializado em um formato bem definido, que segue o seguinte padrão: cada tag é escrita sob a forma de uma tupla [<nome>:<valor>] e tanto o identificador temporal quanto a mensagens são consideradas tags neste momento. Um evento é uma sequência de tuplas com uma quebra de linha no final, como no exemplo a seguir. [application:hello world] [environment:server] [component:web server] [request id:1234] [client id:4321] [operation:processing client request] [message: verifying client settings]\n Após serializados, os eventos são enviados a um servidor central responsável pelo seu tratamento e armazenamento. No entanto, o processo de envio pode não ser trivial se considerarmos que o sistema é distribuído e envolve diferentes plataformas, cada uma com um conjunto de características que influencia a etapa de notificação. Em um sistema web sendo executado na intranet do servidor central, por exemplo, o processo de envio de novos eventos pode ser direto e sem confirmação, pois neste caso podemos contar com um alto índice de disponibilidade. Entretanto, quando consideramos aplicações ubíquas, estas podem não ter uma disponibilidade de rede constante, indo além, a rede pode ter uma qualidade baixa, exigindo um mecanismo de retransmissão. Além disso, estas aplicações costumam ser mais suscetíveis a quedas de energia, o que nos remete ao problema de manter em memória os eventos que ainda não foram enviados. Para solucionar estes problemas propomos que as bibliotecas de sistemas ubíquos utilizem uma política de envio de pequenos pacotes, lidos diretamente do disco em um modelo produtorconsumidor. Cada evento criado deve ser imediatamente gravado no arquivo corrente, e quando este atingir um tamanho limite deve ser fechado e marcado para envio. Em caso de falta de energia, ao ser reiniciada a aplicação continua escrevendo no último arquivo. Outra consequência desta abordagem é a garantia que em um desastre, como um acesso inválido de memória, as informações da falha estão salvas antes da aplicação fechar. Conforme dito anteriormente, o armazenamento de eventos é realizado em um servidor central responsável por interpretar as informações recebidas e fazer alguns ajustes, como por exemplo, a normalização de identificadores temporais. Considerando que cada máquina envolvida no sistema possui seu próprio relógio, que eventualmente está diferente do relógio no servidor central, é necessário converter os logs recebidos para o relógio do servidor central. Solucionamos este problema enviando junto com os eventos o timestamp corrente de cada máquina, e a partir dele calculamos o delta temporal ajustando a coerência dos relógios. Em nossa implementação do servidor central armazenamos os eventos em um banco de dados NoSQL [13], devido a forma como estruturamos o evento. Este tipo de banco de dados armazena cada entrada em um formato de tuplas, semelhante a nossa representação de eventos, e utiliza algoritmos de busca otimizados para este tipo de estrutura. Além disso, este tipo de banco de dados pode ser distribuído, e, considerando o problema de volume de eventos, este recurso combinado a estratégias de computação na nuvem podem resolver o problema de uma forma simples e de baixo custo.

6 C. A ferramenta de inspeção Somente armazenar eventos de uma forma estruturada não é suficiente. Se em uma depuração o operador do sistema serializar todos os eventos do banco de dados, ele continuará com o mesmo problema: um volume considerável de dados misturando eventos de diferentes contextos. Voltamos ao problema inicial: como visualizar somente os eventos que tem alguma relação com o problema em análise? Nossa solução foi construir uma ferramenta de visualização que permite selecionar o conteúdo desejado de acordo com o contexto de interesse. A interface desta ferramenta é apresentada na Figura 2. A ferramenta apresenta uma interface simples, com controles que definem o contexto de interesse e a lista de eventos que se encaixam neste contexto (Figura 2a). Estes controles são: Campos para limitar o espaço temporalmente: datas de corte superior e inferior (Figura 2b). Restrições baseadas nas tags de cada evento (Figura 2c). Cada alteração no controle atualiza a lista para o novo contexto. Desta forma, o operador pode começar com restrições muito específicas, como buscar pela tag Error, em seguida encontrar o último evento com ela, que provavelmente é o que ele estava procurando, e a partir deste descobrir mais informações que ajudem a continuar a depuração, como por exemplo, o dispositivo móvel que notificou o erro. Com estas informações, as restrições da busca podem ser modificadas para visualizar o histórico do dispositivo encontrado, inclusive exibindo eventos relacionados a ele em outros dispositivos ou servidores presentes no sistema. Neste momento a visualização pode estar ainda muito poluída, logo o operador deve adicionar novas restrições a fim de restringir ainda mais o escopo, até chegar à sequência de eventos que explique com clareza o comportamento faltoso. As restrições são representadas como duas listas: a primeira contém tags que tornam o evento interessante para o usuário, ou seja, os eventos que possuírem todas estas tags são incluídos na exibição. A segunda lista contém tags que definem os eventos indesejados, ou seja, qualquer evento que possuir uma destas tags é desconsiderado na exibição. Além disso, a restrição pode ser especificada com uma tag que possua apenas nome, ou ainda com um valor definido a partir de uma expressão regular. Outra questão abordada é a poluição visual relacionada ao número de tags no evento. Considere o seguinte exemplo: [environment:mobile] [application:hello world] [cpu:80] [memory:2524] [version:3] [flow:main] [message:main screen loaded]\n Este evento pode ser interessante tanto para avaliar o desempenho da aplicação, através das tags cpu e memory, quanto para a visualização do fluxo de acesso de telas do sistema. Logo, todas as tags devem existir, entretanto, algumas podem não ser interessantes para alguns contextos. A fim de solucionar este problema a ferramenta apresenta um recurso para que o operador indique as tags que não devem ser exibidas na lista de eventos (Figura 2d), a fim de reduzir a poluição visual durante a depuração. Estas tags também podem ser representadas sob a forma de uma expressão regular. A ferramenta também possui um recurso de atualização incremental (Figura 2e), opcional, que faz com que a lista de eventos seja atualizada em tempo real, permitindo que o operador acompanhe o comportamento do sistema como um todo em uma linha temporal única, respeitando as restrições definidas. Relacionado a este recurso de atualização em tempo real, existe o problema de atualização da lista de eventos mesmo quando o recurso de atualização incremental está desativado. Considerando que estamos trabalhando com sistemas distribuídos, dispositivos ubíquos podem passar por períodos sem rede, uma determinada visualização pode se tornar inconsistente em alguns momentos, ou seja, o servidor pode receber um conjunto de eventos interessantes para esta visualização e que não estão sendo exibidos, pois foram renderizadas em um momento anterior à chegada dos eventos. Observe que isso não é o problema de atualização incremental, pois estes novos eventos podem estar intercalados com os existentes no servidor. Para solucionar este problema implementamos nesta interface um algoritmo que verifica se existem novos dados no servidor e os insere na lista, mantendo a ordem temporal. IV. ESTUDO DE CASO: UM CARDÁPIO DIGITAL Fizemos um estudo de caso em um sistema real com o objetivo de medir o esforço necessário para implantar o mecanismo apresentado neste trabalho e verificar se a sua utilização acelera o processo de diagnostico de falhas. O sistema alvo foi uma solução de cardápio digital implementada como um sistema distribuído, composto por um conjunto de tablets por cliente, uma aplicação web para realizar a gestão do conteúdo e um servidor para tratar da sincronização entre a aplicação web e os tablets. O aplicativo executado em cada tablet foi desenvolvido em Objective-C sobre a plataforma ios [14], enquanto a aplicação web e o servidor de sincronia foram implementados em Python, utilizando a biblioteca DJango [15]. O esforço foi medido em percentual de código destinado à instrumentação, pois as horas desprendidas na tarefa foram o único custo para implantação da metodologia proposta. Também fizemos um experimento com usuários reais em um ambiente controlado, em que a tarefa era diagnosticar um conjunto de falhas injetadas propositalmente no sistema. Estas falhas foram descobertas no ambiente de produção e na época foram diagnosticadas da forma tradicional, sem auxilio do mecanismo proposto. O objetivo deste experimento foi avaliar a contribuição da ferramenta no processo de depuração, que foi medido comparando o

7 Figura 2. Screenshot da interface de consulta tempo gasto por cada usuário durante o experimento com o tempo gasto pelo usuário que realizou o diagnóstico original no ambiente de produção. O aplicativo executado no tablet é baseado em uma linha de produto [16] com dois níveis, e, durante a configuração de cada cliente, é produzido um layout customizado seguindo a identidade visual da sua marca, de acordo com a escolha prévia dos assets da linha de produto. Além da escolha dos assets existe uma configuração fina dos mesmos, realizada através de arquivos de configuração. Observe que o layout produzido é sensível a escolha dos assets e das configurações definidas. A aplicação web de gestão do conteúdo permite inserir, editar e remover diferentes tipos de produtos, além de fornecer mecanismos para configurar o aplicativo dos tablets. O servidor de sincronização é responsável pela atualização incremental do conteúdo e das configurações dos tablets. A escolha deste sistema como estudo de caso se adequa perfeitamente ao presente trabalho devido às dificuldades identificadas em seu ambiente de produção, que se deve principalmente ao trabalho concorrente de diferentes tipos de atores sobre as informações de um mesmo cliente. De forma resumida, os atores do sistema são: um administrador configurando a linha de produto de cada cliente segundo suas necessidades, uma equipe de catalogação inserindo a ficha técnica de produtos (Ex: vinhos) requisitados pelos clientes e uma equipe de designers produzindo o layout segundo as especificações de cada cliente. É importante deixar claro que o trabalho realizado por estes atores não é restrito à etapa inicial de implantação do sistema, mas persiste ao longo da sua utilização. Em suma, este sistema possui um número incomum de superusuários que em alguns momentos trabalham concorrentemente com relação ao mesmo cliente, muitas vezes sem estarem conscientes disso. O sistema foi projetado para funcionar desta forma, entretanto, a falta de comunicação entre os envolvidos ou a falta de atenção pode tornar inconsistente a configuração de um cliente. Como exemplo, podemos citar o caso em que um administrador modificou a configuração nos assets A e B, e inseriu o asset C. Em seguida este administrador pediu para o designer responsável adequar o layout as modificações, esquecendo de mencionar a inclusão do asset C. Este problema ainda pode ser agravado considerando que cada parte do sistema é versionada de forma independente e a aplicação dos tablets deve manter retrocompatibilidade. Ou seja, em uma evolução da aplicação web, por exemplo, o servidor responsável pela sincronia deve ser capaz de disponibilizar um conteúdo compatível com todas as versões de tablets em uso. Este sistema ainda compartilha a dificuldade de depuração de aplicações ubíquas, pois o usuário final do sistema (consumidor em um restaurante) não tem interesse, ou mesmo conhecimento, de como reportar um falha a algum responsável que seja capaz de corrigi-la. Esta dificuldade fortalece a proposta deste trabalho, que viabiliza o monitoramento e depuração de cada parte do sistema em tempo real. A. Esforço de instrumentação Decidimos instrumentar o código da aplicação executada nos tablets e o código do servidor de sincronização, pois estas são as partes do sistema que apresentam maior dificuldade de

8 depuração, logo representam maior risco ao projeto. O código das aplicações possuía algumas assertivas executáveis [11], que foram utilizadas como ponto de partida para instrumentálo. O primeiro passo foi definir o conjunto de tags a ser utilizado, que dividimos em tags gerais e tags do domínio da aplicação. O esforço para definir o conjunto de tags é subjetivo e variável de acordo com o tipo de projeto. Neste estudo de caso definimos um conjunto inicial em uma reunião de 2h envolvendo todos os desenvolvedores, e ao longo do tempo, fomos ajustando de acordo com as necessidades identificadas. Aliás, esta flexibilidade na manipulação do conjunto é uma vantagem, pois as evoluções arquiteturais do sistema eventualmente serão refletidas no conteúdo da introspecção. A composição final do conjunto de tags para o sistema em questão foi: Tags gerais: Error - Falha interna ao sistema. Disaster - Falha que causa um dano irrecuperável. Warning - Inconsistência dos dados ou condição suspeita. Environment - Define o ambiente de execução (Ex: mobile). Function - Nome da função corrente. Action - Ação corrente dentro da execução. CPU - Carga corrente de processamento. Memory - Memória ocupada pela aplicação. Tags da aplicação: User - Usuário que disparou a operação. Company - Empresa do usuário que disparou a operação. RequestID - Identificador da requisição corrente. DeviceID - Identificador do dispositivo que executou a operação. DeviceStatus - Estado corrente das informações do dispositivo (Ex: em atualização). CurrentView - Visão corrente do aplicativo embarcado. ItemCode - Item visualizado na tela corrente. O processo de instrumentação levou 20 horas de desenvolvimento, envolvendo dois desenvolvedores que participaram da construção do sistema e possuem um vasto conhecimento sobre o mesmo. Medimos o percentual de código instrumentado contando o número de operações destinadas à configuração e emissão de log, dividindo-as pelo número total de operações, e os resultados foram 7% para o aplicativo embarcado e 14% para o sistema de sincronização, que apresentou um percentual maior por ser um código mais complexo e mais propenso a falhas. Além disso, ainda que o esforço de instrumentação fosse alto, o custo-benefício poderia valer a pena. Suponhamos que o custo de instrumentação fosse equivalente ao custo de produção do sistema, ou seja, teríamos um esforço de 200% para produzi-lo. Se este trabalho adicional permitir que um diagnóstico seja realizado em 5% do tempo original, para sistemas de missão-crítica, o mecanismo proposto ainda seria vantajoso. O custo de instrumentação foi baixo para este estudo de caso e pode ser bem maior para outros sistemas, entretanto a instrumentação deve ser colocada durante o desenvolvimento, seguindo as mesmas regras das assertivas, logo este custo tende a ser diluído na codificação, inclusive, auxiliando o desenvolvedor a raciocinar um pouco mais sobre a estrutura da sua aplicação. B. Avaliação da ferramenta de inspeção Fizemos um teste qualitativo com um grupo de usuários a fim de avaliar a rapidez com que conseguiam diagnosticar falhas através da ferramenta de inspeção. Escolhemos três falhas que ocorreram no sistema em produção cujo custo de depuração foi alto: Problema: Cadastrei um novo cliente, configurei sua conta e enviei o login e senha por . Ele acabou de ligar dizendo que instalou corretamente o aplicativo no tablet mas não consegue ativálo com suas credenciais. A mensagem de erro diz que existe um problema na configuração da conta. Diagnóstico: O administrador que cadastrou a conta esqueceu de fazer o upload do layout produzido para este cliente. Problema: Um cliente acaba de ligar reclamando que seus tablets não estão sendo sincronizados. Diagnóstico: Existe um erro na implementação que permite um prato ser harmonizado com um vinho que não está ativo na carta. Quando o sistema de sincronização compila os dados a serem enviados para o tablet falta uma informação e este aborta a operação. Problema: Acabei de configurar a conta de um cliente que tinha entrado em contato conosco ha três meses, instalado o aplicativo nos tablets, mas não efetuado a compra. Agora que ele fez isso eu configurei sua conta, mas os tablets não estão sendo ativados por algum motivo e indicam que existe um problema na configuração. Tenho certeza que fiz o upload do layout e da configuração. Diagnóstico: O aplicativo instalado nos tablets deste cliente é antigo e requer uma versão de layout anterior a corrente. Como ele não possuía uma conta na época que esta versão era utilizada não existe um layout compatível com ela. Os problemas escolhidos são simples, entretanto sua diagnosticação é difícil quando realizada através das técnicas de depuração tradicionais. Usualmente o log dos tablets é inacessível e o do servidor apresenta um volume considerável de registros, envolvendo diversas operações de diferentes clientes, dificultando sua análise.

9 O primeiro problema ocorreu com uma frequência alta nos primeiros meses de uso do sistema, representando um custo de depuração de 30 minutos em média por incidente. Inclusive, o tempo de depuração desta falha não variou muito, pois a co-evolução do sistema a mascarou de diferentes formas. Os demais problemas ocorreram uma única vez, o primeiro representando um custo de depuração de 1h e o segundo de 2h e 30 minutos. O grupo submetido ao experimento foi composto por quatro pessoas envolvidas no desenvolvimento do sistema, sendo dois desenvolvedores e dois administradores. Fizemos o teste com cada um individualmente, apresentando um problema de cada vez e pedindo que este o diagnosticasse utilizando a nossa ferramenta. Em cada diagnóstico anotamos o tempo gasto e demais comentários sobre a metodologia utilizada na depuração. Os tempos medidos são apresentados na tabela a seguir junto com os tempos de depuração de quando as falhas foram descoberta no sistema real. Tabela I TEMPO EM MINUTOS DE DEPURAÇÃO PARA CADA PROBLEMA P1 P2 P3 Desenvolvedor sem introspecção Desenvolvedor Desenvolvedor Administrador Administrador Todos os usuários da ferramenta diagnosticaram as falhas com um tempo inferior ao diagnóstico original realizado por um desenvolvedor sem instrumentação. O resultado superou nossas expectativas e nos surpreendeu verificar que os usuários não-técnicos tiveram uma resposta mais rápida que os desenvolvedores, que conheciam o funcionamento interno do sistema. Concluímos que isso aconteceu devido a dois fatores: (1) estes usuários atuam diretamente no sistema em produção, estando mais próximos das falhas reais, e (2) têm uma visão simplificada do todo por não conhecer detalhes de implementação, gerando um grupo menor de hipóteses sobre possíveis causas do problema e, principalmente, dando foco a elas. Nem sempre isso é interessante, entretanto mostrou-se eficiente para os problemas apresentados neste experimento. As três falhas foram escolhidas de forma que nenhum dos usuários tivesse algum conhecimento privilegiado, seja por ela estar relacionada a uma parte do sistema que eles mesmos codificaram, como por algum contato com a manifestação original da falha no ambiente de produção. Além disso, durante o experimento também tomamos o cuidado de não influenciar os usuários, auxiliando somente na utilização da interface de inspeção. Um efeito colateral deste experimento foi a descoberta de uma série de problemas de IHC, que não pertenciam ao escopo deste trabalho, entretanto serão considerados como um trabalho futuro a fim de reduzir ainda mais o esforço e a taxa de falhas da depuração. V. TRABALHOS RELACIONADOS Existem muitos trabalhos na literatura que abordam o problema de depuração baseada em logs, a maioria com foco na detecção automática de falhas [17] [18] [19] [20] [21] [22] [23], poucos no seu diagnóstico [24] [25] [26]. Em ambos os casos o conteúdo do log costuma ser muito superficial, sendo capturado de arquivos de log genéricos [17] [23], lidos do sistema como uma caixa-preta [21] ou gerados automaticamente [18] [25]. Em geral, estas abordagens não produzem informações suficientes para realizar análises profundas ou selecionar eventos de acordo com o contexto de interesse. Alguns trabalhos baseados em mineração e clusterização de dados [27] [28] procuram solucionar este problema detectando padrões, extraindo propriedades das mensagens e classificando-as, entretanto, o número de propriedades acaba sendo limitado à visibilidade do escopo que as criou. Outra questão é a escolha entre a instrumentação automática e a manual. A instrumentação automática apresenta um custo ínfimo e produz um volume maior de logs, porém a manual é escrita pelo próprio desenvolvedor, logo, acaba sendo direcionada para as informações que este considera mais relevantes. Nosso trabalho procura reduzir estas limitações ao fornecer um mecanismo capaz de transcrever, com pouco esforço, o modelo mental dos desenvolvedores sob a forma de instrumentação. O evento é escrito da forma tradicional, entretanto, ao ser emitido é complementado pelas propriedades presentes na pilha de tags. Observe que esta pilha viabiliza a inserção de propriedades definidas em escopos superiores, mesmo que, devido a modularidade, elas não possam ser acessadas pelo escopo corrente. Sem esta pilha o evento seria gerado somente com as propriedades do escopo local, que são importantes, mas não definem o contexto da execução. Encontramos poucos trabalhos [29] [30] [20] [21] que investem em visualizadores para auxiliar a inspeção manual. Estes trabalhos buscam solucionar o problema do volume de logs condensando os eventos e gerando gráficos estatísticos. Esta solução apresenta bons resultados para detectar e diagnosticar falhas de rede e segurança, entretanto é inadequada para falhas de lógica comportamental do sistema, que é o problema tratado por este trabalho e exige um nível maior de profundidade na inspeção. A nossa abordagem segue na direção contrária, buscando mecanismos para aumentar o detalhamento dos log em vez de simplificá-los. Resolvemos o problema do volume de logs através de filtros seguindo o contexto de interesse do usuário, com um grau de flexibilidade alto na sua definição, viabilizado pelas propriedades inseridas na etapa de instrumentação.

10 VI. CONCLUSÃO Apresentamos neste trabalho um mecanismo de diagnóstico de causa de falhas com foco em sistemas distribuídos. O mecanismo é implementado através de logs em que cada evento é anotado com informações do contexto que foi gerado. Estas informações são representadas como tags, compostas por um nome e, opcionalmente, um valor associado. O conjunto de eventos gerado por cada entidade do sistema é enviado para uma base de dados central. Construímos também uma ferramenta de inspeção para apresentar os eventos do sistema em uma linha temporal unificada, exibindo somente os itens do log completo que forem do interesse do depurador, desta forma reduzindo seu esforço para compreender o comportamento do sistema. Realizamos um estudo de caso sobre um sistema de cardápio digital em que foi medido o esforço para instrumentar o sistema e foi realizado um experimento com um grupo de usuários para avaliar as contribuições do mecanismo apresentado. Os resultados foram excelentes, mostrando que a ferramenta não só reduziu o tempo de depuração como se mostrou apta para ser utilizada por usuários não-técnicos. Este trabalho foi uma etapa de uma pesquisa em sistemas orientados a recuperação e servirá como base para trabalhos futuros de detecção e diagnóstico automático de falhas. Além disso, durante a realização do trabalho identificamos alguns trabalhos futuros: (1) estudar soluções de computação nas nuvens para garantir a escalabilidade da solução, (2) criar um mecanismo para inferir novas tags para eventos a partir de relacionamentos não-explícitos entre eles, (3) evoluir a ferramenta de inspeção para visualizar múltiplos contextos concorrentemente, possivelmente relacionando-os, e (4) estudar como a programação orientada a aspectos pode auxiliar a injeção de tags e notificações de eventos. VII. AGRADECIMENTOS Agradecemos ao CNPq pelos auxílios e bolsas: , , e REFERÊNCIAS [1] C. L. Mendes and D. A. Reed, Monitoring large systems via statistical sampling, Int. J. High Perform. Comput. Appl., vol. 18, pp , [2] D. Patterson, A. Brown, P. Broadwell, G. Candea, M. Chen, J. Cutler, P. Enriquez, A. Fox, E. Kiciman, M. Merzbacher, D. Oppenheimer, N. Sastry, W. Tetzlaff, J. Traupman, and N. Treuhaft, Recovery oriented computing (roc): Motivation, definition, techniques, and case studies, EECS Department, University of California, Berkeley, Tech. Rep. UCB/CSD , Mar [3] A. B. Brown and D. A. Patterson, To err is human, in Proceedings of the First Workshop on Evaluating and Architecting System dependability (EASY 01, [4] A. Fox, Toward recovery-oriented computing, in In VLDB, 2002, pp [5] R. Murch, Autonomic Computing. IBM Press, [6] S.-W. Cheng, A.-C. Huang, D. Garlan, B. Schmerl, and P. Steenkiste, Rainbow: Architecture-based self-adaptation with reusable infrastructure, Autonomic Computing, International Conference on, vol. 0, pp , [7] A. Unruh, J. Bailey, and K. Ramamohanarao, Building more robust multi-agent systems using a log-based approach, Web Intelli. and Agent Sys., vol. 7, pp , January [8] A. Avizienis, Toward systematic design of fault-tolerant systems, Computer, vol. 30, pp , April [9] S. Kumar and P. R. Cohen, Towards a fault-tolerant multi-agent system architecture, in Proceedings of the fourth international conference on Autonomous agents. ACM, 2000, pp [10] L. Mariani, M. PezzÃ, and D. Willmor, Generation of integration tests for self-testing components, in Applying Formal Methods: Testing, Performance and M/ECommerce, FORTE 2004 Workshops The FormEMC, EPEW, ITM, Toledo, Spain, October 1-2, 2004, ser. Lecture Notes in Computer Science, vol Springer, 2004, pp [11] A. von Staa, Programacao Modular. Campus, [12] R. Mitchell and J. McKim, Design by contract, by example, in Proceedings of the 39th International Conference and Exhibition on Technology of Object-Oriented Languages and Systems (TOOLS39). IEEE Computer Society, 2001, p [13] C. Strozzi. (2012, Apr.) Nosql. [Online]. Available: US/nosql [14] Apple. (2012, Apr.) ios. [Online]. Available: [15] A. Holovaty and J. Kaplan-Moss, The Definitive Guide to Django: Web Development Done Right (Pro). Berkely, CA, USA: Apress, [16] Software product lines: practices and patterns. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., [17] S. E. Hansen and E. T. Atkins, Automated system monitoring and notification with swatch, in Proceedings of the 7th USENIX conference on System administration, 1993, pp [18] J. H. Andrews and Y. Zhang, Broad-spectrum studies of log file analysis, in Proceedings of the 22nd International Conference on Software Engineering (ICSE ACM Press, 2000, pp [19] R. Vaarandi, Sec: a lightweight event correlation tool, in IP Operations and Management, 2002 IEEE Workshop on, 2002, pp [20] J. Stearley, Towards informatic analysis of syslogs, in Proceedings of the 2004 IEEE International Conference on Cluster Computing. IEEE Computer Society, 2004, pp [21] P. Bodik, G. Friedman, L. Biewald, H. Levine, G. C, K. Patel, G. Tolle, J. Hui, O. Fox, M. I. Jordan, and D. Patterson, Combining visualization and statistical analysis to improve operator confidence and efficiency for failure detection and localization, in In Proceedings of the 2nd IEEE International Conference on Autonomic Computing (ICAC â05. IEEE Computer Society, 2005, pp [22] L. Mariani and F. Pastore, Automated identification of failure causes in system logs, in Proceedings of the th International Symposium on Software Reliability Engineering. Washington, DC, USA: IEEE Computer Society, 2008, pp [23] K. Thomson, Logsurfer - real time log monitoring and alerting, Mar [24] M. Chen, A. X. Zheng, J. Lloyd, M. I. Jordan, and E. Brewer, Failure diagnosis using decision trees, in In Proceedings of the International Conference on Autonomic Computing (ICAC, 2004, pp [25] P. Reynolds, C. Killian, J. L. Wiener, J. C. Mogul, M. A. Shah, and A. Vahdat, Pip: detecting the unexpected in distributed systems, in Proceedings of the 3rd conference on Networked Systems Design & Implementation - Volume 3, ser. NSDI 06. Berkeley, CA, USA: USENIX Association, 2006, pp [26] D. Geels, G. Altekar, P. Maniatis, T. Roscoe, and I. Stoica, Friday: global comprehension for distributed replay, in Proceedings of the 4th USENIX conference on Networked systems design; implementation, ser. NSDI 07. USENIX Association, 2007, pp [27] J. L. Hellerstein, S. Ma, and C.-S. Perng, Discovering actionable patterns in event data, IBM Syst. J., vol. 41, pp , [28] R. Vaarandi, A data clustering algorithm for mining patterns from event logs, in in IEEE IPOMâ03 Proceedings, 2003, pp [29] T. Takada and H. Koide, Mielog: A highly interactive visual log browser using information visualization and statistical analysis, in Proceedings of the 16th USENIX conference on System administration. Berkeley, CA, USA: USENIX Association, 2002, pp [30] T. Takada and H. Koike, Tudumi: Information visualization system for monitoring and auditing computer logs. in IV, 2002, pp

APRENDENDO LÓGICA DE PROGRAMAÇÃO VIA WEB

APRENDENDO LÓGICA DE PROGRAMAÇÃO VIA WEB APRENDENDO LÓGICA DE PROGRAMAÇÃO VIA WEB Romero Tori Universidade de São Paulo Escola Politécnica INTERLAB Laboratório de Tecnologias Interativas-USP Instituto Sumaré de Educação Superior rometori@usp.br

Leia mais

Falha benigna. Sistema. Sistema Próprio. Interrompido. Restauração. Falha catastrófica. Falha catastrófica. Sistema. Impróprio

Falha benigna. Sistema. Sistema Próprio. Interrompido. Restauração. Falha catastrófica. Falha catastrófica. Sistema. Impróprio INE 5418 Segurança de Funcionamento Tipos de s Detecção de s Recuperação de s Segurança de Funcionamento Representa a confiança depositada em um determinado sistema em relação ao seu correto funcionamento

Leia mais

Notas da Aula 4 - Fundamentos de Sistemas Operacionais

Notas da Aula 4 - Fundamentos de Sistemas Operacionais Notas da Aula 4 - Fundamentos de Sistemas Operacionais 1. Threads Threads são linhas de execução dentro de um processo. Quando um processo é criado, ele tem uma única linha de execução, ou thread. Esta

Leia mais

Resumo. Introdução Classificação Fases Curiosidades

Resumo. Introdução Classificação Fases Curiosidades Tolerância à falha Resumo Introdução Classificação Fases Curiosidades Introdução Sistemas Tolerantes a Falhas são aqueles que possuem a capacidade de continuar provendo corretamente os seus serviços mesmo

Leia mais

SGBD x Disponibilidade

SGBD x Disponibilidade SGBD x Disponibilidade Objetivo Escopo Motivação Conceitos básicos Disponibilidade Redundância de software Redundância de hardware 1 Objetivo: Objetivo Discutir tecnologias e práticas operacionais utilizadas

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Faculdades SENAC Análise e Desenvolvimento de Sistemas 1 de agosto de 2009 Conceitos Conança de Funcionamento (Dependability) Representa a conança depositada em um determinado sistema em relação ao seu

Leia mais

Anderson Corrêa Carraro 1, Fernando Alves Rodrigues 2, Silvio Francisco dos Santos 3

Anderson Corrêa Carraro 1, Fernando Alves Rodrigues 2, Silvio Francisco dos Santos 3 DESENVOLVIMENTO E IMPLANTAÇÃO DE UM SISTEMA INFORMATIZADO PARA O CONTROLE DE PROCESSOS DA QUALIDADE NA DIRETORIA DE METROLOGIA CIENTÍFICA E INDUSTRIAL DIMCI/INMETRO. Anderson Corrêa Carraro 1, Fernando

Leia mais

Computação Sensível ao Contexto

Computação Sensível ao Contexto Computação Sensível ao Contexto Percepção de Contexto em Ambientes Domiciliares Modelagem de Contexto Modelagem de Contexto + Modelagem de Usuário Fabrício J. Barth novembro de 2004 Sumário O que já foi

Leia mais

Teste de software. Definição

Teste de software. Definição Definição O teste é destinado a mostrar que um programa faz o que é proposto a fazer e para descobrir os defeitos do programa antes do uso. Quando se testa o software, o programa é executado usando dados

Leia mais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais Notas da Aula 15 - Fundamentos de Sistemas Operacionais 1. Software de Entrada e Saída: Visão Geral Uma das tarefas do Sistema Operacional é simplificar o acesso aos dispositivos de hardware pelos processos

Leia mais

Teste Funcional 3. Arndt von Staa Departamento de Informática PUC-Rio Março 2015

Teste Funcional 3. Arndt von Staa Departamento de Informática PUC-Rio Março 2015 Teste Funcional 3 Arndt von Staa Departamento de Informática PUC-Rio Março 2015 Especificação Objetivo desse módulo Apresentar uma modalidade de geração de casos de teste a partir de casos de uso Justificativa

Leia mais

Table 1. Dados do trabalho

Table 1. Dados do trabalho Título: Desenvolvimento de geradores de aplicação configuráveis por linguagens de padrões Aluno: Edison Kicho Shimabukuro Junior Orientador: Prof. Dr. Paulo Cesar Masiero Co-Orientadora: Prof a. Dr. Rosana

Leia mais

Microsoft System Center Operations Manager 2007

Microsoft System Center Operations Manager 2007 Microsoft System Center Operations Manager 2007 Visão Geral Microsoft Corporation Publicado: 18 de dezembro de 2006 Atualizado: 5 de abril de 2007 Sumário Executivo O System Center Operations Manager 2007

Leia mais

4 Conversor EDTV Raw. 4.1 Arquitetura

4 Conversor EDTV Raw. 4.1 Arquitetura 4 Conversor EDTV Raw O conversor EDTV Raw é o programa que lê um documento escrito no perfil NCL EDTV e gera um documento Raw equivalente, i.e. que define a mesma apresentação. Este capítulo, apresenta

Leia mais

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários.

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários. Os sistemas computacionais atuais permitem que diversos programas sejam carregados na memória e executados simultaneamente. Essa evolução tornou necessário um controle maior na divisão de tarefas entre

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br Centro Universitário de Volta Redonda - UniFOA Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro

Leia mais

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP) Hardware (Nível 0) Organização O AS/400 isola os usuários das características do hardware através de uma arquitetura de camadas. Vários modelos da família AS/400 de computadores de médio porte estão disponíveis,

Leia mais

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula 6 - ALGORÍTIMOS PARALELOS MPI - Parallel Virtual Machine e PVM - Parallel Virtual Machine 1. INTRODUÇÃO Inicialmente é necessário conceber alguns conceitos para entendimento dos algoritmos paralelos:

Leia mais

Gestão de Configurações II

Gestão de Configurações II Gestão de Configurações II Bibliografia Livro: Software Configuration Management Patterns: Effective Teamwork, Practical Integration Gestão de Projecto 14 Padrões de Gestão Os padrões de gestão de configurações

Leia mais

Arquitetura de Software e Atributos de Qualidade

Arquitetura de Software e Atributos de Qualidade Arquitetura de Software e Atributos de Qualidade Jair C Leite Requisitos e atributos de qualidade Requisitos Características, atributos, propriedades e restrições associadas ao software. Requisitos funcionais

Leia mais

Engenharia Reversa para Recuperação de Modelos de Sistemas Desenvolvidos em PL/SQL

Engenharia Reversa para Recuperação de Modelos de Sistemas Desenvolvidos em PL/SQL Engenharia Reversa para Recuperação de Modelos de Sistemas Desenvolvidos em PL/SQL Rodnei Couto 1, Luana Lachtermacher 1, Soeli Fiorini 1, Akeo Tanabe 1, Gustavo Carvalho 1, Arndt von Staa 1, Ricardo Choren

Leia mais

INTRODUÇÃO. A SKA preparou este documento técnico com o objetivo de auxiliar seus clientes a realizar a instalação do SolidWorks 2009.

INTRODUÇÃO. A SKA preparou este documento técnico com o objetivo de auxiliar seus clientes a realizar a instalação do SolidWorks 2009. Guia de Instalação do SolidWorks 2009 INTRODUÇÃO A SKA preparou este documento técnico com o objetivo de auxiliar seus clientes a realizar a instalação do SolidWorks 2009. O SolidWorks pode ser instalado

Leia mais

Análise do impacto de operações de live migration em ambientes de computação em nuvem Workshop MoDCS 2012.2

Análise do impacto de operações de live migration em ambientes de computação em nuvem Workshop MoDCS 2012.2 Análise do impacto de operações de live migration em ambientes de computação em nuvem Workshop MoDCS 2012.2 Matheus D'Eça Torquato de Melo (mdetm@cin.ufpe.br) Paulo Maciel (prmm@cin.ufpe.br) 12 Roteiro

Leia mais

CA Nimsoft Monitor. Guia do Probe Inspetor de serviços do Windows. ntservices série 3.1

CA Nimsoft Monitor. Guia do Probe Inspetor de serviços do Windows. ntservices série 3.1 CA Nimsoft Monitor Guia do Probe Inspetor de serviços do Windows ntservices série 3.1 Aviso de copyright do CA Nimsoft Monitor Este sistema de ajuda online (o Sistema ) destina-se somente para fins informativos

Leia mais

MANUAL DE INSTALAÇÃO ADMINISTRAÇÃO DE TOKEN SAFESIGN

MANUAL DE INSTALAÇÃO ADMINISTRAÇÃO DE TOKEN SAFESIGN MANUAL DE INSTALAÇÃO E ADMINISTRAÇÃO DE TOKEN SAFESIGN Manual de utilização do software de gerenciamento SafeSign Índice 1. Instalação... 3 1.1. Instalação no Windows... 3 1.2. Verificar versão do aplicativo...

Leia mais

Modelo de Controle de Acesso para uma Arquitetura Orientada a Serviços Visando a Integração de Aplicações de Comando e Controle

Modelo de Controle de Acesso para uma Arquitetura Orientada a Serviços Visando a Integração de Aplicações de Comando e Controle Modelo de Controle de Acesso para uma Arquitetura Orientada a Serviços Visando a Integração de Aplicações de Comando e Controle Márcio Araújo Varchavsky, Eduardo Martins Guerra, Clóvis Torres Fernandes

Leia mais

HP Quality Center. Preparar materiais de treinamento e observações para a nova versão 16 Suporte pós-atualização 16 Suporte 17 Chamada à ação 17

HP Quality Center. Preparar materiais de treinamento e observações para a nova versão 16 Suporte pós-atualização 16 Suporte 17 Chamada à ação 17 Documento técnico HP Quality Center Atualize o desempenho Índice Sobre a atualização do HP Quality Center 2 Introdução 2 Público-alvo 2 Definição 3 Determine a necessidade de uma atualização do HP Quality

Leia mais

Gestão da qualidade do software

Gestão da qualidade do software Gestão da qualidade do software Empenhada em assegurar que o nível de qualidade requerido de um produto de software é atingido Envolve a definição de normas e procedimentos de qualidade apropriados, e

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

For-All - Uma Plataforma para Sistemas Pervasivos Orientados a Serviço

For-All - Uma Plataforma para Sistemas Pervasivos Orientados a Serviço For-All - Uma Plataforma para Sistemas Pervasivos Orientados a Serviço Elenilson Vieira da S. Filho 1, Ângelo L. Vidal de Negreiros 1, Alisson V. Brito 2 1 Departamento de Informática Universidade Federal

Leia mais

O que é a UML? Introdução a UML. Objetivos da Modelagem. Modelos. A UML não é. Princípios da Modelagem. O que é um modelo?

O que é a UML? Introdução a UML. Objetivos da Modelagem. Modelos. A UML não é. Princípios da Modelagem. O que é um modelo? O que é a UML? Introdução a UML Linguagem Gráfica de Modelagem para: Visualizar Especificar Construir Documentar Comunicar Artefatos de sistemas complexos Linguagem: vocabulário + regras de combinação

Leia mais

Proposta para Grupo de Trabalho. GT-Computação em Nuvem para Ciência: Armazenamento de Dados. Roberto Samarone dos Santos Araujo

Proposta para Grupo de Trabalho. GT-Computação em Nuvem para Ciência: Armazenamento de Dados. Roberto Samarone dos Santos Araujo Proposta para Grupo de Trabalho GT-Computação em Nuvem para Ciência: Armazenamento de Dados Roberto Samarone dos Santos Araujo Agosto/2011 1 Título GT-Computação em Nuvem para Ciência: Armazenamento de

Leia mais

Frameworks. Pasteur Ottoni de Miranda Junior

Frameworks. Pasteur Ottoni de Miranda Junior Frameworks Pasteur Ottoni de Miranda Junior 1-Definição Apesar do avanço das técnicas de desenvolvimento de software, a construção de software ainda é um processo extremamente complexo.a reutilização tem

Leia mais

Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos

Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos Francisco José da Silva e Silva Laboratório de Sistemas Distribuídos (LSD) Departamento de Informática / UFMA http://www.lsd.deinf.ufma.br

Leia mais

Configuração SERVIDOR.

Configuração SERVIDOR. REQUISITOS MINIMOS SISTEMAS FORTES INFORMÁTICA. Versão 2.0 1. PRE-REQUISITOS FUNCIONAIS HARDWARES E SOFTWARES. 1.1 ANALISE DE HARDWARE Configuração SERVIDOR. Componentes Mínimo Recomendado Padrão Adotado

Leia mais

Developers Magazine http://www.developers.com.br

Developers Magazine http://www.developers.com.br Developers Magazine http://www.developers.com.br Edição 54, Fevereiro de 2001. Mobilidade na Segurança Corporativa A Aliança dos Agentes Móveis e Tecnologias de Segurança Contra os Crackers Francisco Gomes

Leia mais

XDR. Solução para Big Data.

XDR. Solução para Big Data. XDR Solução para Big Data. ObJetivo Principal O volume de informações com os quais as empresas de telecomunicações/internet têm que lidar é muito grande, e está em constante crescimento devido à franca

Leia mais

CIBM. IBM SmartCloud Entry. Guia do Usuário - Versão 2.2

CIBM. IBM SmartCloud Entry. Guia do Usuário - Versão 2.2 CIBM Guia do Usuário - Versão 2.2 Esta edição aplica-se à versão 2, release 2, modificação 0 do (número do produto 5765-SKC) e a todos os releases e modificações subsequentes, até que seja indicado de

Leia mais

Avaya Virtualization Provisioning Service

Avaya Virtualization Provisioning Service Avaya Virtualization Provisioning Service Uma solução que fornece visibilidade, validação, automatização e geração de relatórios ao longo dos diferentes servidores, aplicações e dispositivos de rede para

Leia mais

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS Lilian R. M. Paiva, Luciene C. Oliveira, Mariana D. Justino, Mateus S. Silva, Mylene L. Rodrigues Engenharia de Computação - Universidade de Uberaba (UNIUBE)

Leia mais

Banco de Dados. Uma coleção de dados relacionados [ELMASRI/NAVATHE]

Banco de Dados. Uma coleção de dados relacionados [ELMASRI/NAVATHE] 1/6 Banco de Dados O que é um Banco de Dados? Uma coleção de dados relacionados [ELMASRI/NAVATHE] Conjunto de dados integrados que tem por objetivo atender a uma comunidade específica [HEUSER] Um conjunto

Leia mais

2 Auto-sintonia de Bancos de Dados e Agentes de Software

2 Auto-sintonia de Bancos de Dados e Agentes de Software 2 Auto-sintonia de Bancos de Dados e Agentes de Software A uso da abordagem de agentes de software 1 pode trazer benefícios a áreas de aplicação em que é necessário construir sistemas autônomos, ou seja,

Leia mais

Um Arcabouço open source em Python para DBC com

Um Arcabouço open source em Python para DBC com Um Arcabouço open source em Python para DBC com Suporte à Evolução Dinâmica não Antecipada Yguaratã C. Cavacanti 1, Hyggo Oliveira de Almeida 1, Evandro Costa 2 1 Instituto de Computação Universidade Federal

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Capítulo 3 Processos de Software Slides do Livro do Sommerville, 2000 Disponíveis em inglês em www.software-engin.com Traduzidos por Jacinta Pereira Graduando do Curso de Letras

Leia mais

Arquitetura de Software. Silvia Regina Vergilio

Arquitetura de Software. Silvia Regina Vergilio Arquitetura de Software Silvia Regina Vergilio Atividades de Projeto Projeto Geral ou Preliminar: fase que traduz a especificação do sistema em termos da arquitetura de dados e de módulos. Descreve a organização

Leia mais

Importância da Arquitetura de Sistemas Baseados em Componentes para os Testes por Injeção de Falhas

Importância da Arquitetura de Sistemas Baseados em Componentes para os Testes por Injeção de Falhas Importância da Arquitetura de Sistemas Baseados em Componentes para os Testes por Injeção de Falhas Regina Lúcia de Oliveira Moraes Universidade Estadual de Campinas (UNICAMP) Centro Superior de Educação

Leia mais

Capítulo 25. Gerenciamento de Configuração. Engenharia de Software Prof. Flávio de Oliveira Silva, Ph.D.

Capítulo 25. Gerenciamento de Configuração. Engenharia de Software Prof. Flávio de Oliveira Silva, Ph.D. Capítulo 25 Gerenciamento de Configuração slide 624 2011 Pearson Prentice Hall. Todos os direitos reservados. Tópicos abordados Gerenciamento de mudanças Gerenciamento de versões Construção de sistemas

Leia mais

Volume ACRONUS SOFTWARE GUIA DE UTILIZAÇÃO DO ACRONUS SYSTEM. Manual Técnico 4.28

Volume ACRONUS SOFTWARE GUIA DE UTILIZAÇÃO DO ACRONUS SYSTEM. Manual Técnico 4.28 Volume 1 ACRONUS SOFTWARE GUIA DE UTILIZAÇÃO DO ACRONUS SYSTEM Manual Técnico 4.28 P A C O T E I N S T I T U I Ç Õ E S D E E N S I N 0 - E M P R E S A S Manual Técnico 4.28 ACRONUS SOFTWARE 08.104.732/0001-33

Leia mais

EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE

EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE UNIVERSIDADE CATÓLICA DE PELOTAS CENTRO POLITÉCNICO TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS EIMOBILE INSTITUIÇÕES DE ENSINO MOBILE por Miguel Aguiar Barbosa Trabalho de curso II submetido como

Leia mais

Programação Modular. Alessandro Garcia. DI/PUC-Rio Março 2013

Programação Modular. Alessandro Garcia. DI/PUC-Rio Março 2013 Programação Modular Alessandro Garcia DI/PUC-Rio Março 2013 Programação Modular Quem sou eu? Quem são vocês? Qual é o problema abordado no curso? Qual é o objetivo do curso Organização: aulas, avaliação

Leia mais

NOMES: Leonardo Claro Diego Lage Charles Tancredo Márcio Castro

NOMES: Leonardo Claro Diego Lage Charles Tancredo Márcio Castro NOMES: Leonardo Claro Diego Lage Charles Tancredo Márcio Castro O MySQL Cluster é versão do MySQL adaptada para um ambiente de computação distribuída, provendo alta disponibilidade e alta redundância utilizando

Leia mais

VoIPFix: Uma ferramenta para análise e detecção de falhas em sistemas de telefonia IP

VoIPFix: Uma ferramenta para análise e detecção de falhas em sistemas de telefonia IP XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos 915 VoIPFix: Uma ferramenta para análise e detecção de falhas em sistemas de telefonia IP Paulo C. Siécola 1, Fabio Kon 1 1 Departamento

Leia mais

GUIDE Instagram e Hootsuite. Guia de Início Rápido

GUIDE Instagram e Hootsuite. Guia de Início Rápido GUIDE Instagram e Hootsuite Guia de Início Rápido Instagram e Hootsuite Guia de Início Rápido Com 300 milhões de usuários ativos por mês, o Instagram pode abrir um mundo de oportunidades para o seu negócio.

Leia mais

Consultar Tabelas Administrativas

Consultar Tabelas Administrativas STN Coordenação-Geral de Sistemas e Tecnologia de Informação Sistema Integrado de Administração Financeira do Governo Federal SIAFI Secretaria do Tesouro Nacional STN Documentação de Serviços de Interoperabilidade

Leia mais

6 Infraestrutura de Trabalho

6 Infraestrutura de Trabalho 6 Infraestrutura de Trabalho Este capítulo tem como objetivo fornecer uma visão geral do ambiente de trabalho encontrado na organização estudada, bem como confrontá-lo com a organização ideal tal como

Leia mais

Sistemas Distribuídos: Conceitos e Projeto Estilos Arquitetônicos e Arquitetura Cliente/Servidor

Sistemas Distribuídos: Conceitos e Projeto Estilos Arquitetônicos e Arquitetura Cliente/Servidor Sistemas Distribuídos: Conceitos e Projeto Estilos Arquitetônicos e Arquitetura Cliente/Servidor Francisco José da Silva e Silva Laboratório de Sistemas Distribuídos (LSD) Departamento de Informática /

Leia mais

Utilização do aplicativo ODK como suporte na inspeção de Via Permanente

Utilização do aplicativo ODK como suporte na inspeção de Via Permanente Utilização do aplicativo ODK como suporte na inspeção de Via Permanente Eric Pretti Serafim 1 * 1 VALES/A. Rod. BR155, s/n, Pátio Ferroviário de Marabá, 68508-970, Marabá - Pará e-mail: eric.pretti@vale.com

Leia mais

UTFPR - Sistemas Distribuídos Prof. Cesar Augusto Tacla. Anotações. Copyright Cesar Augusto Tacla 2008 - 1 -

UTFPR - Sistemas Distribuídos Prof. Cesar Augusto Tacla. Anotações. Copyright Cesar Augusto Tacla 2008 - 1 - - 1 - - 2 - - 3 - Segundo (Garg, 2004), são sistemas compostos por múltiplos processadores conectados por uma rede de comunicação, sendo a rede de comunicação uma LAN (Ethernet) ou WAN (Internet). - 4

Leia mais

PLATAFORMA URBANMOB Aplicativo para captura de trajetórias urbanas de objetos móveis

PLATAFORMA URBANMOB Aplicativo para captura de trajetórias urbanas de objetos móveis PLATAFORMA URBANMOB Aplicativo para captura de trajetórias urbanas de objetos móveis Gabriel Galvão da Gama 1 ; Reginaldo Rubens da Silva 2 ; Angelo Augusto Frozza 3 RESUMO Este artigo descreve um projeto

Leia mais

Planejamento Estratégico de TI. Prof.: Fernando Ascani

Planejamento Estratégico de TI. Prof.: Fernando Ascani Planejamento Estratégico de TI Prof.: Fernando Ascani Data Warehouse - Conceitos Hoje em dia uma organização precisa utilizar toda informação disponível para criar e manter vantagem competitiva. Sai na

Leia mais

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider Ferramenta: Spider-CL Manual do Usuário Versão da Ferramenta: 1.1 www.ufpa.br/spider Histórico de Revisões Data Versão Descrição Autor 14/07/2009 1.0 15/07/2009 1.1 16/07/2009 1.2 20/05/2010 1.3 Preenchimento

Leia mais

Gerenciamento de Rede Baseado em Políticas

Gerenciamento de Rede Baseado em Políticas Gerenciamento de Rede Baseado em Políticas (Policy-Based Networking) Ademir José de Carvalho Junior Recife, Fevereiro de 2007 Resumo: A complexidade das redes baseadas em IP atualmente segue crescendo

Leia mais

7 Utilização do Mobile Social Gateway

7 Utilização do Mobile Social Gateway 7 Utilização do Mobile Social Gateway Existem três atores envolvidos na arquitetura do Mobile Social Gateway: desenvolvedor do framework MoSoGw: é o responsável pelo desenvolvimento de novas features,

Leia mais

Uma Análise da História do VEM, WBVS e WMSWM

Uma Análise da História do VEM, WBVS e WMSWM VEM Uma Análise da História do VEM, WBVS e WMSWM Renato Novais, Thiago S. Mendes, Fernando Teles Instituto Federal da Bahia (IFBA) Salvador Bahia Brasil {renato,thiagosouto,fernandoteles}@ifba.edu.br Abstract.

Leia mais

Instalação do IBM SPSS Modeler Server Adapter

Instalação do IBM SPSS Modeler Server Adapter Instalação do IBM SPSS Modeler Server Adapter Índice Instalação do IBM SPSS Modeler Server Adapter............... 1 Sobre a Instalação do IBM SPSS Modeler Server Adapter................ 1 Requisitos de

Leia mais

Requisitos de Ferramentas Especializadas de Gestão de Configuração de Software

Requisitos de Ferramentas Especializadas de Gestão de Configuração de Software Requisitos de Ferramentas Especializadas de Gestão de Configuração de Software Ricardo Terra 1 1 Departamento de Ciência da Computação Universidade Federal de Minas Gerais (UFMG) Campus da Pampulha 31.270-010

Leia mais

Thin Clients : aumentando o potencial dos sistemas SCADA

Thin Clients : aumentando o potencial dos sistemas SCADA Artigos Técnicos Thin Clients : aumentando o potencial dos sistemas SCADA Tarcísio Romero de Oliveira, Engenheiro de Vendas e Aplicações da Intellution/Aquarius Automação Industrial Ltda. Um diagnóstico

Leia mais

MARACATU. A component search tool. Especificação, Projeto e Implementação de uma Arquitetura para um Engenho de Busca de Componentes

MARACATU. A component search tool. Especificação, Projeto e Implementação de uma Arquitetura para um Engenho de Busca de Componentes MARACATU A component search tool Especificação, Projeto e Implementação de uma Arquitetura para um Engenho de Busca de Componentes Vinicius Cardoso Garcia July 29, 2005 Agenda Introdução Especificação

Leia mais

Aula 02: Conceitos Fundamentais

Aula 02: Conceitos Fundamentais Aula 02: Conceitos Fundamentais Profa. Ms. Rosângela da Silva Nunes 1 de 26 Roteiro 1. Por que mineração de dados 2. O que é Mineração de dados 3. Processo 4. Que tipo de dados podem ser minerados 5. Que

Leia mais

SISTEMA DE GERÊNCIA - DmView

SISTEMA DE GERÊNCIA - DmView Sistema de Gerenciamento DmView O DmView é o Sistema de Gerência desenvolvido para supervisionar e configurar os equipamentos DATACOM, disponibilizando funções para gerência de supervisão, falhas, configuração,

Leia mais

ITIL. Conteúdo. 1. Introdução. 2. Suporte de Serviços. 3. Entrega de Serviços. 4. CobIT X ITIL. 5. Considerações Finais

ITIL. Conteúdo. 1. Introdução. 2. Suporte de Serviços. 3. Entrega de Serviços. 4. CobIT X ITIL. 5. Considerações Finais ITIL Conteúdo 1. Introdução 2. Suporte de Serviços 3. Entrega de Serviços 4. CobIT X ITIL 5. Considerações Finais Introdução Introdução Information Technology Infrastructure Library O ITIL foi desenvolvido,

Leia mais

Administração de Banco de Dados

Administração de Banco de Dados Administração de Banco de Dados Professora conteudista: Cida Atum Sumário Administração de Banco de Dados Unidade I 1 INTRODUÇÃO A BANCO DE DADOS...1 1.1 Histórico...1 1.2 Definições...2 1.3 Importância

Leia mais

INTRODUÇÃO. A SKA preparou este documento técnico com o objetivo de auxiliar seus clientes a realizar a instalação do SolidWorks 2010.

INTRODUÇÃO. A SKA preparou este documento técnico com o objetivo de auxiliar seus clientes a realizar a instalação do SolidWorks 2010. Guia de Instalação do SolidWorks 2010 INTRODUÇÃO A SKA preparou este documento técnico com o objetivo de auxiliar seus clientes a realizar a instalação do SolidWorks 2010. O SolidWorks pode ser instalado

Leia mais

3.1 Baseado em operações

3.1 Baseado em operações 23 3. Estado da Arte Algumas das ferramentas de controle de versão comerciais mais conhecidas atualmente são: Concurrent Version System (CVS) [CEDERQVIST, 1993], Microsoft Visual SourceSafe (MVSS) [MICROSOFT,

Leia mais

2 Gerenciamento de Log 2.1 Definições básicas

2 Gerenciamento de Log 2.1 Definições básicas 2 Gerenciamento de Log 2.1 Definições básicas Os logs são fontes riquíssimas de informação e são gerados pelos servidores e pelas aplicações conforme eventos significativos acontecem. Em [1], log é definido

Leia mais

Teste de Software I Conceitos e Estratégias

Teste de Software I Conceitos e Estratégias Tema da Aula Teste de I Conceitos e Estratégias Prof. Cristiano R R Portella portella@widesoft.com.br Conceitos Teste e Garantia de Qualidade Importância do Teste, segundo Deutsch: O desenvolvimento de

Leia mais

CAD Trabalho III. PThreads e OpenMP. Pedro Carvalho de Oliveira Rui André Ponte Costa

CAD Trabalho III. PThreads e OpenMP. Pedro Carvalho de Oliveira Rui André Ponte Costa Universidade de Coimbra Faculdade de Ciências e Tecnologia Departamento de Engenharia Informática CAD Trabalho III PThreads e OpenMP Pedro Carvalho de Oliveira Rui André Ponte Costa Maio 2008 Resumo Neste

Leia mais

CA Nimsoft Monitor. Guia do Probe Monitoramento de conectividade de rede. net_connect série 3.0

CA Nimsoft Monitor. Guia do Probe Monitoramento de conectividade de rede. net_connect série 3.0 CA Nimsoft Monitor Guia do Probe Monitoramento de conectividade de rede net_connect série 3.0 Aviso de copyright do CA Nimsoft Monitor Este sistema de ajuda online (o Sistema ) destina-se somente para

Leia mais

L04 Visualização:FactoryTalk View Site Edition v8.0 FactoryTalk View Site Edition Lab

L04 Visualização:FactoryTalk View Site Edition v8.0 FactoryTalk View Site Edition Lab L04 Visualização:FactoryTalk View Site Edition v8.0 FactoryTalk View Site Edition Lab Felipe Ribeiro / Paulo Rocha Domain Experts - Arquitetura e Software Maio/2015 PUBLIC PUBLIC - 5058-CO900G Copyright

Leia mais

Gerenciador Financeiro CITi. Gerenciador Financeiro CITi

Gerenciador Financeiro CITi. Gerenciador Financeiro CITi (Sistema de Gerenciamento Financeiro) Especificação dos Requisitos do Software Gerenciador Financeiro CITi Versão 1.0 Autores: Bruno Medeiros de Oliveira Igor Rafael Medeiros Pedro Araújo de Melo Tiago

Leia mais

Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow

Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow Itana M. S. Gimenes 1 itana@din.uem.br Fabrício R. Lazilha 2 fabricio@cesumar.br Edson A. O. Junior

Leia mais

Introdução a Banco de Dados

Introdução a Banco de Dados Introdução a Banco de Dados O modelo relacional Marta Mattoso Sumário Introdução Motivação Serviços de um SGBD O Modelo Relacional As aplicações não convencionais O Modelo Orientado a Objetos Considerações

Leia mais

Versão 1.0 Janeiro de 2011. Xerox Phaser 3635MFP Plataforma de interface extensível

Versão 1.0 Janeiro de 2011. Xerox Phaser 3635MFP Plataforma de interface extensível Versão 1.0 Janeiro de 2011 Xerox Phaser 3635MFP 2011 Xerox Corporation. XEROX e XEROX e Design são marcas da Xerox Corporation nos Estados Unidos e/ou em outros países. São feitas alterações periodicamente

Leia mais

INTERNET HOST CONNECTOR

INTERNET HOST CONNECTOR INTERNET HOST CONNECTOR INTERNET HOST CONNECTOR IHC: INTEGRAÇÃO TOTAL COM PRESERVAÇÃO DE INVESTIMENTOS Ao longo das últimas décadas, as organizações investiram milhões de reais em sistemas e aplicativos

Leia mais

Conceitos Básicos e Implementação. Entrega de Serviços. Professor Gledson Pompeu (gledson.pompeu@gmail.com)

Conceitos Básicos e Implementação. Entrega de Serviços. Professor Gledson Pompeu (gledson.pompeu@gmail.com) Conceitos Básicos e Implementação Pref. Mun. Vitória 2007 Analista de Suporte 120 A ITIL (information technology infrastructure library) visa documentar as melhores práticas na gerência, no suporte e na

Leia mais

COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP

COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP Cleber de F. Ferreira¹, Roberto Dias Mota¹. ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil cleberferreirasi@hotmail.com, motaroberto@hotmail.com Resumo.

Leia mais

GUILHERME STUTZ TÖWS ANIMAÇÃO DE ALGORITMOS

GUILHERME STUTZ TÖWS ANIMAÇÃO DE ALGORITMOS GUILHERME STUTZ TÖWS ANIMAÇÃO DE ALGORITMOS Trabalho de graduação do Curso de Ciência da Computação do Setor de Ciências Exatas da Universidade Federal do Paraná. Professor: André Luiz Pires Guedes CURITIBA

Leia mais

Detecção e investigação de ameaças avançadas. VISÃO GERAL

Detecção e investigação de ameaças avançadas. VISÃO GERAL Detecção e investigação de ameaças avançadas. VISÃO GERAL DESTAQUES Introdução ao RSA Security Analytics, que oferece: Monitoramento da segurança Investigação de incidente Geração de relatórios de conformidade

Leia mais

Dell Server PRO Management Pack 4.0 para o Microsoft System Center Virtual Machine Manager Guia de instalação

Dell Server PRO Management Pack 4.0 para o Microsoft System Center Virtual Machine Manager Guia de instalação Dell Server PRO Management Pack 4.0 para o Microsoft System Center Virtual Machine Manager Guia de instalação Notas, avisos e advertências NOTA: uma NOTA indica informações importantes que ajudam você

Leia mais

CA Nimsoft Monitor Snap

CA Nimsoft Monitor Snap CA Nimsoft Monitor Snap Guia de Configuração do Monitoramento de conectividade de rede net_connect série 2.9 Aviso de copyright do CA Nimsoft Monitor Snap Este sistema de ajuda online (o Sistema ) destina-se

Leia mais

Sr. Nimbus DBA Remoto

Sr. Nimbus DBA Remoto Sr. Nimbus DBA Remoto O serviço DBA Remoto da Sr. Nimbus oferece ao cliente uma melhor estruturação e otimização do seu ambiente de plataforma de gerenciamento de dados baseado no Microsoft SQL Server.

Leia mais

Sistema de Automação Comercial de Pedidos

Sistema de Automação Comercial de Pedidos Termo de Abertura Sistema de Automação Comercial de Pedidos Cabana - Versão 1.0 Iteração 1.0- Release 1.0 Versão do Documento: 1.5 Histórico de Revisão Data Versão do Documento Descrição Autor 18/03/2011

Leia mais

SISTEMAS DISTRIBUÍDOS

SISTEMAS DISTRIBUÍDOS SISTEMAS DISTRIBUÍDOS Capítulo 1 Introdução Material de suporte às aulas de Sistemas Distribuídos de Nuno Preguiça Copyright DI FCT/ UNL / 1 NOTA PRÉVIA A apresentação utiliza algumas das figuras do livro

Leia mais

Documentação do Sistema de Reserva de Salas da Intranet do ICMC-USP

Documentação do Sistema de Reserva de Salas da Intranet do ICMC-USP UNIVERSIDADE DE SÃO PAULO Instituto de Ciências Matemáticas e de Computação Departamento de Ciências da Computação e Estatística Documentação do Sistema de Reserva de Salas da Intranet do ICMC-USP André

Leia mais

Especificação Técnica

Especificação Técnica Especificação Técnica Última atualização em 31 de março de 2010 Plataformas Suportadas Agente: Windows XP e superiores. Customização de pacotes de instalação (endereços de rede e dados de autenticação).

Leia mais

Processos (Threads,Virtualização e Migração de Código)

Processos (Threads,Virtualização e Migração de Código) Processos (Threads,Virtualização e Migração de Código) Roteiro Processos Threads Virtualização Migração de Código O que é um processo?! Processos são programas em execução. Processo Processo Processo tem

Leia mais

CONTRA CONTROLE DE ACESSOS E MODULARIZADOR DE SISTEMAS

CONTRA CONTROLE DE ACESSOS E MODULARIZADOR DE SISTEMAS MINISTÉRIO DO DESENVOLVIMENTO AGRÁRIO SUBSECRETARIA DE PLANEJAMENTO, ORÇAMENTO E ADMINISTRAÇÃO COORDENAÇÃO-GERAL DE MODERNIZAÇÃO E INFORMÁTICA CONTRA CONTROLE DE ACESSOS E MODULARIZADOR DE SISTEMAS MANUAL

Leia mais

Sistemas Operacionais Carlos Eduardo Portela Serra de Castro

Sistemas Operacionais Carlos Eduardo Portela Serra de Castro Introdução Sistemas Operacionais 1 Sistema Operacional: Um conjunto de programas, executado pelo computador como os outros programas. Função: Controlar o funcionamento do computador, disponibilizando seus

Leia mais