ECON: MONITORAMENTO DE EVENTOS DE CADEIAS DE PROCESSOS PRODUTIVOS AUTOMOTIVOS UTILIZANDO WEB SERVICES

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

Download "ECON: MONITORAMENTO DE EVENTOS DE CADEIAS DE PROCESSOS PRODUTIVOS AUTOMOTIVOS UTILIZANDO WEB SERVICES"

Transcrição

1 UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIA DA COMPUTAÇÃO BACHARELADO ECON: MONITORAMENTO DE EVENTOS DE CADEIAS DE PROCESSOS PRODUTIVOS AUTOMOTIVOS UTILIZANDO WEB SERVICES LEONARDO BROILO JUNIOR BLUMENAU /2-15

2 LEONARDO BROILO JUNIOR ECON: MONITORAMENTO DE EVENTOS DE CADEIAS DE PROCESSOS PRODUTIVOS AUTOMOTIVOS UTILIZANDO WEB SERVICES Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Ciência da Computação Bacharelado. Prof. Francisco Adell Péricas, Mestre - Orientador BLUMENAU /2-15

3 ECON: MONITORAMENTO DE EVENTOS DE CADEIAS DE PROCESSOS PRODUTIVOS AUTOMOTIVOS UTILIZANDO WEB SERVICES Por LEONARDO BROILO JUNIOR Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por: Presidente: Membro: Membro: Prof. Francisco Adell Péricas, Mestre Orientador, FURB Prof. Paulo Fernando da Silva, Mestre FURB Prof. Oscar Dalfovo, Doutor FURB Blumenau, 01 de dezembro de 2011

4 Dedico este trabalho aos meus pais, Leonardo e Deise, irmãos, namorada e todos os amigos, especialmente aqueles que me ajudaram diretamente na realização deste.

5 AGRADECIMENTOS Aos meus pais, por acreditarem na minha capacidade e investirem no meu potencial. À minha família, pelo constante apoio durante a realização deste trabalho. À minha namorada, pela motivação e compreensão nos momentos difíceis. Ao meu orientador, Francisco Adell Péricas, por apoiar minha idéia e ter acreditado na conclusão deste trabalho. Aos meus colegas, que deram sugestões e apoio na realização deste trabalho. À T-Systems do Brasil pelo apoio concedido. A todos que contribuíram direta ou indiretamente para a realização deste trabalho.

6 Mais que de máquinas, precisamos de humanidade. Charles Chaplin

7 RESUMO Este trabalho apresenta a especificação e o desenvolvimento de um sistema de monitoramento de processos produtivos de um sistema de planejamento e controle de produção automotiva utilizando Web Services. O módulo servidor, o módulo cliente e o Web Service foram desenvolvidos utilizando a linguagem Java. Através do módulo cliente é possível monitorar os erros que ocorrem nos processos produtivos de montadoras de automóveis. O módulo servidor mantém uma base de dados centralizada e gerencia a troca de informações entre os servidores das fábricas e os módulos clientes ativos. Palavras-chave: Monitoramento. Planejamento e controle de produção. Cadeia de processos. Web services. SOAP.

8 ABSTRACT This work presents the specification and development of a system for monitoring productive processes from automotive production planning and control systems using Web Services. The server module, the client module and the Web service were developed using the Java programming language. Through the client module it is possible to monitor errors that occur in production processes of automobile manufacturers. The server module maintains a centralized database and manages the exchange of information between the plant's productive servers and active clients. Key-words: Monitoring. Production planning and control. Process chain. Web services. SOAP.

9 LISTA DE ILUSTRAÇÕES Figura 1 - Atividades básicas do PCP Quadro 1 - Exemplo simples de uma cadeia de processos no arquivo de configuração Quadro 2 - Linhas do log que evidenciam erros nos processos Quadro 3 - Exemplos da descrição de erros Figura 2 - Integração dos serviços de TI aos recursos e estratégias de negócio Figura 3 - Perguntas para estabelecer uma visão incluindo métricas, metas e objetivo Figura 4 - Aplicação cliente acessando diretamente um Web Service Figura 5 - Arquitetura dos Web Services Quadro 4 - Exemplo de arquivo XML representando um número de telefone Figura 6 - Estrutura da mensagem SOAP Quadro 5 - Exemplo de um envelope SOAP enviado em uma requisição HTTP Figura 7 - Principais elementos de um documento WSDL Quadro 6 - Principais namespaces de um documento WSDL Figura 8 - Casos de uso do módulo servidor Quadro 7 - Caso de uso Quadro 8 - Caso de uso Quadro 9 - Caso de uso Quadro 10 - Caso de uso Quadro 11 - Caso de uso Figura 9 - Casos de uso do módulo cliente Quadro 12 - Caso de uso Quadro 13 - Caso de uso Quadro 14 - Caso de uso Quadro 15 - Caso de uso Quadro 16 - Definição dos pacotes do módulo servidor Figura 10 - Pacote econserver.ui Figura 11 - Pacote econserver.db Figura 12 - Pacote econserver.rmi Figura 13 - Pacote econaxisws Quadro 17 - Definição dos pacotes do módulo cliente Figura 14 - Pacote econclientmonitor.ui... 42

10 Figura 15 - Pacote econclientmonitor.util.telegram Figura 16 - Pacote econclientmonitor.rmi Figura 17 - Diagrama de atividades do módulo servidor Figura 18 - Diagrama de atividades do módulo cliente Figura 19 - MER do banco de dados Quadro 18 Classe econws Quadro 19 Procedimento do script PERL e definição do endereço do arquivo WSDL Quadro 20 - Método run da thread ThreadListenMessagesFromWS Figura 20 - Tela principal do módulo servidor Quadro 21 - Estrutura da barra de ferramentas Quadro 22 - Estrutura de menus Figura 21 - Tela de manutenção de fábricas Figura 22 - Tela para cadastro de nova fábrica Figura 23 - Tela de manutenção de servidores Figura 24 - Tela para cadastro de novo servidor Figura 25 - Tela de manutenção de instâncias Figura 26 - Tela para cadastro de nova instância Figura 27 - Tela de manutenção de usuários Figura 28 - Tela para cadastro de novo usuário Figura 29 - Tela de manutenção da associação de usuários e fábricas Figura 30 - Tela de autenticação do módulo cliente Figura 31 - Tela principal do módulo cliente Figura 32 - Aba de monitoramento de mensagens críticas Figura 33 - Tela de visualização de mensagens críticas Figura 34 - Tela de visualização dos possíveis erros Figura 35 - Tela de relatório de erros Figura 36 - Tela do simulador de mensagens Quadro 23 - Exemplo de um arquivo com mensagens de erro Quadro 24 - Comparativo com trabalhos correlatos Quadro 25 - Arquivo WSDL Quadro 26 - Laço principal do script PERL Figura 37 - Autorização da T-Systems do Brasil... 75

11 LISTA DE SIGLAS AIX Advanced Interactive executive AMS Application Management Service CS3 Communication System 3 EM Event Manager ERP - Enterprise Resource Planning HTTP HyperText Transfer Protocol IBM International Business Machine JIT - Just In Time MER Modelo Entidade Relacional MRP - Material Requirement Planning MRP II - Manufacturing Resource Planning OPT - Optimized Production Technology P2P Peer To Peer PCP - Planejamento e Controle de Produção PERL Practical Extraction and Report Language RMI - Remote Method Invocation SGBD Sistema Gerenciador de Banco de Dados SOAP - Sample Object Access Protocol TI Tecnologia da Informação UML Unified Modeling Language W3C World Wide Web Consortium WSDL Web Services Definition Language XML - extensible Markup Language

12 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS DO TRABALHO ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA PLANEJAMENTO E CONTROLE DE PRODUÇÃO Atividades do planejamento e controle da produção Conceitos e características dos sistemas produtivos MRP Planejamento das necessidades de materiais Just In Time (JIT) OPT Tecnologia de produção otimizada Sistema de planejamento e controle de produção do grupo Cadeia de processos Detecção de erros de processos GERENCIAMENTO DE SERVIÇOS DE TI WEB SERVICES Arquitetura XML SOAP WSDL TRABALHOS CORRELATOS DESENVOLVIMENTO REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO ESPECIFICAÇÃO Diagrama de casos de uso Módulo servidor Módulo cliente Diagrama de classes Módulo servidor Módulo Cliente Diagrama de atividades Modelo Entidade Relacional (MER)... 47

13 3.3 IMPLEMENTAÇÃO Técnicas e ferramentas utilizadas Implementação do sistema Operacionalidade da implementação Módulo Servidor Módulo Cliente Simulador de mensagens RESULTADOS E DISCUSSÃO CONCLUSÕES EXTENSÕES REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICE A Arquivo econ.wsdl APÊNDICE B Laço principal do script PERL ANEXO A Autorização da T-Systems do Brasil... 75

14 13 1 INTRODUÇÃO Frente às mudanças constantes na área da Tecnologia da Informação (TI) e ao aumento na concorrência desta área, surge a necessidade de que as organizações sejam inteligentes e que se modifiquem, o que requer um melhor planejamento de suas informações, de seu conhecimento e de sua tecnologia da informação. Levando isso em consideração pode-se chegar à conclusão de que as empresas lidam a cada dia com mais dados, os quais precisam ser devidamente trabalhados para que possam agregar algum valor à organização a fim de gerar conhecimento sempre que necessário (REZENDE, 2003, p. 39). A empresa T-Systems do Brasil é uma destas organizações que se atualiza frequentemente para continuar em uma posição destacada perante o mercado nacional e internacional (T-SYSTEMS, 2011). Dentre os projetos de suporte e sustentação existentes na empresa, um deles visa prestar suporte ao sistema de planejamento e controle que gerencia a linha de produção das fábricas de um grupo de montadoras de automóveis. Denominado de projeto de suporte Application Management Services (AMS), utiliza os conceitos de boas práticas em gerenciamento de serviços de tecnologia da informação para garantir a satisfação do cliente. A equipe AMS é responsável por gerenciar e suportar os recursos e serviços do sistema de planejamento e controle utilizado pela área de Planejamento e Controle da Produção (PCP) dos clientes aos quais presta serviço. O bom funcionamento do sistema e a qualidade do serviço prestado dependem de uma estratégia de monitoramento eficiente. É através deste sistema que a área de PCP tem controle total sobre os produtos que estão sendo produzidos. Hoje, esta equipe presta suporte ao sistema planejamento e controle de produção de doze fábricas deste grupo em países como Brasil, Inglaterra, Índia, China, África do Sul, Argentina e Espanha. Dentro deste contexto, ferramentas que ajudem os analistas e técnicos no controle dos processos produtivos do cliente, seja na coleta de informações, no monitoramento ou na execução de tarefas automatizadas, são de suma importância para o ganho de produtividade e a garantia da qualidade do serviço. O presente trabalho possibilitará aos técnicos e analistas da empresa T-Systems do Brasil aperfeiçoar o trabalho de monitoramento e controle dos eventos e dos processos produtivos ativos nos servidores de todas estas doze fábricas. Para tal, foi desenvolvido um módulo a ser executado no servidor, que disponibiliza serviços através de Web Services, e um

15 14 módulo a ser executado nos clientes, ambos utilizando a linguagem de programação Java e rodando no sistema operacional Windows. Também foi desenvolvido um script utilizando a linguagem de programação Practical Extraction and Report Language (PERL), para rodar nos servidores produtivos das fábricas com sistema operacional Advanced Interactive executive (AIX), da International Business Machines (IBM), e que alimenta a base de dados utilizada pelo servidor e pelos clientes ativos. Segundo Albinader Neto e Lins (2006), a tecnologia dos Web Services pode fazer com que dados sejam transmitidos entre várias entidades, desde que a semântica possa ser transformada em informação útil para as entidades envolvidas. Esta tecnologia permite que sistemas desenvolvidos em plataformas diferentes sejam compatíveis, enviando e recebendo dados em formato padrão extensible Markup Language (XML). O protocolo básico para a comunicação entre duas partes é o Sample Object Access Protocol (SOAP) (ALBINADER NETO; LINS, 2006, p. 78). O SOAP é um protocolo utilizado para a troca de informações estruturadas em uma plataforma distribuída e descentralizada. A integração dos dados quando não se trabalha com Web Services apresenta-se como um desafio complexo quando estes estão situados em entidades, plataformas e sistemas diferentes (ALBINADER NETO; LINS, 2006, p. 8). Neste sentido, o desenvolvimento de aplicações distribuídas e de serviços que utilizam Web Services torna-se relevante por se adequarem a uma arquitetura com plataformas, linguagens e sistemas diferentes. Este trabalho apresenta uma forma descentralizada de monitoramento dos processos produtivos ativos nos servidores através de Web Services permitindo vários clientes simultâneos avaliar continuamente de qualquer lugar o estado destes processos, garantindo a qualidade do serviço de suporte e sustentação do sistema oferecido pela equipe da T-Systems, que autorizou o uso de algumas informações conforme anexo A. 1.1 OBJETIVOS DO TRABALHO O objetivo deste trabalho é disponibilizar uma ferramenta que, com o auxílio de Web Services, seja capaz de receber, gerenciar e transmitir aos clientes ativos informações do processo produtivo dos servidores produtivos da rede de um grupo de montadoras de veículos para facilitar e otimizar seu processo de monitoramento. Os objetivos específicos do trabalho são:

16 15 a) disponibilizar um módulo a ser executado no servidor, que faz a gerência do sistema e disponibiliza os Web Services, e um módulo cliente que será executado nos computadores de monitoramento; b) centralizar informações coletadas dos servidores produtivos das fábricas no módulo servidor; c) proporcionar aos analistas e técnicos uma melhor qualidade do serviço prestado e uma maior produtividade na detecção de erros durante o processo produtivo de veículos. 1.2 ESTRUTURA DO TRABALHO Este trabalho está estruturado em quatro capítulos. O segundo capítulo contém a fundamentação teórica necessária para o desenvolvimento do trabalho. Nele são abordados assuntos relacionados ao processo produtivo e planejamento e controle de produção, ao gerenciamento de serviços de TI e ao funcionamento da tecnologia de Web Services e os padrões que integram parte desta tecnologia. Por último, são apresentados quatro trabalhos correlatos. No terceiro capítulo são detalhados os passos do desenvolvimento da ferramenta, intitulada econ, onde são relacionados seus requisitos, bem como explicada a especificação contendo diagramas de casos de uso, de classe, de atividades e a modelagem do banco de dados. Também são feitos comentários sobre a implementação abrangendo ferramentas utilizadas, técnicas, operacionalidade e, por fim, são discutidos os resultados obtidos. O quarto capítulo refere-se às conclusões do presente trabalho e sugestões para trabalhos futuros.

17 16 2 FUNDAMENTAÇÃO TEÓRICA Neste capítulo, aspectos teóricos relacionados ao desenvolvimento e entendimento do trabalho serão apresentados. Por primeiro, são abordados os temas PCP, sistema de planejamento e controle de produção e gerenciamento de serviços de TI. Após serão abordados temas como Web Services, XML, a tecnologia SOAP e a linguagem Web Service Definition Language (WSDL). Por fim são apresentados trabalhos correlatos com características semelhantes ao trabalho proposto. 2.1 PLANEJAMENTO E CONTROLE DE PRODUÇÃO Segundo Vollmann et al. (2005, p. 25), o sistema de PCP ocupa-se do planejamento e controle de todos os aspectos da produção, inclusive do gerenciamento de materiais e da programação de máquinas e pessoas e da coordenação de fornecedores e clientes-chave. A tarefa essencial do sistema de PCP é gerenciar com eficiência o fluxo de material, a utilização de pessoas e equipamentos e responder às necessidades do cliente utilizando a capacidade dos fornecedores, da estrutura interna e, em alguns casos, dos clientes para atender à demanda do cliente. [...] O sistema de PCP não toma decisões nem gerencia operações os gerentes desempenham essas atividades. O sistema de PCP dá o suporte para que eles o façam de maneira sábia. (VOLLMANN et al., 2005, p. 28). Os sistemas de PCP realmente eficazes coordenam cadeias de suprimento, ou supply chain. Segundo Supply-Chain Council (2011), supply chain é todo esforço envolvido nos processos e atividades empresariais que criam valor na forma de produtos e serviços para o consumidor final, sendo também uma forma integrada de planejar e controlar o fluxo das mercadorias. Sendo assim, engloba todos os esforços empenhados na elaboração e na distribuição de um produto ou serviço, desde o primeiro fornecedor até o consumidor final. Vários termos são frequentemente utilizados para tratar o mesmo assunto. Gestão da produção, gerenciamento da produção, administração da produção e planejamento e controle da produção são alguns destes termos (PIRES, 1995, p. 119). A seguir são apresentadas as principais atividades de PCP, conceitos e principais características dos sistemas produtivos.

18 Atividades do planejamento e controle da produção Independentemente do sistema produtivo e abordagem utilizada pelo PCP, existem algumas atividades que são tradicionalmente peculiares à sua realização. Isto significa que, em um nível de complexidade variável, estas atividades, representadas na Figura 1, sempre se farão necessárias (PIRES, 1995, p. 136). Fonte: adaptado de Pires (1995, p. 137). Figura 1 - Atividades básicas do PCP Na previsão de vendas, o planejamento inicia-se com os dados fornecidos pela área de vendas. Esses dados dizem respeito ao que produzir, em quais quantidades e em que prazo. O planejamento agregado da produção consiste no estabelecimento dos níveis gerais de capacidade e produção para um período de médio e longo prazo. Este planejamento é feito em termos de famílias de itens e os produtos a serem produzidos não são definidos de forma individual e especificada, mas são agregados formando famílias de itens semelhantes. O programa mestre de produção é um referencial básico para a produção, e estabelece quando e em que quantidade cada produto deverá ser produzido dentro de um certo horizonte de planejamento. Geralmente é nesta etapa onde verificações mais detalhadas da capacidade podem nivelar a produção por restrições organizacionais e econômicas. O planejamento das necessidades materiais calcula as chamadas necessidades líquidas para cada produto a ser produzido. Estas necessidades são calculadas com base nas necessidades brutas vindas da lista de materiais, pelas exigências impostas pelo programa

19 18 mestre e pelas informações do controle de estoque, considerando itens em estoque e itens em processo de fabricação ou compra. O controle de estoques trata basicamente do controle sobre todos os itens fabricados, comprados e utilizados para a produção de seus produtos. Este controle visa maximizar o nível de atendimento aos clientes e a produção da indústria e minimizar os investimentos em estoques. A programação da produção determina os prazos de entrega para os itens definidos. As restrições para esta tarefa são impostas pela capacidade disponível do centro produtivo para o período em questão, bem como pelas exigências tecnológicas colocadas nos roteiros de produção. O planejamento e controle da capacidade estipula quais devem ser os níveis de produção máximos que os centros produtivos devem ter em um certo horizonte de planejamento. Cuida das informações a serem utilizadas por outras atividades do PCP e das providências para que a capacidade planejada seja realizada. O controle da produção consiste em acompanhar a fabricação e compra dos itens programados com o objetivo de que os prazos sejam cumpridos. O controle da produção também atua coletando dados importantes para o sistema de custos, tomando decisões típicas de chão de fábrica e alimentando informações ao controle de estoques Conceitos e características dos sistemas produtivos As atividades de planejamento e controle de produção podem ser implementadas e operacionalizadas seguindo algumas das abordagens de PCP. Neste tópico serão brevemente descritas três destas abordagens, que são o Material Requirement Planning (MRP), o Just In Time (JIT) e a Optimized Production Technology (OPT) MRP Planejamento das necessidades de materiais O termo MRP surgiu na década de 1960 com o objetivo de executar computacionalmente a atividade de planejamento das necessidades de materiais, permitindo assim determinar as prioridades das ordens de compra e fabricação precisa e rapidamente. Na década de 70 este sistema, que executava o cálculo das necessidades materiais,

20 19 evoluiu paralelamente ao desenvolvimento da informática, surgindo um sistema computacional com o pretensioso objetivo de realizar todas as principais atividades do PCP (PIRES, 1995, p. 143). Este novo sistema passou a se chamar Manufacturing Resource Planning (MRP II). O MRP II pode ser descrito como um sistema hierárquico de gestão da produção, em que os planos de longo prazo são sucessivamente detalhados até se chegar ao nível do planejamento de componentes e máquinas (CORREA; GIANESI, 1993, p. 116). Outros módulos começaram a ser acrescidos nos sistemas MRP II, como o módulo de compras e o módulo financeiro. Estes sistemas integrados passaram a ser chamados de Enterprise Resource Planning (ERP) e são capazes de atender a necessidade de diversas áreas das empresas, apoiando a tomada de decisões de outros setores e não apenas aqueles ligados à manufatura, a partir de uma base de dados central e não redundante. (CORREA; GIANESI; CAON, 1997, p. 343) Just In Time (JIT) O princípio básico da filosofia JIT, no que diz respeito a produção, é atender de forma rápida e flexível à variada demanda do mercado, produzindo geralmente em lotes pequenos. O planejamento e programação da produção dentro do contexto desta filosofia procura adequar a demanda esperada às possibilidades do sistema produtivo. Este objetivo é alcançado através da utilização da técnica de produção nivelada. Segundo Correa e Gianesi (1993, p. 88), a utilização do conceito de produção nivelada envolve duas fases, a programação mensal e a programação diária da produção. Através do conceito de produção nivelada, as linhas de produção podem produzir vários produtos diferentes a cada dia, de acordo com a demanda do mercado. Para isto, é fundamental que se busque a redução dos tempos envolvidos nos processos. A filosofia JIT coloca a ênfase da gerência no fluxo de produção fazendo com que os produtos fluam de forma contínua através das fases do processo de produção. A principal ênfase do JIT para as linhas de produção é a flexibilidade. Espera-se que a produção esteja ajustada às variações da demanda, sendo balanceadas muitas vezes. A busca pela flexibilidade e pela redução dos tempos de preparação de equipamentos reflete-se na ênfase dada à produção de modelos mesclados de produtos, permitindo uma produção adaptável às mudanças de curto prazo e obtendo ganhos de produtividade.

21 OPT Tecnologia de produção otimizada A OPT pode ser apresentada como uma abordagem de gestão de produção orientada por gargalos produtivos e baseada em uma técnica de programação da produção que utiliza um software específico. Os gargalos da produção são os recursos produtivos sobre os quais a demanda imposta é maior que a sua capacidade de processamento. Os recursos anteriores ao gargalo são puxados, na chamada programação para trás, e os recursos posteriores são empurrados, na chamada programação para frente, de acordo com as saídas do gargalo. Segundo Correa e Gianesi (1993, p. 163), a filosofia da OPT é baseada em 9 princípios: a) balancear o fluxo e não a capacidade; b) o nível de utilização de um recurso não gargalo não é determinada por sua disponibilidade, mas por alguma outra restrição do sistema; c) utilização e ativação de um recurso não são sinônimos; d) uma hora ganha em um recurso gargalo é uma hora ganha para o sistema como um todo; e) uma hora ganha em um recurso não gargalo não é nada, apenas uma ilusão; f) o lote de transferência pode não ser, e não deveria ser, igual ao lote de processamento; g) o lote de processamento deve ser variável e não fixo; h) os gargalos governam o volume de produção e o volume de estoques; i) a programação das atividades e a capacidade produtiva devem ser consideradas simultaneamente e não sequencialmente. O lead time é resultado da programação e não pode ser predeterminado. Segundo Correa e Gianesi (1993, p. 158), o software OPT é composto de quatro módulos. A OPT programa os Recursos Restritivos Críticos (RRC) com uma lógica de programação finita para frente. O Buildnet cria e mantém a base de dados atualizada. O Serve ordena os pedidos de utilização de recursos e programa os recursos não gargalos. O Split que separa os recursos em gargalos e não gargalos. A OPT tem-se mostrado capaz de reduzir o lead time em até 30% e o estoque na ordem de 40 a 75% (CORREA; GIANESI, 1993, p. 164). Um fato desfavorável é que o algoritmo não é público e cria uma dependência da empresa usuária com apenas um fornecedor do

22 21 sistema. Outra questão é que ela não possui nenhuma forma de retroalimentação do sistema em função do que realmente ocorre no chão de fábrica, dificultando as funções de controle de produção Sistema de planejamento e controle de produção do grupo O sistema de planejamento e controle de produção utilizado pelo grupo de montadoras de veículos é responsável por gerenciar toda linha de produção. Uma linha de produção é um conjunto de estações de trabalho seqüencialmente dispostas, normalmente interligadas por um sistema contínuo de movimentação de materiais, e projetada para montar componentes e realizar qualquer operação necessária à obtenção de um produto acabado. (ASKIN; STANDRIDGE, 1993, p. 19). Neste caso o sistema gerencia desde a armação da carroceria (onde as chapas de aço são soldadas), passando pela pintura até chegar à montagem final onde acontece a montagem da carroceria e do chassi e são feitos os testes de qualidade. Ele é dividido em módulos, que são responsáveis por gerenciar diferentes partes do processo produtivo como, por exemplo, o depósito de carrocerias, os fornecedores, o sequenciamento de peças na linha de montagem, a qualidade assegurada e a disponibilização de veículos para serem produzidos. Estes módulos estão instalados em servidores da IBM com sistemas operacionais IBM AIX, e cada módulo roda dentro de uma instância de um middleware chamado Communication System 3 (CS3), desenvolvido pela T-Systems do Brasil. Este middleware nada mais é do que um ambiente para aplicações distribuídas, o qual divide um servidor em instâncias lógicas para uma melhor estruturação do sistema. O sistema de planejamento e controle trabalha com o conceito de cadeia de processos, ou Supply Chain Management, descrito anteriormente Cadeia de processos Para cada instância CS3 que contenha um módulo do sistema há um arquivo de configuração das cadeias de processos. O Event Manager (EM), ou gerenciador de eventos, é o programa responsável por disparar estas cadeias e baseia-se neste arquivo para executar as etapas do processo produtivo, do qual este módulo é responsável. O EM é acionado a cada nova entrada de dados em algum equipamento que esteja ligado ao sistema de produção. Ele

23 22 recebe um telegrama com a sigla de identificação da cadeia a ser disparada e com todas as informações necessárias para a execução dos processos. O Quadro 1 mostra a cadeia de processos PRRD descrita no arquivo de configuração. Quadro 1 - Exemplo simples de uma cadeia de processos no arquivo de configuração O EM aciona sempre o primeiro processo da cadeia. Neste exemplo, o primeiro passo a ser executado desta cadeia é o PRRD001, que irá acionar o processo INITPRRD. Cada processo executado responde ao EM um código de retorno 0, 1 ou 2, que no arquivo correspondem às colunas 4, 5 e 6 respectivamente, sendo 0 quando o processo não responde até um determinado tempo, 1 quando não há dados no banco de dados correspondentes ao veículo que disparou a cadeia e 2 quando o processo é executado com sucesso. O EM se baseará nestes códigos de retorno para verificar qual o próximo processo deve ser disparado até que esta cadeia se encerre com sucesso ou fracasso Detecção de erros de processos Para cada tarefa executada por um processo de uma cadeia são gerados registros num arquivo de log. Quando os processos respondem negativamente ao EM, são geradas linhas neste arquivo contendo qual o processo está com problemas, e qual o código de identificação definido para este tipo de erro. No Quadro 2, um exemplo de algumas linhas deste arquivo de log que identificam erros. Quadro 2 - Linhas do log que evidenciam erros nos processos A descrição dos códigos de erro está definida no ambiente CS3. O Quadro 3 mostra a descrição de alguns códigos de erros.

24 23 código do erro descrição do erro POL0003 Error during sending to EM POL0005 Timeout after sending telegram POL0012 error during sending to resource POL0077 no data in FIS database for KNR '%2' POL0211 ***** state '%2' of KNR '%3' already exists! ***** POL0218 FHSTATUS error! (KNR=%2) POL0224 ATTENTION! state '%2', KNR '%3': identical seq. No. exists! inserting not possible Quadro 3 - Exemplos da descrição de erros Todos os erros gerados nos logs das instâncias CS3 devem ser analisados e, se necessário, corrigidos. Estas mensagens com erros serão tratadas pelo script PERL e enviadas ao Web Service para que os clientes conectados naquele instante tomem conhecimento dos problemas que estão ocorrendo nas fábricas naquele instante. 2.2 GERENCIAMENTO DE SERVIÇOS DE TI Com o crescimento da dependência das organizações em relação a TI e com o crescimento da disponibilidade de informações, cada minuto de indisponibilidade de um sistema em uma organização de grande porte pode significar um prejuízo da ordem dos milhares de reais. Atualmente as áreas de TI não podem mais se preocupar unicamente com questões tecnológicas. É necessária uma integração com as demais áreas das organizações para que o gerenciamento de serviços tenha um caráter mais formal e passe a ser visto como um investimento e não como um custo. Segundo Dias (2008), o gerenciamento do serviço de TI é fundamental para o sucesso de uma organização pelo simples fato de alinhar pessoas, processos e infra-estrutura, a fim de fornecer e suportar serviços de TI que possibilitem as funções e atividades do negócio. A necessidade pelo gerenciamento de serviços cresce à medida que os negócios dependem dos serviços de TI. A Figura 2 mostra que os serviços estão integrados aos recursos e estratégias do negócio.

25 24 Fonte: Dias (2008). Figura 2 - Integração dos serviços de TI aos recursos e estratégias de negócio Segundo Fabiciack (2009), um serviço de TI é um conjunto de recursos da infraestrura de TI que atendem uma ou mais necessidades dos seus clientes. Este conjunto é considerado pelo cliente como uma solução que apóia a sua função no negócio. O gerenciamento dos serviços de TI tem por objetivo garantir a entrega de serviços que satisfaçam os requisitos acordados entre o cliente e o fornecedor, tanto em desempenho quanto em custo, além de estar alinhado aos objetivos estratégicos da organização (MAGALHÃES; PINHEIRO, 2007, p. 59). deve: Segundo Magalhães e Pinheiro (2007, p. 60), para atingir estes objetivos a área de TI a) contribuir estrategicamente com o negócio; b) permitir a mensuração da contribuição para o negócio; c) realizar a entrega de serviços mais consistentes e estáveis; d) enfatizar menos a tecnologia. Para que uma organização de TI possa funcionar como um negócio é preciso traçar uma visão incluindo objetivos, métricas e metas. Deve-se ter um programa de melhoria contínua do gerenciamento de serviços e a cada ciclo traçar os objetivos que se espera obter em determinado prazo, avaliando e adaptando os processos para uma melhor eficácia e eficiência nos resultados (FABICIACK, 2009). Para estabelecer um ciclo de evolução constante e uma política de melhoria contínua as organizações podem se basear em algumas perguntas que poderão orientá-las nas suas estratégias e objetivos, conforme a Figura 3.

26 25 Fonte: Fabiciack (2009). Figura 3 - Perguntas para estabelecer uma visão incluindo métricas, metas e objetivo 2.3 WEB SERVICES Os Web Services são utilizados para disponibilizar serviços interativos numa rede, com o objetivo de integração e comunicação entre sistemas distribuídos ou aplicações stand-alone (CUNHA, 2002). Um sistema Web Service é implementado para fornecer interoperabilidade entre hosts em uma determinada rede. Possui uma interface descrita no formato conhecido como Web Services Definition Language (WSDL). Sistemas interagem com Web Services usando mensagens SOAP, através do HyperText Transfer Protocol (HTTP) com uma serialização XML em conjunto com outros padrões relacionados. (WORLD WIDE WEB CONSORTIUM, 2011). Interoperabilidade é um dos principais ganhos com a implementação de Web Services. Segundo Singh (2006, p. 5), talvez esta interoperabilidade seja a razão primordial para o crescimento do uso de Web Services, pois os sistemas que foram escritos em diferentes linguagens e operam em plataformas distintas podem trabalhar juntas sem maiores problemas. Ainda segundo ele, os Web Services reduzem custos operacionais e permitem que as organizações reutilizem suas funcionalidades de sistemas existentes. Cunha (2002) explica que a aplicação cliente, após localizar o serviço remoto (definido por um documento WSDL), invoca os seus serviços [...]. O Web Service recebe a chamada, a processa e envia uma resposta. É válido lembrar que cliente e Web Service conversam usando SOAP sobre HTTP.

27 26 Fonte: Cunha (2002). Figura 4 - Aplicação cliente acessando diretamente um Web Service Arquitetura O Web Service é baseado na integração de 3 entidades: provedor de serviços (service provider), cliente do serviço (service consumer) e servidor de registros (service broker ou service registry). A iteração destas entidades serve para que haja busca, publicação e execução das operações (CHAPPELL, JEWEL, 2002, p. 14). O provedor de serviços representa a entidade que hospeda o Web Service. É considerado o dono do serviço e responsável pela disponibilização do mesmo para utilização. Este serviço deve estar descrito em um formato padrão para que qualquer um que precise usar este serviço possa compreendê-lo. O provedor de serviços deve publicar os detalhes dos Web Services fornecidos por ele em um servidor de registros que esteja disponível. O cliente do serviço é todo cliente que busca um serviço desejado e inicia a interação com um provedor de serviços. Este cliente pode ser tanto uma pessoa acessando através de um navegador quanto uma entidade computacional sem interface com o usuário, como um outro Web Service por exemplo. O cliente do serviço deve conhecer a interface de comunicação do Web Service, que é disponibilizada por um provedor e recuperada a partir de uma pesquisa no servidor de registro. O servidor de registro representa a busca de registros de serviços baseados em arquivos de descrição publicados pelos provedores. A Figura 5 mostra a ligação entre estas três entidades.

28 27 Figura 5 - Arquitetura dos Web Services A base para a construção de um Web Service são os padrões XML, que definem os tipos de dados a serem enviados, e SOAP, responsável pelo encapsulamento destes dados. A transmissão dos dados é feita via HyperText Transfer Protocol (HTTP). Os métodos dos serviços são descritos através da linguagem WSDL XML O XML é uma recomendação da World Wide Web Consortium (W3C) para gerar linguagens de marcação para necessidades especiais. Estas linguagens são um conjunto de convenções para codificação de textos, que devem especificar quais marcas são permitidas, quais são exigidas, como distinguí-las entre as marcas e o texto e qual o significado da marcação (ALMEIDA, 2002). De acordo com Singh (2006, p. 35), o XML é uma linguagem de marcação baseada em textos, bastante flexível e simples. Os dados são marcados utilizando, entre colchetes angulares, as tags, que contém o significado dos dados marcados por elas. Esta marcação permite que sistemas interpretem facilmente dados enviados por qualquer outro sistema distinto. Segundo Marchal (2000, p. 9), o XML pode ser útil em áreas como carga e descarga de bancos de dados, aplicações de comércio eletrônico e troca de informações entre organizações. O Quadro 4 mostra um exemplo de um arquivo XML com marcação de dados com diferentes representações de um número telefônico, contendo o código de área, o prefixo e o número do telefone. Um arquivo deste tipo poderia ser facilmente interpretado por diversos sistemas para a troca de informações entre aplicações distintas.

29 28 Fonte: Snell, Tidwell e Kulchenko (2002, p. 12). Quadro 4 - Exemplo de arquivo XML representando um número de telefone SOAP O SOAP é um protocolo que permite a dois sistemas, um cliente e um servidor, trocar dados entre si. Este protocolo foi especificado de modo a ser implementado em uma variedade de protocolos de transporte, porém ele é mais utilizado sobre o HTTP. De acordo com Sant Anna (2002), O SOAP é um protocolo elaborado para facilitar a chamada remota de funções via internet, permitindo que dois programas comuniquem-se de uma maneira tecnicamente muito semelhante à invocação de páginas Web. Por ser elaborado como um padrão, sua utilização e implementação torna-se mais fácil. O SOAP é uma especificação complexa e não se deve dizer que se resume apenas à chamada de funções remotas. O SOAP, dentre suas variadas funções, permite a transmissão assíncrona de mensagens em uma via, além de permitir serviços web orientado a documentos (SNELL, TIDWELL, KULCHENKO, 2002, p. 11). Conforme Seely (2002, p. 43), a especificação do SOAP é dividida em quatro partes principais: a) SOAP envelope: define uma plataforma para descrição do que há na mensagem e como processá-la. É a única parte do protocolo que é obrigatória; b) SOAP enconding rules: define um mecanismo de serialização que pode ser usado para a troca de instâncias de tipos definidos pela aplicação; c) SOAP Remote Procedure Call (RPC) style: define uma convenção que pode ser usada para representar chamadas e respostas remotas a procedimentos, nada mais que a dupla requisição/resposta, que não é obrigatória; d) link SOAP-HTTP: define um protocolo que liga o SOA e o HTTP. Ele descreve como mensagens SOAP são transmitidas via HTTP.

30 29 A mensagem SOAP, como demonstrado na Figura 6, consiste num envelope contendo um cabeçalho opcional e um corpo obrigatório. O cabeçalho contém blocos de informações relevantes sobre como a mensagem deve ser processada, incluindo rota e entrega, autenticação ou autorização e contextos de transações. O corpo da mensagem contém a mensagem atual que será entregue e processada. Tudo o que puder ser expressado em um arquivo XML poderá estar no corpo da mensagem (SNELL, TIDWELL, KULCHENKO, 2002, p. 13). Fonte: Snell, Tidwell e Kulchenko (2002, p. 13). Figura 6 - Estrutura da mensagem SOAP Por ser um padrão XML, o SOAP possui suas próprias marcas para a identificação do protocolo. No Quadro 5 é apresentado um exemplo de XML criado pelo protocolo SOAP com uma marca preço, apresentando o último preço de troca de um produto exemplo. Quadro 5 - Exemplo de um envelope SOAP enviado em uma requisição HTTP WSDL O WSDL define um sistema para descrição de serviços. A partir desta linguagem são descritos os serviços oferecidos por uma determinada aplicação, bem como a sua localização. Assim como a maioria das tecnologias para Web Services, a especificação do WSDL também

31 30 é baseada no XML (RECKZIEGEL, 2006b). Em um documento WSDL existem componentes que formam sua especificação e definem os parâmetros de um determinado serviço. Mello et al. (2006) define estes componentes como: a) types: tipos utilizados no serviço; b) messages: definem, de forma abstrata, as mensagens que serão trocadas; c) operations: definem, de forma abstrata, as operações para uma mensagem; d) port type: descreve um conjunto abstrato de operações mapeadas para um ou mais serviços, os quais são descritos como pontos finais de rede ou portas; e) bindings: definem, de forma concreta, como mapear os elementos messages e operations, nos protocolos de rede que serão utilizados; f) port: uma combinação entre o elemento binding e o endereço de rede, provendo um endereço único para acessar um serviço; g) service: define onde encontrar um serviço usando sua porta. A Figura 7 mostra os principais elementos de um documento WSDL. Fonte: Reckziegel (2006a). Figura 7 - Principais elementos de um documento WSDL O WSDL utiliza namespaces para aumentar a reutilização dos elementos e

32 31 componentes definidos em seu documento. Estes namespaces são espaços para nomes definidos no interior do XML permitindo a unicidade de nomes. Os principais namespaces utilizados em documentos WSDL estão indicados no Quadro 6. Prefixo URI do namespace Descrição WSDL Namespace de WSDL para framework WSDL SOAP Namespace de WSDL para vinculo de SOAP e WSDL HTTP Namespace de WSDL para WSDL HTTP GET e vínculo POST MIME Namespace de WSDL para vínculo MIME de WSDL XSD Namespace do esquema conforme definido pelo esquema de XML Fonte: adaptado de Reckziegel (2006a). Quadro 6 - Principais namespaces de um documento WSDL 2.4 TRABALHOS CORRELATOS A seguir são apresentados trabalhos com características em comum ao trabalho proposto. Os trabalhos têm características específicas do seu escopo, mas englobam áreas relacionadas como o uso de Web Services e a necessidade de controlar e monitorar certos eventos. Venturi (2005) desenvolveu um protótipo de um sistema para controle e monitoração residencial à distância através de dispositivos móveis. Os objetivos principais do protótipo eram controlar e monitorar objetos de uma residência, criar a comunicação da casa com o dispositivo móvel e desenvolver um simulador de um ambiente residencial. Todas as informações relevantes ao controle e monitoramento residencial ficam centralizadas no servidor. Este trabalho foi desenvolvido com o Visual Studio.NET com a linguagem Visual C# e utilizando Web Services para a comunicação de dados via Internet. Outro trabalho analisado é o Traffic Monitor (COUTO; GATTAI, 2008). Foram desenvolvidas uma aplicação para dispositivos móveis e uma aplicação servidora contendo Web Services e um banco de dados com informações dos dados e das rotas dos usuários. O objetivo é disponibilizar ao usuário informações sobre o tráfego nas vias ou rotas definidas pelo usuário no aplicativo para dispositivo móvel. O dispositivo, que deve estar conectado à internet, requisita informações ao servidor que através de Web Services busca as informações

33 32 solicitadas e responde ao dispositivo. Os Web Services desenvolvidos buscam informações nos Web Services disponibilizados pela MapLink, que além das informações sobre o trânsito nas vias das cidades também disponibiliza imagens de mapas e rotas. O Ministério do Meio Ambiente (2008) elaborou um sistema de monitoramento por satélite do desmatamento dos biomas caatinga, cerrado, mata atlântica, pampa e pantanal, com o intuito de quantificar desmatamentos de áreas de vegetação nativa e de embasar ações de fiscalização e combate aos desmatamentos ilegais destes biomas. O objetivo do monitoramento é permitir maior eficiência das políticas públicas voltadas à conservação e uso sustentável destes biomas e de fiscalização e controle da aplicação da legislação ambiental. O sistema capta imagens através de satélites e as envia a um servidor central que disponibiliza Web Services que as processam e distribuem aos clientes da aplicação a informação recebida. Trojan e Padoin (2008) desenvolveram um sistema para o monitoramento remoto de servidores em subestações de energia. O objetivo principal do trabalho é possibilitar o monitoramento remoto das grandezas trabalhadas nas subestações de energia elétrica através de dispositivos móveis. O sistema utiliza Web Services para receber as informações do banco de dados que representam a tensão, corrente elétrica, potência aparente, potência ativa e fator de potência de uma subestação de energia. O aplicativo embarcado no dispositivo móvel recebe estes dados no padrão SOAP e gera ao usuário gráficos que facilitam o monitoramento no caso de uma ocorrência de variação elétrica anormal fora dos limites estipulados. Uma mensagem do tipo Short Message Service (SMS) é enviada ao celular do técnico responsável, o que torna a tarefa de monitoramento mais flexível e dinâmica.

34 33 3 DESENVOLVIMENTO Neste capítulo são detalhadas as etapas do desenvolvimento da ferramenta. São apresentados os principais requisitos, a especificação, a implementação e por fim são listados resultados e discussão. 3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO A ferramenta foi desenvolvida tendo em vista os seguintes requisitos: a) enviar dados coletados aos Web Services através de um script escrito na linguagem PERL que ficará residente nos servidores produtivos que serão monitorados (Requisito Funcional - RF); b) permitir, no módulo servidor, o cadastro e manutenção dos usuários (RF); c) permitir, no módulo servidor, o cadastro das fábricas, dos servidores e das instâncias que serão monitoradas (RF); d) permitir, no módulo servidor, associar os usuários às fábricas que serão por eles monitoradas (RF); e) enviar dados do módulo servidor para os clientes ativos (RF); f) oferecer uma tela de login no módulo cliente para autenticação do usuário (RF); g) permitir o monitoramento dos servidores (RF); h) permitir, no módulo cliente, cadastrar as ações tomadas pelo usuário na correção de um erro detectado no monitoramento (RF); i) permitir ao usuário visualizar relatórios de erros detectados (RF); j) utilizar objetos SOAP para o envio de informações aos Web Services (Requisito Não-Funcional - RNF); k) implementar os módulos cliente e servidor e os Web Services utilizando a linguagem Java e o ambiente Netbeans IDE 7.0 (RNF); l) comunicar os módulos cliente e servidor utilizando o Java Remote Method Invocation (RMI) (RNF); m) utilizar um banco de dados PostgreSQL para armazenar informações no servidor (RNF);

35 ESPECIFICAÇÃO Nesta seção são apresentadas as especificações do sistema desenvolvido. Para especificação dos requisitos foram utilizados alguns dos diagramas da Unified Modeling Language (UML) em conjunto com a ferramenta Enterprise Architect para a descrição dos casos de uso, diagramas de classes e diagrama de atividades Diagrama de casos de uso cliente. A seguir são demonstrados os principais casos de uso do módulo servidor e do módulo Módulo servidor A Figura 8 demonstra os nove (9) casos de uso do módulo servidor. Figura 8 - Casos de uso do módulo servidor

36 35 Abaixo são explanados os casos de uso, com exceção aos UC01, UC02, UC03 e UC04 por se tratarem de cadastros simples. O caso de uso UC05, chamado de Associar Usuários e Fábricas é detalhado no Quadro 7. UC05 - Associar usuários e fábricas Usuário deve ser administrador; deve existir pelo menos uma fábrica e um Pré-condições usuário cadastrados. 01) O usuário acessa a tela Manage User x Plant. 02) O sistema busca os usuários cadastrados. 03) O sistema busca as fábricas cadastradas. Cenário principal 04) O usuário seleciona o usuário. 05) O usuário seleciona a planta na lista Non Associated Plants. 06) O usuário associa a planta ao usuário pressionando o botão >>. 07) O sistema salva a associação no banco de dados. No passo 05, caso o usuário deseje desassociar uma planta ao usuário: Fluxo alternativo ) O usuário seleciona uma planta na lista Associated Plants. 05.2) O usuário pressiona o botão <<. O usuário deverá estar apto a monitorar através do módulo cliente a fábrica Pós-condição associada a ele. Quadro 7 - Caso de uso 05 O caso de uso UC06, chamado Coletar Mensagens de Erros nos Processos, e o caso de uso UC07, chamado Receber Mensagem de Erro do Web Service, são descritos, respectivamente, nos quadros 8 e 9. UC06 Coletar mensagens de erros nos processos Pré-condições Script PERL deve estar rodando no servidor produtivo. 01) O script busca por erros de processos produtivos nos arquivos de log do servidor produtivo. Cenário principal 02) O script trata a mensagem de erro encontrada. 03) O script envia a mensagem ao Web Service utilizando o protocolo SOAP. Pós-condição Módulo servidor deverá receber a mensagem de erro. Quadro 8 - Caso de uso 06 UC07 Receber mensagens de erro do Web Service Pré-condições Não há pré-condições. 01) include::uc06. Cenário principal 02) O sistema trata a mensagem recebida. Pós-condição O sistema deverá enviar a mensagem tratada aos clientes ativos. Quadro 9 - Caso de uso 07 Os casos de uso UC08, chamado Enviar Mensagens de Erro aos Clientes Ativos, e UC09, chamado Receber Ações Tomadas no Erro, são detalhados nos quadros 10 e 11, respectivamente.

37 36 UC08 Enviar mensagens de erro aos usuários ativos Pré-condições Ter uma conexão com um cliente ativo. 01) include::uc07. 02) O sistema verifica de qual fábrica é a mensagem. Cenário principal 03) O sistema busca os usuários ativos. 04) O sistema verifica quais dos usuários ativos devem receber a mensagem. 05) O sistema envia a mensagem. Exceção 01 No passo 03, se não houver usuário ativo, o caso de uso se encerra. No passo 04, se nenhum usuário está associado à fábrica em questão, o caso Exceção 02 de uso se encerra. No passo 05, se a conexão com o cliente for perdida, o caso de uso se Exceção 03 encerra. Pós-condição Os clientes ativos deverão receber a mensagem enviada. Quadro 10 - Caso de uso 08 UC09 Receber ações tomadas no erro Ter enviado uma mensagem de erro classificada como crítica ao cliente Pré-condições ativo. 01) O sistema recebe uma ação tomada por um usuário. Cenário principal 02) O sistema salva a ação na base de dados. O erro deverá constar como resolvido na base de dados e estará disponível Pós-condição nos relatórios. Quadro 11 - Caso de uso Módulo cliente A Figura 9 demonstra os cinco (5) casos de uso do módulo cliente. Figura 9 - Casos de uso do módulo cliente

38 37 Abaixo são explanados os casos de uso, com exceção do UC12. O caso de uso UC10 é chamado Efetuar Login e tem uma exceção, conforme representado no Quadro 12. No Quadro 13 é apresentado o caso de uso UC11, chamado Receber Mensagem de Erro do Servidor e que possui um fluxo alternativo. UC10 Efetuar login Pré-condições Cenário principal Exceção 01 Pós-condição Não há pré-condições 01) O usuário inicializa o módulo cliente. 02) O usuário informa o endereço IP do servidor, a porta de comunicação, o login e a senha. 03) O sistema valida os dados. 04) O sistema autoriza o usuário e abre a tela inicial. No passo 03, os dados do usuário podem não ser validados: 03.1) O sistema mostra uma mensagem de erro. O usuário deve estar autenticado e o sistema liberado para uso. Quadro 12 - Caso de uso 10 UC11 Receber mensagem de erro do servidor Pré-condições Módulo cliente deve estar conectado ao servidor. 01) O sistema recebe uma mensagem de erro de processo do módulo servidor. Cenário principal 02) O sistema trata a mensagem recebida. 03) O sistema mostra a mensagem de erro na aba Monitoring. No passo 03, caso a mensagem seja classificada como crítica: 03.1) O sistema também mostra a mensagem de erro na aba Critical Fluxo alternativo 01 Messages. 03.2) O sistema emite um alarme sonoro. Pós-condição O usuário identifica o erro e sua criticidade para o sistema. Quadro 13 - Caso de uso 11 O caso de uso UC13 é chamado Enviar ao Servidor as Ações Tomadas no Erro e está representado no Quadro 14. O caso de uso UC14 é chamado Ver Relatório de Erros, como mostra o Quadro 15. Ambos possuem um fluxo alternativo. UC13 Enviar ao servidor as ações tomadas no erro Módulo cliente deve estar conectado ao servidor e o usuário deve estar Pré-condições autenticado. 01) O usuário acessa a aba Critical Messages. 02) O usuário clica no botão OK ao lado da mensagem de erro. 03) O usuário seleciona seu login. Cenário principal 04) O usuário insere as ações tomadas sobre o erro. 05) O usuário salva a ação. 06) O sistema envia as ações ao servidor. 07) O alarme sonoro é desativado. Pós-condição O erro constará como resolvido nos clientes ativos. Quadro 14 - Caso de uso 13

39 38 UC14 Ver relatório de erros Módulo cliente deve estar conectado ao servidor e o usuário deve estar Pré-condições autenticado. 01) O usuário acessa a tela de relatórios. 02) O sistema lista as fábricas, servidores e instâncias disponíveis. 03) O usuário escolhe a fábrica. Cenário principal 04) O usuário escolhe o servidor. 05) O usuário escolhe a instância. 06) O usuário pressiona o botão Select. No passo 05, o usuário pode adicionar uma data específica para a busca: Fluxo alternativo ) O usuário insere a data. 05.2) O usuário insere a hora. As informações que satisfaçam as condições do usuário devem ter sido Pós-condição mostradas. Quadro 15 - Caso de uso Diagrama de classes Com a intenção de facilitar a leitura, entendimento e interpretação do diagrama de classes, são apresentados os diagramas de acordo com o módulo e o pacote que o conjunto de classes representa. Nos próximos tópicos, são apresentados os diagramas do módulo servidor e do módulo cliente e as classes que representam os Web Services. Foram definidos métodos getters e setters para os atributos de cada classe, mas os mesmos não estão sendo apresentados para não comprometer o entendimento dos diagramas Módulo servidor As classes do módulo servidor estão divididas nos pacotes explanados no Quadro 16.

40 39 Definição dos pacotes do módulo servidor Pacote econserver econserver.ctrl econserver.dao econserver.db econserver.model econserver.rmi econserver.ui econserver.util econaxisws Definição define a classe CtrlMainApp, que é onde se inicia módulo servidor contém as classes que fazem o controle do acesso aos métodos que utilizam conexões com o banco de dados contém as classes que persistem os dados no banco de dados da aplicação contém três classes de configuração do banco de dados e do pool de conexões contém as classes dos objetos que serão persistidos no banco de dados e que serão utilizados para troca de mensagens entre os módulos contém as classes necessárias para a comunicação RMI do módulo servidor com o módulo cliente. Possui também a implementação dos métodos do módulo servidor que poderão ser invocados remotamente contém as classes de definição da interface gráfica do módulo contém as classes que tratarão as mensagens recebidas do Web Service antes de enviá-las aos clientes ativos contém as classes responsáveis pelos Web Services disponibilizados contém a interface do módulo cliente para a comunicação com o mesmo econclientmonitor.rmi através do RMI Quadro 16 - Definição dos pacotes do módulo servidor São explanados a partir de agora os pacotes considerados mais importantes para funcionalidade deste módulo. A Figura 10 ilustra as classes do pacote econserver.ui. Figura 10 - Pacote econserver.ui A classe UIServer recebe em seu construtor uma instância da classe ServerRMI, e é a classe principal deste módulo. É responsável pela interface gráfica e também por publicar os Web Services. Nesta classe também é iniciada uma thread do tipo

41 40 ThreadListenMessagesFromWS, responsável por ouvir as mensagens enviadas ao Web Service, e uma outra thread do tipo ThreadLoggedUsers, que é acionada quando o administrador solicita a lista de usuários conectados ao servidor. As classes do pacote econserver.db são apresentadas na Figura 11. Figura 11 - Pacote econserver.db A classe ConfigurationFile faz a leitura do arquivo de configuração do banco de dados, chamado dbconfig.properties, que está localizado dentro da pasta etc na pasta raiz do projeto. Esta classe carrega as informações deste arquivo e instancia um objeto do tipo DBConfiguration. A classe ConnectionPool utiliza um objeto do tipo DBConfiguration para a criação de um pool de conexões com o banco de dados. Os métodos checkin e checkout gerenciam as conexões que estão ativas com o banco de dados. As classes do pacote econserver.rmi estão ilustradas na Figura 12. A classe ServerRMI é a classe que disponibiliza o servidor RMI para que os módulos cliente se conectem ao módulo servidor. A classe LoginUser, que implementa a interface Serializable, é o modelo do objeto utilizado para que o cliente efetue o login. A classe UserAuthImpl, que implementa a interface UserAuth, e contém os métodos que podem ser invocados remotamente pelos clientes ativos. Nesta classe, pode-se destacar os métodos que buscam informações no banco de dados relacional do módulo servidor, como por exemplo os métodos SQLgetPlantInfo e SQLselectIdPlant.

42 41 Figura 12 - Pacote econserver.rmi A Figura 13 apresenta as classes do pacote econaxisws. Figura 13 - Pacote econaxisws A classe EconWS é a classe responsável pelos métodos do Web Service. Esta classe possui um atributo do tipo MessageHandler, que funciona como um gerenciador das mensagens de erro recebidas através do método pushfisservermessage, que é o método mais importante para o monitoramento dos servidores. Este método também é responsável por

43 42 enviar estas mensagens ao atributo msghandler. A classe MessageHandler é a principal classe do pacote. É a classe responsável pelo gerenciamento das mensagens recebidas. A classe KERNTypeTelegram é a classe responsável pela consistência das mensagens recebidas. O método splitkerntypetelegram faz a consistência das mensagens recebidas e as envia para o objeto msghandler, que as organiza em uma fila. As mensagens enfileiradas serão buscadas pela thread do tipo ThreadListenMessagesFromWS da classe UIServer, explicada anteriormente. A classe FISMessage representa o modelo dos objetos das mensagens que serão trabalhadas por estas classes Módulo Cliente. As classes do módulo servidor estão divididas nos pacotes explanados no Quadro 17. Definição dos pacotes do módulo cliente Pacote econclientmonitor.ctrl econclientmonitor.rmi econclientmonitor.ui econclientmonitor.util econserver.rmi Definição define a classe CtrlGeneral, que faz o controle de acesso aos métodos que serão invocados remotamente contém as classes necessárias para a comunicação RMI do módulo cliente com o módulo servidor. Possui também a implementação dos métodos do módulo cliente que poderão ser invocados remotamente contém as classes de definição da interface gráfica do módulo contém as classes que tratarão as mensagens recebidas do módulo servidor contém a interface do módulo servidor para a comunicação com o mesmo através do RMI Quadro 17 - Definição dos pacotes do módulo cliente As classes do pacote econclientmonitor.ui são apresentadas na Figura 14. Figura 14 - Pacote econclientmonitor.ui

44 43 A classe UILoginClient é responsável pela tela de login do módulo cliente. Esta classe é a responsável por conectar o módulo cliente ao módulo servidor, informando o endereço e porta do servidor RMI, usuário e senha. A classe UIMainClient é responsável pela tela principal deste módulo. É através desta classe que o usuário poderá interagir com o sistema. A classe UIDialogCheckCriticalMessage é a classe responsável pela tela de registro de ações tomadas sobre os erros críticos. As threads do pacote econclientmonitor.ui.thread representam as principais funcionalidades deste módulo. As classes responsáveis pela atualização das telas de monitoramento são as classes ThreadMonitoring, ThreadKernErrorMessages e ThreadCriticalMessages, enquanto a classe ThreadReports é a responsável pela busca de dados solicitados pelo usuário através da tela de relatórios da classe UIMainClient. A Figura 15 detalha as classes do pacote econclientmonitor.util. Figura 15 - Pacote econclientmonitor.util.telegram As classes FISMessage e KERNTypeTelegram desempenham o mesmo papel explicado no módulo servidor. A classe KERNCriticalMessage é utilizada para tratar uma mensagem de erro considerada crítica, e que será mostrada separadamente na tela de monitoramento. A classe KERNTeleHandler é a classe responsável por gerenciar, classificar e entregar à interface a mensagem tratada e sua devida classificação quanto à criticidade.

45 44 A Figura 16 apresenta as classes do pacote econclientmonitor.rmi. Figura 16 - Pacote econclientmonitor.rmi A classe ClientServerRMI é responsável por iniciar a conexão do módulo cliente ao servidor RMI. A classe ConnectionP2PImpl, que implementa a interface ConnectionP2P, contém os métodos do cliente que podem ser invocados remotamente Diagrama de atividades O diagrama de atividades foi desenvolvido para facilitar a visualização do processo de determinadas situações do sistema. É essencialmente um gráfico de fluxo que mostra o controle de uma atividade para outra. O diagrama da Figura 17 mostra as atividades do módulo servidor quando inicializado e quando recebe telegramas através do Web Service.

46 45 Figura 17 - Diagrama de atividades do módulo servidor Quando o módulo é iniciado, inicia-se o servidor RMI pelo qual os clientes se conectam ao módulo servidor, publicam-se os serviços e então o servidor fica à espera de novas mensagens de erro. Quando uma mensagem é recebida, ela é consistida, gravada no banco de dados e tratada internamente. O servidor busca os clientes ativos e verifica quais clientes devem receber esta mensagem. Caso o cliente deva receber a mensagem, a mesma é enviada, caso contrário, busca-se o próximo cliente ativo. Em caso de ocorrência de exceção por perda de conexão com algum cliente, o mesmo é descartado e é dado prosseguimento aos próximos clientes ativos. A Figura 18 representa as atividades do módulo cliente ao ser inicializado e ao receber uma mensagem de erro do módulo servidor.

47 46 Figura 18 - Diagrama de atividades do módulo cliente Ao iniciar o módulo cliente, é solicitado o endereço e a porta do servidor, nome de usuário e senha para o login. Se os dados forem validados, é apresentada a tela principal e é feita a conexão RMI com o servidor, e o módulo aguarda o recebimento de mensagens de erro. Ao receber uma mensagem, o módulo trata e classifica a mensagem. Se a mensagem for considerada crítica, é apresentada na tela de monitoramento de erros críticos e na tela de monitoramento geral. Caso a mensagem não seja crítica, esta é apresentada apenas no monitoramento geral. As mensagens classificadas como críticas ficam aguardando o registro de ações por parte do usuário. Ao solicitar o registro de uma ação, um diálogo para o cadastro de ações se abrirá e enviará o registro ao servidor. Após o registro da ação, a mensagem desaparecerá da tela de monitoramento crítico.

48 Modelo Entidade Relacional (MER) O MER tem como objetivo representar de forma visual as estruturas de dados de um banco de dados. Para desenhar o MER deste sistema foi utilizada a ferramenta DB Designer 4 da fabforce.net. Como banco de dados, é utilizado o PostgreSQL 9.0 e para o gerenciamento e criação dos objetos é utilizado o pgadmin III. A Figura 19 mostra o MER da estrutura de banco de dados utilizada neste trabalho. Figura 19 - MER do banco de dados Os dados persistidos no servidor estão distribuídos nas seguintes tabelas: a) tabela plant guarda informações das fábricas monitoradas: identificação e descrição; b) tabela server guarda informações dos servidores de cada fábrica; c) tabela instance guarda informações das instâncias CS3 de cada servidor; d) tabela user guarda informações dos usuários do sistema; e) tabela message type guarda os tipos de mensagem de erro e sua descrição; f) tabela message data guarda os dados das mensagens de erro capturadas nos servidores monitorados e enviadas aos Web Services;

49 48 g) tabela checked messages guarda as informações das mensagens de erro já tratadas e as ações corretivas tomadas pelo usuário para a solução do problema; h) tabela client Peer To Peer (P2P) guarda temporariamente as informações de endereço de rede e porta utilizada pelo usuário para acessar o sistema; i) tabela plant_client P2P guarda a lista de quais fábricas o usuário monitora; j) tabela kern error types guarda informações sobre os diferentes tipos de erros. O campo active indica se o erro deve ou não ser mostrado no monitoramento; k) tabela kern color codes guarda a relação do erro com a cor a qual ele deve aparecer no cliente de monitoramento de acordo com sua criticidade. 3.3 IMPLEMENTAÇÃO A seguir são mostradas as técnicas e ferramentas utilizadas e a operacionalidade da implementação Técnicas e ferramentas utilizadas O trabalho foi implementado sob o paradigma da orientação a objetos, utilizando a linguagem Java na versão 6. A mesma linguagem foi utilizada para desenvolver o módulo servidor e o módulo cliente. Como ambiente de desenvolvimento, foi utilizado o Netbeans IDE na sua versão O Sistema Gerenciador de Banco de Dados (SGBD) utilizado foi o PostgreSQL 9.0. Para auxiliar na publicação e na integração do Web Service, optou-se pela utilização do servidor web Apache Tomcat 7 e do framework Apache Axis2/Java, que oferece todo o suporte a comunicação entre aplicações utilizando o protocolo SOAP, ambos disponibilizados pela Apache Software Foundation Implementação do sistema O objetivo deste trabalho é implementar um sistema de monitoramento em dois

50 49 módulos, servidor e cliente, e utilizando Web Service, visando receber informações dos processos produtivos do sistema de controle e planejamento de produção das fábricas de um grupo de montadoras de automóveis através de um script escrito em PERL. Estas informações são tratadas e persistidas no módulo servidor, e enviadas aos módulos clientes ativos. No Quadro 18 é apresentada a classe que implementa os métodos disponibilizados como Web Service. Estes métodos são descritos no arquivo econ.wsdl, que é apresentado no apêndice A. Quadro 18 Classe econws O método pushfisservermessage é o método principal do Web Service e que será chamado através dos scripts PERL dos servidores. O método inserttelegram da classe MessageHandler insere os telegramas recebidos numa fila de processamento do módulo servidor. No Quadro 19 é apresentado um comentário com o procedimento executado pelo script PERL e a definição do endereço do Web Service.

51 50 Quadro 19 Procedimento do script PERL e definição do endereço do arquivo WSDL No apêndice B é apresentado o laço principal do script PERL, onde acontece a chamada do método pushfisservermessage. No módulo servidor, a thread ThreadListenMessagesFromWS ficará ouvindo as mensagens que serão recebidas através do Web Service. O método run desta thread é apresentado no Quadro 20. As mensagens captadas por esta thread são tratadas, gerenciadas e persistidas no módulo servidor através da chamada do método gettelegramfromwebservice. Após o tratamento destas mensagens, o módulo servidor disponibiliza estas mensagens aos clientes ativos, que interpretam as mensagens e verificam se devem ou não mostrar a informação no módulo cliente. A comunicação entre o módulo servidor e os módulos cliente é feita através de um servidor RMI, o qual é disponibilizado na execução do módulo servidor. É a partir deste servidor RMI que é feita a autenticação dos usuários, o envio de mensagens de erro detectadas e são enviadas as ações tomadas sobre os erros críticos, esta última feita do módulo cliente para o módulo servidor.

52 51 Quadro 20 - Método run da thread ThreadListenMessagesFromWS Operacionalidade da implementação A operacionalidade da implementação será apresentada através da simulação de casos de utilização do sistema, ou seja, serão detalhadas as operações em nível de usuário para a utilização dos recursos do sistema. De uma forma geral a ferramenta econ tem por objetivo disponibilizar acesso ao módulo servidor através do módulo cliente para facilitar o monitoramento dos processos produtivos do sistema de planejamento e controle de produção. Nas próximas seções serão abordadas as principais funcionalidades do módulo servidor e do módulo cliente.

53 Módulo Servidor O módulo servidor do econ está instalado em um servidor que tem acesso à rede do grupo de montadoras. O acesso ao módulo está restrito aos administradores do servidor. Sendo assim, não é feito controle de usuário, pois este controle já é feito diretamente no servidor. As principais funções do administrador do sistema são manter os cadastros de fábricas, servidores, instâncias e usuários e gerenciar a associação de quais fábricas serão monitoradas por quais usuários. Após a inicialização do módulo, os Web Services são publicados e é inicializado o servidor RMI para a comunicação com os módulos cliente. A tela principal deste módulo é apresentada conforme Figura 20. Figura 20 - Tela principal do módulo servidor As funções dos botões são vistas no Quadro 21, listados da esquerda para a direita, enquanto a estrutura de menus é descrita no Quadro 22. Botão Descrição 1º Fechar a aba ativa Ir para a próxima aba da 2º esquerda Ir para a próxima aba da 3º direita Quadro 21 - Estrutura da barra de ferramentas

54 53 Menu Submenu Descrição File Exit Fecha o módulo servidor Maintenance Manage Plant Manter fábricas Manage Server Manter servidores Manage Instance Manter instâncias Manage User Manter usuários Manage User x Plant Associar usuários e fábricas View Online Users Ver usuários conectados Quadro 22 - Estrutura de menus Ao clicar no menu Maintenance > Manage Plant, o sistema abrirá a aba de manutenção de fábricas, apresentado na Figura 21. É possível inserir, alterar, excluir e visualizar as fábricas cadastradas. Este cadastro é utilizado para identificar quais as fábricas serão monitoradas pelo econ. Figura 21 - Tela de manutenção de fábricas Para cadastrar uma nova fábrica basta clicar no botão Add e preencher os campos id e plant, conforme Figura 22. Para editar ou excluir um registro o administrador deve selecioná-lo na tabela e clicar em Change ou Delete. Os campos para edição são os mesmos do cadastro. Figura 22 - Tela para cadastro de nova fábrica

55 54 Para manter os servidores, o administrador deve clicar no menu Maintenance > Manage Servers. O sistema abrirá a aba de manutenção de servidores, onde é possível inserir, alterar, excluir e visualizar os servidores cadastrados, como mostra a Figura 23. Figura 23 - Tela de manutenção de servidores Para adicionar um novo servidor deve-se clicar no botão Add, e preencher os campos necessários. Para editar ou excluir um registro o administrador deve selecioná-lo na tabela e clicar em Change ou Delete. Os campos para edição são os mesmos do cadastro. Deve-se obrigatoriamente associá-lo a uma fábrica cadastrada no sistema. A Figura 24 mostra a tela de cadastro de um novo servidor. Figura 24 - Tela para cadastro de novo servidor A aba de manutenção das instâncias é habilitada ao clicar no menu Maintenance > Manage Instances, conforme mostra a Figura 25. É possível inserir, alterar, excluir e visualizar as instâncias cadastradas.

56 55 Figura 25 - Tela de manutenção de instâncias Para adicionar um novo servidor deve-se clicar no botão Add, e preencher os campos necessários. Deve-se obrigatoriamente associá-lo a uma fábrica e um servidor cadastrados no sistema. Para editar ou excluir um registro o administrador deve selecioná-lo na tabela e clicar em Change ou Delete. Os campos para edição são os mesmos do cadastro. A Figura 26 mostra a tela de cadastro de uma nova instância. Figura 26 - Tela para cadastro de nova instância A manutenção dos usuários é feita através do menu Maintenance > Manage Users. Ao abrir esta aba, o administrador visualizará a lista dos usuários cadastrados. Através desta aba, é possível inserir, alterar ou excluir usuários. A Figura 27 mostra a tela de manutenção de usuários.

57 56 Figura 27 - Tela de manutenção de usuários Para adicionar novos usuários, basta clicar no botão Add e preencher os campos necessários. Para editar ou excluir um registro o administrador deve selecioná-lo na tabela e clicar em Change ou Delete. Os campos para edição são os mesmos do cadastro. Todo usuário cadastrado no módulo servidor pode autenticar-se no módulo cliente do econ, e pode visualizar o monitoramento das plantas associadas a ele. A Figura 28 apresenta a tela de cadastro de usuários. Figura 28 - Tela para cadastro de novo usuário A associação de quais fábricas cada usuário deve monitorar é feita pelo administrador do sistema através do menu Maintenance > Manage Users X Plant. A tela de manutenção da associação de usuários e fábricas está ilustrada na Figura 29. O sistema carrega os usuários cadastrados e os carrega em uma lista (Figura 29(1)). As fábricas não associadas ao usuário selecionado aparecem na lista Non Associated Plants (Figura 29(2)), enquanto as fábricas associadas ao usuário aparecem na lista Associated Plants

58 57 (Figura 29(3)). Figura 29 - Tela de manutenção da associação de usuários e fábricas Para associar uma fábrica ao usuário selecionado, deve-se selecionar a fábrica desejada na lista de fábricas não associadas e clicar no botão >> (Figura 29(4)). Para desassociar uma fábrica associada ao usuário, deve-se selecionar a fábrica na lista de fábricas associadas e clicar no botão << (Figura 29(5)) Módulo Cliente O módulo cliente pode ser instalado em qualquer computador que possua acesso à rede do grupo e possua o Java Runtime Environment versão 6 ou superior instalado. Ao acessar este módulo, será apresentada a tela de autenticação, que solicitará ao usuário o endereço do servidor, a porta para conexão RMI, o usuário e a senha, conforme mostra a Figura 30.

59 58 Figura 30 - Tela de autenticação do módulo cliente Após a autenticação do usuário, é apresentada a tela principal do módulo cliente com a aba de monitoramento ativa (Figura 31(1)). Esta aba é dividida em três partes: lista das plantas monitoradas pelo usuário (Figura 31(2)), tabela dos erros das plantas monitoradas (Figura 31(3)) e o campo com a descrição do último erro recebido (Figura 31(4)). A partir do momento em que esta tela está ativa, o módulo cliente já começa a receber as mensagens enviadas pelo servidor. Figura 31 - Tela principal do módulo cliente As mensagens recebidas são classificadas de três maneiras. As mensagens na cor verde são mensagens que não precisam ser verificadas, pois são apenas mensagens informativas sobre algum processo do sistema. As mensagens em amarelo são erros que podem vir a causar algum impacto na linha de produção, porém não causam impacto imediato. As mensagens em vermelho são consideradas críticas e impactam diretamente o funcionamento do sistema na

60 59 linha de montagem, e devem ser analisadas e tratadas imediatamente. A classificação dos erros no sistema de monitoramento é feita pelo administrador do sistema diretamente no banco de dados do servidor, e esta classificação foi feita pelo grupo dos analistas mais experientes da equipe de suporte AMS. A lista de fábricas monitoradas serve como um filtro para as mensagens de erro, ou seja, ao selecionar uma fábrica, serão mostrados na tabela de erros apenas os erros referentes à fábrica selecionada. Para visualizar todos os erros, o usuário deve selecionar neste campo o valor ALL PLANTS. A aba de monitoramento de mensagens críticas é mostrada na Figura 32. Esta aba conterá apenas os erros classificados como críticos pelo administrador do módulo servidor que impactam diretamente a produção e que podem resultar numa parada da linha de produção. Figura 32 - Aba de monitoramento de mensagens críticas Esta aba foi criada para diminuir o tempo de detecção de problemas críticos, para que os mesmos sejam tratados antes que causem qualquer impacto à linha de montagem. É uma tela simples com uma tabela informando a fábrica, o servidor, a instância, o tipo e o conteúdo da mensagem. Na sexta coluna da tabela o usuário pode visualizar a situação do erro, que pode ser true, para o erro que já foi tratado por um analista, ou false, que ainda não foi tratado e pode estar impactando a produção. Se a situação do erro estiver true, na sétima coluna da tabela estarão registradas as ações tomadas pelo analista que tratou o erro. Para o usuário registrar uma ação tomada em um erro com o estado false ou ver as informações de um erro, basta dar um duplo clique sobre o mesmo e a tela mostrada na Figura

61 60 33 estará disponível. Esta tela está dividida em duas partes: informações sobre o erro Figura 33(1)) e salvar informações no banco de dados central (Figura 33(2)). Figura 33 - Tela de visualização de mensagens críticas Para salvar uma ação tomada e atribuir o status true para o erro, é preciso selecionar seu usuário na lista de usuários (Figura 33(3)), descrever a ação tomada e clicar no botão Save (Figura 33(4)). No módulo cliente ainda tem duas funções, as quais podem ser acessadas através do menu View da tela principal: verificar a lista de possíveis erros com suas descrições (Figura 34) e buscar o histórico de erros detectados pelo econ (Figura 35). Na aba de mensagens de erro é possível buscar um erro específico utilizando o campo de filtro (Figura 34(1)). Estes erros são inseridos diretamente na base de dados pelo administrador do sistema, especificando o código do erro, a sua descrição e a sua criticidade. Na aba de relatórios, é possível filtrar os erros ocorridos por fábrica, servidor, instância, tipo, data e hora (Figura 35(1)). Para gerar o relatório de acordo com os filtros do usuário, basta clicar no botão Select (Figura 35(2)). Se o usuário não usar nenhum filtro, todos os erros detectados pelo monitoramento serão apresentados. O resultado da busca aparece logo abaixo em uma tabela (Figura 35(3)).

62 61 Figura 34 - Tela de visualização dos possíveis erros Figura 35 - Tela de relatório de erros Simulador de mensagens No módulo servidor foi desenvolvido um simulador de envio e recebimento de mensagens para auxiliar na parte de testes de tratamento de mensagens e de comunicação entre os módulos da ferramenta. Esta funcionalidade foi desenvolvida para possibilitar a realização de testes locais em computadores que não fazem parte da rede do grupo de

63 62 montadoras de veículos, ou seja, não estão na mesma rede dos servidores de produção das fábricas. A tela do simulador de mensagens é apresentada na Figura 36. Figura 36 - Tela do simulador de mensagens As mensagens que serão transmitidas pelo simulador devem ser carregadas de um arquivo texto. Ao clicar no botão Select File (Figura 36(1)) o usuário seleciona o arquivo desejado, e então clica no botão Load File (Figura 36(2)). As mensagens do arquivo selecionado serão carregadas na tabela (Figura 36(3)). Ao selecionar uma mensagem na tabela, os dados da mesma serão mostrados na área Attributes (Figura 36(4)). Para enviar esta mensagem basta clicar no botão Send Message (Figura 36(5)). Ao enviar a mensagem, é disparada uma thread que simula uma mensagem já tratada pelo Web Service, a qual é transmitida através de RMI aos clientes ativos. Para que o simulador consiga interpretar corretamente as mensagens contidas no arquivo texto, todas devem estar no mesmo formato do exemplo apresentado no Quadro 23. Cada mensagem deve conter a identificação da fábrica, do servidor e da instância, o tipo do erro, e o dado da mensagem, todos separados por vírgula.

64 63 Quadro 23 - Exemplo de um arquivo com mensagens de erro 3.4 RESULTADOS E DISCUSSÃO Os resultados obtidos com o término do trabalho foram satisfatórios, pois com a utilização do econ o processo de monitoramento foi facilitado, aumentando a eficácia na detecção de problemas, a qualidade do serviço e a produtividade dos analistas de suporte e sustentação do sistema de planejamento e controle de produção. Foram desenvolvidos os dois módulos propostos. O módulo servidor, que disponibiliza os serviços, o servidor RMI, e gerencia o sistema, e o módulo cliente, no qual é feito um controle de acesso de usuários e que é capaz de receber informações do servidor e disponibilizar ao usuário uma interface de monitoramento dos processos produtivos. Todas as informações relevantes ao monitoramento são registradas no banco de dados do servidor. Quanto ao desempenho, os dois módulos se mostraram eficientemente rápidos. Quanto ao desempenho do Web Service, a operação que se acreditava ser demorada, que é o recebimento de muitas mensagens de diferentes servidores ao mesmo tempo, se mostrou muito eficaz e apresentou ótimos resultados durante os testes de carga. A utilização de Web Services demonstra ser uma alternativa viável e interessante para o monitoramento dos processos produtivos de sistemas de planejamento e controle de produção, principalmente pela flexibilidade e interoperabilidade que pode ser observada. Sistemas que foram escritos em diferentes linguagens e operam em plataformas distintas podem trabalhar juntos sem maiores problemas. Após a realização dos testes de implementação, a ferramenta foi disponibilizada aos analistas para testes de viabilidade e usabilidade. De modo geral, a ferramenta foi bem aceita pelos usuários, os quais contribuíram para a melhoria da mesma através de sugestões e críticas. Quanto à usabilidade, um dos pontos mais relevantes relatados é a possibilidade de monitorar remotamente diversas fábricas de diferentes países do mundo com apenas uma ferramenta, a qual recebe de forma organizada as informações de todas elas. A ferramenta foi considerada relevante pelos usuários, pois fornece informações em tempo real sobre a situação dos processos produtivos da fábrica, que são fundamentais para o bom

65 64 funcionamento do sistema de planejamento e controle. A implementação de uma tela que mostra apenas os erros críticos foi sugerida pelos usuários para diminuir o tempo de detecção de um problema grave na produção. Outra sugestão foi adicionar ao banco de dados o campo active à tabela KernErrorType, a qual informa se este erro deve ser analisado ou é um erro o qual a equipe já tem conhecimento e não precisa atuar. Este erro, classificado como conhecido pelo administrador do sistema, é filtrado nas telas de monitoramento, aumentado a eficiência na identificação de problemas. O Quadro 24 apresenta um comparativo com os trabalhos correlatos. Por se tratar do monitoramento de um sistema em específico, não foi encontrado nenhum trabalho com o mesmo objetivo específico deste, então o critério de comparação foi o uso das tecnologias e funcionalidades próximas. Quadro 24 - Comparativo com trabalhos correlatos Pode-se verificar que as plataformas de desenvolvimento variam de acordo com a linguagem de programação na qual os trabalhos foram desenvolvidos. Todos os trabalhos apresentam sistemas gerenciadores de bancos de dados diferentes e utilizam a tecnologia de Web Services. Apesar dos diferentes objetos de monitoramento, percebe-se que os objetivos principais dos trabalhos são similares.

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 13 Web Services Web Services

Leia mais

2 Conceitos relativos a Web services e sua composição

2 Conceitos relativos a Web services e sua composição 15 2 Conceitos relativos a Web services e sua composição A necessidade de flexibilidade na arquitetura das aplicações levou ao modelo orientado a objetos, onde os processos de negócios podem ser representados

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

UNIVERSIDADE. Sistemas Distribuídos

UNIVERSIDADE. Sistemas Distribuídos UNIVERSIDADE Sistemas Distribuídos Ciência da Computação Prof. Jesus José de Oliveira Neto Web Services Web Services Existem diferentes tipos de comunicação em um sistema distribuído: Sockets Invocação

Leia mais

Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) São Paulo, 2011 Universidade Paulista (UNIP) Service Oriented Architecture (SOA) Prof. MSc. Vladimir Camelo vladimir.professor@gmail.com 04/09/11 vladimir.professor@gmail.com 1 04/09/11 vladimir.professor@gmail.com

Leia mais

Trabalho de Sistemas Distribuídos

Trabalho de Sistemas Distribuídos Cássio de Olivera Ferraz Trabalho de Sistemas Distribuídos Petrópolis 2015, v-1.0 Cássio de Olivera Ferraz Trabalho de Sistemas Distribuídos Trabalho sobre sistemas distribuídos e suas tecnologias. Universidade

Leia mais

Consumindo um Web Service através de uma Aplicação Comercial em Android. Alex Malmann Becker www.alex.porthal.com.br alex@porthal.com.

Consumindo um Web Service através de uma Aplicação Comercial em Android. Alex Malmann Becker www.alex.porthal.com.br alex@porthal.com. Consumindo um Web Service através de uma Aplicação Comercial em Android Alex Malmann Becker www.alex.porthal.com.br alex@porthal.com.br 08/2014 Agenda Introdução Conceitos Web Service Por que utilizar

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

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil Projeto 914 BRA5065 - PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 02 IMPLANTAÇÃO DE 1 (UM)

Leia mais

Arquitetura de Software: Uma Central para Gestão da execução de serviços

Arquitetura de Software: Uma Central para Gestão da execução de serviços Arquitetura de Software: Uma Central para Gestão da execução de serviços ADILSON FERREIRA DA SILVA Centro Paula Souza São Paulo Brasil afs.software@gmail.com Prof.a. Dr.a. MARILIA MACORIN DE AZEVEDO Centro

Leia mais

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio 32 3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio Este capítulo apresenta o framework orientado a aspectos para monitoramento e análise de processos de negócio

Leia mais

SOA Introdução. SOA Visão Departamental das Organizações

SOA Introdução. SOA Visão Departamental das Organizações 1 Introdução A Organização é a forma pela qual nós coordenamos nossos recursos de todos os tipos para realizar o trabalho que nos propusemos a fazer. A estrutura de nossas organizações manteve-se basicamente

Leia mais

Sistema de Informações da Produção Utilizando o Método Kanban

Sistema de Informações da Produção Utilizando o Método Kanban Ciências da Computação FURB Trabalho de Conclusão de Curso (TCC) Sistema de Informações da Produção Utilizando o Método Kanban Alzir Wagner Orientador: Wilson Pedro Carli Fevereiro de 2008 Roteiro de apresentação

Leia mais

Web Services. (Introdução)

Web Services. (Introdução) Web Services (Introdução) Agenda Introdução SOA (Service Oriented Architecture) Web Services Arquitetura XML SOAP WSDL UDDI Conclusão Introdução Comunicação distribuída Estratégias que permitem a comunicação

Leia mais

Uma Proposta de Tecnologia Embarcada na Internação Domiciliar Capítulo 3 Implementação do SMD 93

Uma Proposta de Tecnologia Embarcada na Internação Domiciliar Capítulo 3 Implementação do SMD 93 Capítulo 3 Implementação do SMD 93 CAPÍTULO 3 IMPLEMENTAÇÃO DO SMD Este capítulo reserva-se à apresentação da implementação do SMD tomando como partida o desenvolvimento do Projeto Preliminar que consta

Leia mais

MRP II. Planejamento e Controle da Produção 3 professor Muris Lage Junior

MRP II. Planejamento e Controle da Produção 3 professor Muris Lage Junior MRP II Introdução A lógica de cálculo das necessidades é conhecida há muito tempo Porém só pode ser utilizada na prática em situações mais complexas a partir dos anos 60 A partir de meados da década de

Leia mais

Desenvolvendo e Integrando Serviços Multiplataforma de TV Digital Interativa

Desenvolvendo e Integrando Serviços Multiplataforma de TV Digital Interativa Desenvolvendo e Integrando Serviços Multiplataforma de TV Digital Interativa Agenda Introdução Aplicações interativas de TV Digital Desafios de layout e usabilidade Laboratório de usabilidade Desafios

Leia mais

Service Oriented Architecture SOA

Service Oriented Architecture SOA Service Oriented Architecture SOA Arquitetura orientada aos serviços Definição: Arquitetura de sistemas distribuídos em que a funcionalidade é disponibilizada sob a forma de serviços (bem definidos e independentes)

Leia mais

3 Serviços na Web (Web services)

3 Serviços na Web (Web services) 3 Serviços na Web (Web services) 3.1. Visão Geral Com base na definição do Word Wide Web Consortium (W3C), web services são aplicações autocontidas, que possuem interface baseadas em XML e que descrevem

Leia mais

MRP / MRP II / ERP (capítulos 11 e 12)

MRP / MRP II / ERP (capítulos 11 e 12) MRP / MRP II / ERP (capítulos 11 e 12) As siglas MRP, MRP II e ERP são bastante difundidas e significam: MRP Materials Requirements Planning Planejamento das Necessidades de Materiais; MRP II Resource

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

Gerência de Redes e Serviços de Comunicação Multimídia

Gerência de Redes e Serviços de Comunicação Multimídia UNISUL 2013 / 1 Universidade do Sul de Santa Catarina Engenharia Elétrica - Telemática 1 Gerência de Redes e Serviços de Comunicação Multimídia Aula 3 Gerenciamento de Redes Cenário exemplo Detecção de

Leia mais

Dados x Informações. Os Sistemas de Informação podem ser:

Dados x Informações. Os Sistemas de Informação podem ser: CONCEITOS INICIAIS O tratamento da informação precisa ser visto como um recurso da empresa. Deve ser planejado, administrado e controlado de forma eficaz, desenvolvendo aplicações com base nos processos,

Leia mais

SUMÁRIO CAPÍTULO 1 - INTRODUÇÃO 19 CAPÍTULO 2 - CONCEITOS 25

SUMÁRIO CAPÍTULO 1 - INTRODUÇÃO 19 CAPÍTULO 2 - CONCEITOS 25 SUMÁRIO LISTA DE FIGURAS LISTA DE TABELAS LISTA DE SIGLAS E ABREVIATURAS Pág. CAPÍTULO 1 - INTRODUÇÃO 19 CAPÍTULO 2 - CONCEITOS 25 2.1 A tecnologia de orientação a objetos 25 2.1.1 Projeto de software

Leia mais

Essencial ao Desenvolvimento de Software

Essencial ao Desenvolvimento de Software Documento de Requisitos Essencial ao Desenvolvimento de Software De que se trata o artigo? Apresenta o documento de requisitos de software, destacando-o como um dos principais documentos pertinentes ao

Leia mais

Acadêmico: Marciane Schotten Prof. Orientador: Ricardo Alencar de Azambuja

Acadêmico: Marciane Schotten Prof. Orientador: Ricardo Alencar de Azambuja PROTÓTIPO DE UMA APLICAÇÃO MÓVEL PARA LOCAÇÃO DE VEÍCULOS UTILIZANDO J2ME Acadêmico: Marciane Schotten Prof. Orientador: Ricardo Alencar de Azambuja Roteiro da apresentação Introdução Objetivos Fundamentação

Leia mais

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Tópicos Motivação e Objetivos LP e SOA Processo ADESE

Leia mais

Programação WEB Introdução

Programação WEB Introdução Programação WEB Introdução Rafael Vieira Coelho IFRS Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Sul Campus Farroupilha rafael.coelho@farroupilha.ifrs.edu.br Roteiro 1) Conceitos

Leia mais

acoplamento Exprime o grau de conexão entre os módulos; os módulos de um software devemapresentar um baixo coeficiente de acoplamento.

acoplamento Exprime o grau de conexão entre os módulos; os módulos de um software devemapresentar um baixo coeficiente de acoplamento. SOA Arquitetura Orientada a Serviços Conceitos e Aplicações Prof. MSc. Edilberto Silva edilms@yahoo.com/ http://edilms.eti.br Gestão de TI Conceitode SOA SOA - Service OrientedArchitecture (Arquitetura

Leia mais

Integração de Dados Plataforma Hub Magento E-Commerce

Integração de Dados Plataforma Hub Magento E-Commerce Integração de Dados Plataforma Hub Magento E-Commerce Facilitando Negócios Conectando softwares com Magento Plataforma de E-Commerce Integração de Dados Plataforma Hub Magento E-Commerce Este documento

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos LICENCIATURA EM COMPUTAÇÃO Prof. Adriano Avelar Site: www.adrianoavelar.com Email: eam.avelar@gmail.com Mecanismos de Comunicação Protocolos de Aplicação Mecanismos de comunicação

Leia mais

www.f2b.com.br 18/04/2006 Micropagamento F2b Web Services Web rev 00

www.f2b.com.br 18/04/2006 Micropagamento F2b Web Services Web rev 00 www.f2b.com.br 18/04/2006 Micropagamento F2b Web Services Web rev 00 Controle de Revisões Micropagamento F2b Web Services/Web 18/04/2006 Revisão Data Descrição 00 17/04/2006 Emissão inicial. www.f2b.com.br

Leia mais

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula Complementar - MODELO DE REFERÊNCIA OSI Este modelo se baseia em uma proposta desenvolvida pela ISO (International Standards Organization) como um primeiro passo em direção a padronização dos protocolos

Leia mais

Roteiro. Arquitetura. Tipos de Arquitetura. Questionário. Centralizado Descentralizado Hibrido

Roteiro. Arquitetura. Tipos de Arquitetura. Questionário. Centralizado Descentralizado Hibrido Arquitetura Roteiro Arquitetura Tipos de Arquitetura Centralizado Descentralizado Hibrido Questionário 2 Arquitetura Figura 1: Planta baixa de uma casa 3 Arquitetura Engenharia de Software A arquitetura

Leia mais

Protocolos de gerenciamento

Protocolos de gerenciamento Protocolos de gerenciamento Os protocolos de gerenciamento têm a função de garantir a comunicação entre os recursos de redes homogêneas ou não. Com esse requisito satisfeito, operações de gerenciamento

Leia mais

PROGRAMA DE MBA em Gestão e Engenharia do Produto. O Produto Internet e suas Aplicações

PROGRAMA DE MBA em Gestão e Engenharia do Produto. O Produto Internet e suas Aplicações Universidade de São Paulo Escola Politécnica Programa de Educação Continuada em Engenharia PROGRAMA DE MBA em Gestão e Engenharia do Produto O Produto Internet e suas Aplicações Tecnologias de Informação

Leia mais

NETALARM GATEWAY. Manual do Usuário

NETALARM GATEWAY. Manual do Usuário Índice 1. Introdução...3 2. Requisitos Mínimos de Instalação...3 3. Instalação...3 4. Inicialização do Programa...5 5. Abas de Configuração...6 5.1 Aba Serial...6 5.2 Aba TCP...7 5.2.1 Opções Cliente /

Leia mais

Fase 1: Engenharia de Produto

Fase 1: Engenharia de Produto Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os

Leia mais

Web Services: estudo de caso envolvendo uma aplicação B2B

Web Services: estudo de caso envolvendo uma aplicação B2B Web Services: estudo de caso envolvendo uma aplicação B2B Cristiano Fornari Colpani (FURB) cristiano.colpani@senior.com.br Alexander Roberto Valdameri (FURB) arv@furb.br Resumo. Este artigo descreve um

Leia mais

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Aula 2 Computação em Nuvem Desafios e Oportunidades A Computação em Nuvem

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Soquetes Um soquete é formado por um endereço IP concatenado com um número de porta. Em geral, os soquetes utilizam uma arquitetura cliente-servidor. O servidor espera por pedidos

Leia mais

Ambientes Visuais. Ambientes Visuais

Ambientes Visuais. Ambientes Visuais Ambientes Visuais Inicialmente, apenas especialistas utilizavam os computadores, sendo que os primeiros desenvolvidos ocupavam grandes áreas e tinham um poder de processamento reduzido. Porém, a contínua

Leia mais

Uma Abordagem usando PU

Uma Abordagem usando PU Uma Abordagem usando PU Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Baseada em: Rational Software Corpotation G. Booch, Ivar Jacobson,

Leia mais

CONCEITOS INICIAIS. Agenda A diferença entre páginas Web, Home Page e apresentação Web;

CONCEITOS INICIAIS. Agenda A diferença entre páginas Web, Home Page e apresentação Web; CONCEITOS INICIAIS Agenda A diferença entre páginas Web, Home Page e apresentação Web; O que é necessário para se criar páginas para a Web; Navegadores; O que é site, Host, Provedor e Servidor Web; Protocolos.

Leia mais

Introdução à Informática

Introdução à Informática Introdução à Informática Aula 23 http://www.ic.uff.br/~bianca/introinfo/ Aula 23-07/12/2007 1 Histórico da Internet Início dos anos 60 Um professor do MIT (J.C.R. Licklider) propõe a idéia de uma Rede

Leia mais

FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação

FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação 1 Ruironaldi dos Santos Cruz ARTIGO ARQUITETURA ORIENTADA A SERVIÇO SOA SERVICE

Leia mais

Gerência de Redes de Computadores Gerência de Redes de Computadores As redes estão ficando cada vez mais importantes para as empresas Não são mais infra-estrutura dispensável: são de missão crítica, ou

Leia mais

Autoria Web Apresentação e Visão Geral sobre a Web

Autoria Web Apresentação e Visão Geral sobre a Web Apresentação e Visão Geral sobre a Web Apresentação Thiago Miranda Email: mirandathiago@gmail.com Site: www.thiagomiranda.net Objetivos da Disciplina Conhecer os limites de atuação profissional em Web

Leia mais

Monitoramento Inteligente:

Monitoramento Inteligente: Ebook Exclusivo Monitoramento Inteligente: Melhore a eficiência operacional, automatize processos e aumente a produtividade. E s pec i a li s ta em S e rv i ços G e r e n c i a do s Segurança de de Perímetro

Leia mais

MRP COMO SISTEMA PROPULSOR DE MELHORIAS NA ADMINISTRAÇÃO DE MATERIAIS

MRP COMO SISTEMA PROPULSOR DE MELHORIAS NA ADMINISTRAÇÃO DE MATERIAIS ISSN 1984-9354 MRP COMO SISTEMA PROPULSOR DE MELHORIAS NA ADMINISTRAÇÃO DE MATERIAIS Jamile Pereira Cunha Rodrigues (UESC) Resumo Diante do atual cenário competitivo empresarial, as empresas estão buscando

Leia mais

TCP/IP TCP UDP IP HTTP HTTPS FTP TFTP TELNET POP3 IMAP SMTP SNMP DHCP

TCP/IP TCP UDP IP HTTP HTTPS FTP TFTP TELNET POP3 IMAP SMTP SNMP DHCP TCP/IP TCP UDP IP HTTP HTTPS FTP TFTP TELNET POP3 IMAP SMTP SNMP DHCP HTTP (Hypertext Transfer Protocol ) Protocolo usado na Internet para transferir as páginas da WWW (WEB). HTTPS (HyperText Transfer

Leia mais

Arquiteturas de Aplicações Distribuídas

Arquiteturas de Aplicações Distribuídas Arquiteturas de Aplicações Distribuídas Fernando Albuquerque 061-2733589 fernando@cic.unb.br www.cic.unb.br/docentes/fernando Tópicos Introdução. HTTP / CGI. API sockets. JDBC. Remote Method Invocation.

Leia mais

Infra estrutura da Tecnologia da Informação

Infra estrutura da Tecnologia da Informação Infra estrutura da Tecnologia da Informação Capítulo 3 Adaptado do material de apoio ao Livro Sistemas de Informação Gerenciais, 7ª ed., de K. Laudon e J. Laudon, Prentice Hall, 2005 CEA460 Gestão da Informação

Leia mais

SOA: Service-oriented architecture

SOA: Service-oriented architecture SOA: Service-oriented architecture Roteiro Breve História O que é Arquitetura de Software? O que é SOA? Serviços Infraestrutura Composição Sua empresa está preparada para SOA? Breve História Uma empresa

Leia mais

Microsoft.NET. Desenvolvimento Baseado em Componentes

Microsoft.NET. Desenvolvimento Baseado em Componentes Microsoft.NET Lirisnei Gomes de Sousa lirisnei@hotmail.com Jair C Leite jair@dimap.ufrn.br Desenvolvimento Baseado em Componentes Resolução de problemas específicos, mas que podem ser re-utilizados em

Leia mais

Web Services. Autor: Rômulo Rosa Furtado

Web Services. Autor: Rômulo Rosa Furtado Web Services Autor: Rômulo Rosa Furtado Sumário O que é um Web Service. Qual a finalidade de um Web Service. Como funciona o serviço. Motivação para o uso. Como construir um. Referências. Seção: O que

Leia mais

Software de gerenciamento do sistema Intel. Guia do usuário do Pacote de gerenciamento do servidor modular Intel

Software de gerenciamento do sistema Intel. Guia do usuário do Pacote de gerenciamento do servidor modular Intel Software de gerenciamento do sistema Intel do servidor modular Intel Declarações de Caráter Legal AS INFORMAÇÕES CONTIDAS NESTE DOCUMENTO SÃO RELACIONADAS AOS PRODUTOS INTEL, PARA FINS DE SUPORTE ÀS PLACAS

Leia mais

INFRAESTRUTURA DE TI E TECNOLOGIAS EMERGENTES

INFRAESTRUTURA DE TI E TECNOLOGIAS EMERGENTES Sistema de Informação e Tecnologia FEQ 0411 Prof Luciel Henrique de Oliveira luciel@uol.com.br Capítulo 5 INFRAESTRUTURA DE TI E TECNOLOGIAS EMERGENTES PRADO, Edmir P.V.; SOUZA, Cesar A. de. (org). Fundamentos

Leia mais

Ricardo Roberto de Lima UNIPÊ 2008.1 APS-I. Históricos e Modelagem Orientada a Objetos

Ricardo Roberto de Lima UNIPÊ 2008.1 APS-I. Históricos e Modelagem Orientada a Objetos Históricos e Modelagem Orientada a Objetos Histórico Diversas metodologias e métodos surgiram para apoiar OO. Evolução a partir de linguagens C++ e SmallTalk. Anos 80 Anos 80-90: diversidade de autores.

Leia mais

Manual do Software: UFV BEER GAME. [Jogue sem moderação] Versão 1.4

Manual do Software: UFV BEER GAME. [Jogue sem moderação] Versão 1.4 Manual do Software: UFV BEER GAME [Jogue sem moderação] Versão 1.4 Como ler esse manual: Esse manual está dividido em duas partes. Na primeira parte é apresentada uma descrição do Beer Game (Jogo da Cerveja)

Leia mais

PRnet/2013. Linguagem de Programação Web

PRnet/2013. Linguagem de Programação Web Linguagem de Programação Web Linguagem de Programação Web Prnet/2013 Linguagem de Programação Web» Programas navegadores» Tipos de URL» Protocolos: HTTP, TCP/IP» Hipertextos (páginas WEB)» HTML, XHTML»

Leia mais

Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS)

Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS) Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS) Definição Geral: Disciplina de Compiladores Prof. Jorge Bidarra (UNIOESTE) A especificação de requisitos tem como objetivo

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

Advanced Planning and Scheduling

Advanced Planning and Scheduling Advanced Planning and Scheduling Por Soraya Oliveira e Raquel Flexa A importância do planejamento Uma cadeia de suprimentos é composta por diversos elos conectados que realizam diferentes processos e atividades

Leia mais

Roteiro 2 Conceitos Gerais

Roteiro 2 Conceitos Gerais Roteiro 2 Conceitos Gerais Objetivos: UC Projeto de Banco de Dados Explorar conceitos gerais de bancos de dados; o Arquitetura de bancos de dados: esquemas, categorias de modelos de dados, linguagens e

Leia mais

UNIVERSIDADE FEDERAL FLUMINENSE IVY MARTINS SALLES SATCAR: SISTEMA DE GERÊNCIA DE UMA EMPRESA DE RASTREAMENTO VEICULAR

UNIVERSIDADE FEDERAL FLUMINENSE IVY MARTINS SALLES SATCAR: SISTEMA DE GERÊNCIA DE UMA EMPRESA DE RASTREAMENTO VEICULAR UNIVERSIDADE FEDERAL FLUMINENSE IVY MARTINS SALLES SATCAR: SISTEMA DE GERÊNCIA DE UMA EMPRESA DE RASTREAMENTO VEICULAR NITERÓI 2010 IVY MARTINS SALLES SATCAR: SISTEMA DE GERÊNCIA DE UMA EMPRESA DE RASTREAMENTO

Leia mais

Serviços Web: Introdução

Serviços Web: Introdução Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e Tecnologia do Maranhão Objetivos Nesta aula

Leia mais

World Wide Web e Aplicações

World Wide Web e Aplicações World Wide Web e Aplicações Módulo H O que é a WWW Permite a criação, manipulação e recuperação de informações Padrão de fato para navegação, publicação de informações e execução de transações na Internet

Leia mais

Guia de Consulta Rápida HTTP. Décio Jr. Novatec Editora. www.novateceditora.com.br

Guia de Consulta Rápida HTTP. Décio Jr. Novatec Editora. www.novateceditora.com.br Guia de Consulta Rápida HTTP Décio Jr. Novatec Editora www.novateceditora.com.br Guia de Consulta Rápida HTTP de Décio Jr. Copyright 2001 da Novatec Editora Ltda. Todos os direitos reservados. É proibida

Leia mais

Exemplo de Plano para Desenvolvimento de Software

Exemplo de Plano para Desenvolvimento de Software Universidade Salgado de Oliveira Especialização em Tecnologia da Informação Qualidade em Engenharia de Software Exemplo de Plano para Desenvolvimento de Software Prof. Msc. Edigar Antônio Diniz Júnior

Leia mais

Ferramentas unificadas de SOA alinham negócios e TI IDG Research aponta grandes ganhos potenciais a partir de uma solução integrada

Ferramentas unificadas de SOA alinham negócios e TI IDG Research aponta grandes ganhos potenciais a partir de uma solução integrada Insight completo sobre IDG/Oracle Relatório de pesquisa de SOA Ferramentas unificadas de SOA alinham negócios e TI IDG Research aponta grandes ganhos potenciais a partir de uma solução integrada Alinhamento

Leia mais

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE Aluno: Roberto Reinert Orientador: Everaldo A. Grahl Roteiro de apresentação Introdução Objetivos Fundamentação Teórica Workflow Processo

Leia mais

Desenvolvendo para WEB

Desenvolvendo para WEB Nível - Básico Desenvolvendo para WEB Por: Evandro Silva Neste nosso primeiro artigo vamos revisar alguns conceitos que envolvem a programação de aplicativos WEB. A ideia aqui é explicarmos a arquitetura

Leia mais

WWW - World Wide Web

WWW - World Wide Web WWW World Wide Web WWW Cap. 9.1 WWW - World Wide Web Idéia básica do WWW: Estratégia de acesso a uma teia (WEB) de documentos referenciados (linked) em computadores na Internet (ou Rede TCP/IP privada)

Leia mais

Sistema Datachk. Documento de Requisitos. Versão <1.2> Z u s a m m e n a r b e i t I d e i a s C o l a b o r a t i v a s

Sistema Datachk. Documento de Requisitos. Versão <1.2> Z u s a m m e n a r b e i t I d e i a s C o l a b o r a t i v a s Documento de Requisitos Versão Z u s a m m e n a r b e i t I d e i a s C o l a b o r a t i v a s 2010 2 Histórico de Revisões Data Versão Descrição Autores 27/04/2010 1.0 Criação da primeira versão

Leia mais

Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS

Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS Objetos distribuídos e invocação remota Introdução Comunicação entre objetos distribuídos Chamada de procedimento remoto Eventos e notificações Objetos

Leia mais

Objetivo da Aula. Enterprise Resource Planning - ERP. Descrever os sistemas ERP, seus módulos e possíveis aplicações e tendências 23/4/2010

Objetivo da Aula. Enterprise Resource Planning - ERP. Descrever os sistemas ERP, seus módulos e possíveis aplicações e tendências 23/4/2010 Enterprise Resource Planning - ERP Objetivo da Aula Descrever os sistemas ERP, seus módulos e possíveis aplicações e tendências 2 1 Sumário Informação & TI Sistemas Legados ERP Classificação Módulos Medidas

Leia mais

Documento de Requisitos

Documento de Requisitos UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA GRADUAÇÃO EM ENGENHARIA DA COMPUTAÇÃO Documento de Requisitos Sistema Gerenciador de Atendimento de Chamados Técnicos Grupo: Luiz Augusto Zelaquett

Leia mais

Curso de Sistemas de Informação 8º período Disciplina: Tópicos Especiais Professor: José Maurício S. Pinheiro V. 2009-1

Curso de Sistemas de Informação 8º período Disciplina: Tópicos Especiais Professor: José Maurício S. Pinheiro V. 2009-1 Curso de Sistemas de Informação 8º período Disciplina: Tópicos Especiais Professor: José Maurício S. Pinheiro V. 2009-1 Aula 6 Projeto de Sistema Biométrico 1. Definição de Metas A primeira etapa no projeto

Leia mais

Sistema Nacional de Registro de Hóspedes - SNRHos. PGTUR Plataforma de Gestão do Turismo Manual Técnico de Utilização do Web Service Versão 2.

Sistema Nacional de Registro de Hóspedes - SNRHos. PGTUR Plataforma de Gestão do Turismo Manual Técnico de Utilização do Web Service Versão 2. Sistema Nacional de Registro de Hóspedes - PGTUR Plataforma de Gestão do Turismo Manual Técnico de Utilização do Web Service Versão 2.0 ÍNDICE 1. CONSIDERAÇÕES INICIAIS... 3 2. TECNOLOGIA WEB SERVICE...

Leia mais

Arquitetura de Sistemas Distribuídos. Introdução a Sistemas Distribuídos

Arquitetura de Sistemas Distribuídos. Introdução a Sistemas Distribuídos Introdução a Sistemas Distribuídos Definição: "Um sistema distribuído é uma coleção de computadores autônomos conectados por uma rede e equipados com um sistema de software distribuído." "Um sistema distribuído

Leia mais

Versão <1.0> Documento de Requisitos. Documento de Requisitos. Equipe:

Versão <1.0> Documento de Requisitos. Documento de Requisitos. Equipe: Versão Documento de Requisitos Documento de Requisitos Equipe: Bruno Harada (bhhc) Edilson Augusto Junior (easj) José Ivson Soares da Silva (jiss) Pedro Rodolfo da Silva Gonçalves (prsg) Raphael

Leia mais

Descritivo Técnico. SLAView - Descritivo Técnico Build 5.0 release 4 16/02/2011 Página 1

Descritivo Técnico. SLAView - Descritivo Técnico Build 5.0 release 4 16/02/2011 Página 1 Descritivo Técnico 16/02/2011 Página 1 1. OBJETIVO O SLAview é um sistema de análise de desempenho de redes IP por meio da monitoração de parâmetros de SLA (Service Level Agreement, ou Acordo de Nível

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais

Capítulo 8 - Aplicações em Redes

Capítulo 8 - Aplicações em Redes Capítulo 8 - Aplicações em Redes Prof. Othon Marcelo Nunes Batista Mestre em Informática 1 de 31 Roteiro Sistemas Operacionais em Rede Modelo Cliente-Servidor Modelo P2P (Peer-To-Peer) Aplicações e Protocolos

Leia mais

A utilização do JSWDP para construção de Web Services

A utilização do JSWDP para construção de Web Services A utilização do JSWDP para construção de Web Services Fabiana Ferreira Cardoso 1, Francisco A. S. Júnior 1, Madianita Bogo 1 1 Centro de Tecnologia da Informação Centro Universitário Luterano de Palmas

Leia mais

Especificação dos Requisitos do Software. White Label

Especificação dos Requisitos do Software. White Label Ubee Especificação dos Requisitos do Software White Label Review 0.3 Autores: Airton Sampaio de Sobral (asds@cin.ufpe.br) Alan Gomes Alvino (aga@cin.ufpe.br) Glauco Roberto Pires dos Santos (grps@cin.ufpe.br)

Leia mais

Alinhando a infra-estrutura de aplicações com os negócios através de Application Delivery orientado a serviços

Alinhando a infra-estrutura de aplicações com os negócios através de Application Delivery orientado a serviços Alinhando a infra-estrutura de aplicações com os negócios através de Application Delivery orientado a serviços Visão Geral Desafio Solução Uma implementação SOA (Service Oriented Architecture) bem-sucedida

Leia mais

Modelagem de Sistemas Web. Ferramentas e metodologias para projeto de sistemas web

Modelagem de Sistemas Web. Ferramentas e metodologias para projeto de sistemas web Modelagem de Sistemas Web Aula 4 Ferramentas e metodologias para projeto de sistemas web Ferramentas e metodologias para projeto de sistemas web Ferramentas CASE Fontes: Sarajane e Marques Peres Introdução

Leia mais

Extensões MIDP para Web Services

Extensões MIDP para Web Services Extensões MIDP para Web Services INF-655 Computação Móvel Universidade Federal de Viçosa Departamento de Informática MIDP Architecture MIDP = Mobile Information Device Profile Connection Framework HttpConnection

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

Desenvolvimento Web. Saymon Yury C. Silva Analista de Sistemas. http://www.saymonyury.com.br

Desenvolvimento Web. Saymon Yury C. Silva Analista de Sistemas. http://www.saymonyury.com.br Desenvolvimento Web Saymon Yury C. Silva Analista de Sistemas http://www.saymonyury.com.br Vantagens Informação em qualquer hora e lugar; Rápidos resultados; Portabilidade absoluta; Manutenção facilitada

Leia mais

CA Nimsoft Monitor para servidores

CA Nimsoft Monitor para servidores DOCUMENTAÇÃO TÉCNICA Setembro de 2012 CA Nimsoft Monitor para servidores agility made possible CA Nimsoft para monitoramento de servidores sumário CA Nimsoft Monitor para servidores 3 visão geral da solução

Leia mais

Sistema Nacional de Registro de Hóspedes - SNRHos. PGTUR Plataforma de Gestão do Turismo Manual Técnico de Utilização do Web Service Versão 1.

Sistema Nacional de Registro de Hóspedes - SNRHos. PGTUR Plataforma de Gestão do Turismo Manual Técnico de Utilização do Web Service Versão 1. Sistema Nacional de Registro de Hóspedes - PGTUR Plataforma de Gestão do Turismo Manual Técnico de Utilização do Web Service Versão 1.0 ÍNDICE 1. INTRODUÇÃO... 3 2. CONSIDERAÇÕES INICIAIS... 3 3. TÉCNOLOGIA

Leia mais

Documento de Requisitos de Rede (DRP)

Documento de Requisitos de Rede (DRP) Documento de Requisitos de Rede (DRP) Versão 1.2 SysTrack - Grupo 1 1 Histórico de revisões do modelo Versão Data Autor Descrição 1.0 30/04/2011 João Ricardo Versão inicial 1.1 1/05/2011 André Ricardo

Leia mais

SISTEMAS DISTRIBUIDOS

SISTEMAS DISTRIBUIDOS 1 2 Caracterização de Sistemas Distribuídos: Os sistemas distribuídos estão em toda parte. A Internet permite que usuários de todo o mundo acessem seus serviços onde quer que possam estar. Cada organização

Leia mais

GERÊNCIA DE DADOS SEMIESTRUTURADOS -XML. Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza

GERÊNCIA DE DADOS SEMIESTRUTURADOS -XML. Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza GERÊNCIA DE DADOS SEMIESTRUTURADOS -XML Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza O QUE É XML? Tecnologia desenvolvida pelo W3C http://www.w3c.org W3C: World Wide Web Consortium consórcio

Leia mais

3 O sistema APO Advanced Planner and Optimizer

3 O sistema APO Advanced Planner and Optimizer 3 O sistema APO Advanced Planner and Optimizer Esse capítulo tem por objetivo apresentar os conceitos do sistema APO (Advanced Planner and Optimizer), o sistema APS da empresa alemã SAP. O sistema APO

Leia mais

Tópicos de Ambiente Web Conceitos Fundamentais Redes de Dados

Tópicos de Ambiente Web Conceitos Fundamentais Redes de Dados Tópicos de Ambiente Web Conceitos Fundamentais Redes de Dados Professora: Sheila Cáceres Computador Dispositivo eletrônico usado para processar guardar e tornar acessível informação. Tópicos de Ambiente

Leia mais

DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 MANTER FUNCIONÁRIO RELEASE 4.1

DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 MANTER FUNCIONÁRIO RELEASE 4.1 DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 MANTER FUNCIONÁRIO RELEASE 4.1 SUMÁRIO DEFINIÇÃO DE REQUISITOS 4 1. INTRODUÇÃO 4 1.1 FINALIDADE 4 1.2 ESCOPO 4 1.3 DEFINIÇÕES, ACRÔNIMOS

Leia mais