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

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

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

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

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

Software de segurança em redes para monitoração de pacotes em uma conexão TCP/IP

Software de segurança em redes para monitoração de pacotes em uma conexão TCP/IP Software de segurança em redes para monitoração de pacotes em uma conexão TCP/IP Paulo Fernando da Silva psilva@senior.com.br Sérgio Stringari stringari@furbbr Resumo. Este artigo apresenta a especificação

Leia mais

Material de Apoio. Sistema de Informação Gerencial (SIG)

Material de Apoio. Sistema de Informação Gerencial (SIG) Sistema de Informação Gerencial (SIG) Material de Apoio Os Sistemas de Informação Gerencial (SIG) são sistemas ou processos que fornecem as informações necessárias para gerenciar com eficácia as organizações.

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

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

Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA

Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA RESUMO Ricardo Della Libera Marzochi A introdução ao Service Component Architecture (SCA) diz respeito ao estudo dos principais fundamentos

Leia mais

5 Mecanismo de seleção de componentes

5 Mecanismo de seleção de componentes Mecanismo de seleção de componentes 50 5 Mecanismo de seleção de componentes O Kaluana Original, apresentado em detalhes no capítulo 3 deste trabalho, é um middleware que facilita a construção de aplicações

Leia mais

ISO/IEC 12207: Gerência de Configuração

ISO/IEC 12207: Gerência de Configuração ISO/IEC 12207: Gerência de Configuração Durante o processo de desenvolvimento de um software, é produzida uma grande quantidade de itens de informação que podem ser alterados durante o processo Para que

Leia mais

5 Estudo de caso: utilizando o sistema para requisição de material

5 Estudo de caso: utilizando o sistema para requisição de material 61 5 Estudo de caso: utilizando o sistema para requisição de material A fim de avaliar as características da arquitetura proposta e a corretude da implementação, realizamos experiências com cenários de

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Modelo Cliente-Servidor: Introdução aos tipos de servidores e clientes Prof. MSc. Hugo Souza Iniciando o módulo 03 da primeira unidade, iremos abordar sobre o Modelo Cliente-Servidor

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

Um Driver NDIS Para Interceptação de Datagramas IP

Um Driver NDIS Para Interceptação de Datagramas IP Um Driver NDIS Para Interceptação de Datagramas IP Paulo Fernando da Silva psilva@senior.com.br Sérgio Stringari stringari@furb.br Resumo. Este artigo apresenta o desenvolvimento de um driver NDIS 1 para

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

Engenharia de Software III

Engenharia de Software III Engenharia de Software III Casos de uso http://dl.dropbox.com/u/3025380/es3/aula6.pdf (flavio.ceci@unisul.br) 09/09/2010 O que são casos de uso? Um caso de uso procura documentar as ações necessárias,

Leia mais

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart.

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Versão 1.6 15/08/2013 Visão Resumida Data Criação 15/08/2013 Versão Documento 1.6 Projeto Responsáveis

Leia mais

Engª de Produção Prof.: Jesiel Brito. Sistemas Integrados de Produção ERP. Enterprise Resources Planning

Engª de Produção Prof.: Jesiel Brito. Sistemas Integrados de Produção ERP. Enterprise Resources Planning ERP Enterprise Resources Planning A Era da Informação - TI GRI Information Resource Management -Informação Modo organizado do conhecimento para ser usado na gestão das empresas. - Sistemas de informaçã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

Sistemas de Informação I

Sistemas de Informação I + Sistemas de Informação I Dimensões de análise dos SI Ricardo de Sousa Britto rbritto@ufpi.edu.br + Introdução n Os sistemas de informação são combinações das formas de trabalho, informações, pessoas

Leia mais

Plano de Gerenciamento do Projeto

Plano de Gerenciamento do Projeto Projeto para Soluções Contábeis 2015 Plano de Gerenciamento do Projeto Baseado na 5ª edição do Guia PMBOK Brendon Genssinger o e Elcimar Silva Higor Muniz Juliermes Henrique 23/11/2015 1 Histórico de alterações

Leia mais

Noções de. Microsoft SQL Server. Microsoft SQL Server

Noções de. Microsoft SQL Server. Microsoft SQL Server Noções de 1 Considerações Iniciais Basicamente existem dois tipos de usuários do SQL Server: Implementadores Administradores 2 1 Implementadores Utilizam o SQL Server para criar e alterar base de dados

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

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1. ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página

Leia mais

IMPLEMENTAÇÃO DE SOCKETS E THREADS NO DESENVOLVIMENTO DE SISTEMAS CLIENTE / SERVIDOR: UM ESTUDO EM VB.NET

IMPLEMENTAÇÃO DE SOCKETS E THREADS NO DESENVOLVIMENTO DE SISTEMAS CLIENTE / SERVIDOR: UM ESTUDO EM VB.NET 1 IMPLEMENTAÇÃO DE SOCKETS E THREADS NO DESENVOLVIMENTO DE SISTEMAS CLIENTE / SERVIDOR: UM ESTUDO EM VB.NET Daniel da Silva Carla E. de Castro Franco Diogo Florenzano Avelino daniel.silva1@ext.mpsa.com

Leia mais

Anexo VI Edital nº 03361/2008. Projeto de Integração das informações de Identificação Civil. 1. Definições de interoperabilidade adotadas pela SENASP

Anexo VI Edital nº 03361/2008. Projeto de Integração das informações de Identificação Civil. 1. Definições de interoperabilidade adotadas pela SENASP Anexo VI Edital nº 03361/2008 Projeto de Integração das informações de Identificação Civil 1. Definições de interoperabilidade adotadas pela SENASP A Senasp procura adotar os padrões de interoperabilidade

Leia mais

Manual Portal Ambipar

Manual Portal Ambipar Manual Portal Ambipar Acesso Para acessar o Portal Ambipar, visite http://ambipar.educaquiz.com.br. Login Para efetuar o login no Portal será necessário o e-mail do Colaborador e a senha padrão, caso a

Leia mais

UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas

UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas 4.1 Motivação Sistemas de Informação são usados em diversos níveis dentro de uma organização, apoiando a tomada de decisão; Precisam estar

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

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

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

PLANEJAMENTO DA MANUFATURA

PLANEJAMENTO DA MANUFATURA 58 FUNDIÇÃO e SERVIÇOS NOV. 2012 PLANEJAMENTO DA MANUFATURA Otimizando o planejamento de fundidos em uma linha de montagem de motores (II) O texto dá continuidade à análise do uso da simulação na otimização

Leia mais

SIMULADO: Simulado 3 - ITIL Foundation v3-40 Perguntas em Português

SIMULADO: Simulado 3 - ITIL Foundation v3-40 Perguntas em Português 1 de 7 28/10/2012 16:47 SIMULADO: Simulado 3 - ITIL Foundation v3-40 Perguntas em Português RESULTADO DO SIMULADO Total de questões: 40 Pontos: 0 Score: 0 % Tempo restante: 55:07 min Resultado: Você precisa

Leia mais

Programa de Capacitação em Gestão do PPA Curso PPA: Elaboração e Gestão Ciclo Básico. Elaboração de Planos Gerenciais dos Programas do PPA

Programa de Capacitação em Gestão do PPA Curso PPA: Elaboração e Gestão Ciclo Básico. Elaboração de Planos Gerenciais dos Programas do PPA Programa de Capacitação em Gestão do PPA Curso PPA: Elaboração e Gestão Ciclo Básico Elaboração de Planos Gerenciais dos Programas do PPA Brasília, abril/2006 APRESENTAÇÃO O presente manual tem por objetivo

Leia mais

GESTÃO DAS INFORMAÇÕES DAS ORGANIZAÇÕES MÓDULO 11

GESTÃO DAS INFORMAÇÕES DAS ORGANIZAÇÕES MÓDULO 11 GESTÃO DAS INFORMAÇÕES DAS ORGANIZAÇÕES MÓDULO 11 Índice 1. Importância do ERP para as organizações...3 2. ERP como fonte de vantagem competitiva...4 3. Desenvolvimento e implantação de sistema de informação...5

Leia mais

15/09/2015. Gestão e Governança de TI. Modelo de Governança em TI. A entrega de valor. A entrega de valor. A entrega de valor. A entrega de valor

15/09/2015. Gestão e Governança de TI. Modelo de Governança em TI. A entrega de valor. A entrega de valor. A entrega de valor. A entrega de valor Gestão e Governança de TI Modelo de Governança em TI Prof. Marcel Santos Silva PMI (2013), a gestão de portfólio é: uma coleção de projetos e/ou programas e outros trabalhos que são agrupados para facilitar

Leia mais

ADMINISTRAÇÃO DE ATIVOS DE TI GERENCIAMENTO DE CONFIGURAÇÃO

ADMINISTRAÇÃO DE ATIVOS DE TI GERENCIAMENTO DE CONFIGURAÇÃO 1 ADMINISTRAÇÃO DE ATIVOS DE TI GERENCIAMENTO DE CONFIGURAÇÃO 2 INFRAESTRUTURA DE TI Para garantir o atendimento às necessidades do negócio, a área de TI passou a investir na infraestrutura do setor, ampliando-a,

Leia mais

Sistema de Controle de Solicitação de Desenvolvimento

Sistema de Controle de Solicitação de Desenvolvimento Sistema de Controle de Solicitação de Desenvolvimento Introdução O presente documento descreverá de forma objetiva as principais operações para abertura e consulta de uma solicitação ao Setor de Desenvolvimento

Leia mais

Abordagem de Processo: conceitos e diretrizes para sua implementação

Abordagem de Processo: conceitos e diretrizes para sua implementação QP Informe Reservado Nº 70 Maio/2007 Abordagem de Processo: conceitos e diretrizes para sua implementação Tradução para o português especialmente preparada para os Associados ao QP. Este guindance paper

Leia mais

Universidade Paulista

Universidade Paulista Universidade Paulista Ciência da Computação Sistemas de Informação Gestão da Qualidade Principais pontos da NBR ISO/IEC 12207 - Tecnologia da Informação Processos de ciclo de vida de software Sergio Petersen

Leia mais

SERVICE DESK MANAGER SDM. Manual do Sistema - DPOI

SERVICE DESK MANAGER SDM. Manual do Sistema - DPOI SERVICE DESK MANAGER SDM Manual do Sistema - DPOI Conteúdo SERVICE DESK MANAGER SDM... 1 Manual do Sistema - DPOI... 1 INTRODUÇÃO... 4 ACESSO AO SISTEMA... 5 OPÇÕES DO SISTEMA... 6 SISTEMA... 7 Pesquisar

Leia mais

Registro e Acompanhamento de Chamados

Registro e Acompanhamento de Chamados Registro e Acompanhamento de Chamados Contatos da Central de Serviços de TI do TJPE Por telefone: (81) 2123-9500 Pela intranet: no link Central de Serviços de TI Web (www.tjpe.jus.br/intranet) APRESENTAÇÃO

Leia mais

CATÁLOGO DE CUSTOMIZAÇÕES Apontamento Web

CATÁLOGO DE CUSTOMIZAÇÕES Apontamento Web CATÁLOGO DE CUSTOMIZAÇÕES Apontamento Web Índice CONSIDERAÇÕES INICIAIS... 3 DADOS DO PROJETO... 4 OBJETIVO(S) DO PROJETO... 4 ESCOPO... ERRO! INDICADOR NÃO DEFINIDO. PREMISSAS... 17 LIMITAÇÕES E RESTRIÇÕES...

Leia mais

Marketing. Gestão de Produção. Gestão de Produção. Função Produção. Prof. Angelo Polizzi

Marketing. Gestão de Produção. Gestão de Produção. Função Produção. Prof. Angelo Polizzi Marketing Prof. Angelo Polizzi Gestão de Produção Gestão de Produção Objetivos: Mostrar que produtos (bens e serviços) consumidos, são produzidos em uma ordem lógica, evitando a perda ou falta de insumos

Leia mais

Quando se fala em ponto eletrônico, a primeira coisa que vem à sua cabeça ainda é dor?

Quando se fala em ponto eletrônico, a primeira coisa que vem à sua cabeça ainda é dor? Quando se fala em ponto eletrônico, a primeira coisa que vem à sua cabeça ainda é dor? Interagir com sistemas que ainda dependem de agendamentos manuais e de coletas presenciais em vários equipamentos

Leia mais

Satélite. Manual de instalação e configuração. CENPECT Informática www.cenpect.com.br cenpect@cenpect.com.br

Satélite. Manual de instalação e configuração. CENPECT Informática www.cenpect.com.br cenpect@cenpect.com.br Satélite Manual de instalação e configuração CENPECT Informática www.cenpect.com.br cenpect@cenpect.com.br Índice Índice 1.Informações gerais 1.1.Sobre este manual 1.2.Visão geral do sistema 1.3.História

Leia mais

04/08/2012 MODELAGEM DE DADOS. PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS. Aula 1. Prof. Rafael Dias Ribeiro. M.Sc.

04/08/2012 MODELAGEM DE DADOS. PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS. Aula 1. Prof. Rafael Dias Ribeiro. M.Sc. MODELAGEM DE DADOS PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS Aula 1 Prof. Rafael Dias Ribeiro. M.Sc. @ribeirord 1 Objetivos: Apresenta a diferença entre dado e informação e a importância

Leia mais

Introdução ao Modelos de Duas Camadas Cliente Servidor

Introdução ao Modelos de Duas Camadas Cliente Servidor Introdução ao Modelos de Duas Camadas Cliente Servidor Desenvolvimento de Sistemas Cliente Servidor Prof. Esp. MBA Heuber G. F. Lima Aula 1 Ciclo de Vida Clássico Aonde estamos? Page 2 Análise O que fizemos

Leia mais

MÓDULO 7 Modelo OSI. 7.1 Serviços Versus Protocolos

MÓDULO 7 Modelo OSI. 7.1 Serviços Versus Protocolos MÓDULO 7 Modelo OSI A maioria das redes são organizadas como pilhas ou níveis de camadas, umas sobre as outras, sendo feito com o intuito de reduzir a complexidade do projeto da rede. O objetivo de cada

Leia mais

E-business: Como as Empresas Usam os Sistemas de Informação

E-business: Como as Empresas Usam os Sistemas de Informação Capítulo 2 E-business: Como as Empresas Usam os Sistemas de Informação 2.1 2007 by Prentice Hall OBJETIVOS DE ESTUDO Identificar e descrever as principais características das empresas que são importantes

Leia mais

PLANEJAMENTO OPERACIONAL - MARKETING E PRODUÇÃO MÓDULO 3 O QUE É PLANEJAMENTO DE VENDAS E OPERAÇÕES?

PLANEJAMENTO OPERACIONAL - MARKETING E PRODUÇÃO MÓDULO 3 O QUE É PLANEJAMENTO DE VENDAS E OPERAÇÕES? PLANEJAMENTO OPERACIONAL - MARKETING E PRODUÇÃO MÓDULO 3 O QUE É PLANEJAMENTO DE VENDAS E OPERAÇÕES? Índice 1. O que é planejamento de...3 1.1. Resultados do planejamento de vendas e operações (PVO)...

Leia mais

GUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas

GUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas PIM PROGRAMA DE INTEGRAÇÃO COM O MERCADO GUIA DE CURSO Tecnologia em Sistemas de Informação Tecnologia em Desenvolvimento Web Tecnologia em Análise e Desenvolvimento de Sistemas Tecnologia em Sistemas

Leia mais

1) MANUAL DO INTEGRADOR Este documento, destinado aos instaladores do sistema, com informações de configuração.

1) MANUAL DO INTEGRADOR Este documento, destinado aos instaladores do sistema, com informações de configuração. O software de tarifação é uma solução destinada a rateio de custos de insumos em sistemas prediais, tais como shopping centers. O manual do sistema é dividido em dois volumes: 1) MANUAL DO INTEGRADOR Este

Leia mais

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES [Observação: O template a seguir é utilizado como roteiro para projeto de sistemas orientado

Leia mais

2 Diagrama de Caso de Uso

2 Diagrama de Caso de Uso Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Caso de Uso (Use Case) Autoria:Aristófanes Corrêa

Leia mais

Despachante Express - Software para o despachante documentalista veicular DESPACHANTE EXPRESS MANUAL DO USUÁRIO VERSÃO 1.1

Despachante Express - Software para o despachante documentalista veicular DESPACHANTE EXPRESS MANUAL DO USUÁRIO VERSÃO 1.1 DESPACHANTE EXPRESS MANUAL DO USUÁRIO VERSÃO 1.1 1 Sumário 1 - Instalação Normal do Despachante Express... 3 2 - Instalação do Despachante Express em Rede... 5 3 - Registrando o Despachante Express...

Leia mais

Programação Orientada a Objetos com PHP & MySQL Cookies e Sessões. Prof. MSc. Hugo Souza

Programação Orientada a Objetos com PHP & MySQL Cookies e Sessões. Prof. MSc. Hugo Souza Programação Orientada a Objetos com PHP & MySQL Cookies e Sessões Prof. MSc. Hugo Souza Se você precisar manter informações sobre seus usuários enquanto eles navegam pelo seu site, ou até quando eles saem

Leia mais

SUMÁRIO Acesso ao sistema... 2 Atendente... 3

SUMÁRIO Acesso ao sistema... 2 Atendente... 3 SUMÁRIO Acesso ao sistema... 2 1. Login no sistema... 2 Atendente... 3 1. Abrindo uma nova Solicitação... 3 1. Consultando Solicitações... 5 2. Fazendo uma Consulta Avançada... 6 3. Alterando dados da

Leia mais

TRBOnet MDC Console. Manual de Operação

TRBOnet MDC Console. Manual de Operação TRBOnet MDC Console Manual de Operação Versão 1.8 ÍNDICE NEOCOM Ltd 1. VISÃO GERAL DA CONSOLE...3 2. TELA DE RÁDIO...4 2.1 COMANDOS AVANÇADOS...5 2.2 BARRA DE FERRAMENTAS...5 3. TELA DE LOCALIZAÇÃO GPS...6

Leia mais

Aplicativo da Manifestação do Destinatário. Manual

Aplicativo da Manifestação do Destinatário. Manual Aplicativo da Manifestação do Destinatário Manual Novembro de 2012 1 Sumário 1 Aplicativo de Manifestação do Destinatário...4 2 Iniciando o aplicativo...4 3 Menus...5 3.1 Manifestação Destinatário...5

Leia mais

Banco de Dados I. Apresentação (mini-currículo) Conceitos. Disciplina Banco de Dados. Cont... Cont... Edson Thizon (edson@esucri.com.

Banco de Dados I. Apresentação (mini-currículo) Conceitos. Disciplina Banco de Dados. Cont... Cont... Edson Thizon (edson@esucri.com. Sistemas da Informação Banco de Dados I Edson Thizon (edson@esucri.com.br) 2008 Apresentação (mini-currículo) Formação Acadêmica Mestrando em Ciência da Computação (UFSC/ ) Créditos Concluídos. Bacharel

Leia mais

APLICAÇÃO REDE APLICAÇÃO APRESENTAÇÃO SESSÃO TRANSPORTE REDE LINK DE DADOS FÍSICA 1/5 PROTOCOLOS DE REDE

APLICAÇÃO REDE APLICAÇÃO APRESENTAÇÃO SESSÃO TRANSPORTE REDE LINK DE DADOS FÍSICA 1/5 PROTOCOLOS DE REDE 1/5 PROTOCOLOS DE O Modelo OSI O OSI é um modelo usado para entender como os protocolos de rede funcionam. Para facilitar a interconexão de sistemas de computadores, a ISO (International Standards Organization)

Leia mais

Semântica para Sharepoint. Busca semântica utilizando ontologias

Semântica para Sharepoint. Busca semântica utilizando ontologias Semântica para Sharepoint Busca semântica utilizando ontologias Índice 1 Introdução... 2 2 Arquitetura... 3 3 Componentes do Produto... 4 3.1 OntoBroker... 4 3.2 OntoStudio... 4 3.3 SemanticCore para SharePoint...

Leia mais

MASTER IN PROJECT MANAGEMENT

MASTER IN PROJECT MANAGEMENT MASTER IN PROJECT MANAGEMENT PROJETOS E COMUNICAÇÃO PROF. RICARDO SCHWACH MBA, PMP, COBIT, ITIL Atividade 1 Que modelos em gestão de projetos estão sendo adotados como referência nas organizações? Como

Leia mais

Conceitos de Banco de Dados

Conceitos de Banco de Dados Conceitos de Banco de Dados Autor: Luiz Antonio Junior 1 INTRODUÇÃO Objetivos Introduzir conceitos básicos de Modelo de dados Introduzir conceitos básicos de Banco de dados Capacitar o aluno a construir

Leia mais

INDICE 1. INTRODUÇÃO... 3 2. CONFIGURAÇÃO MÍNIMA... 4 3. INSTALAÇÃO... 4 4. INTERLIGAÇÃO DO SISTEMA... 5 5. ALGUNS RECURSOS... 6 6. SERVIDOR BAM...

INDICE 1. INTRODUÇÃO... 3 2. CONFIGURAÇÃO MÍNIMA... 4 3. INSTALAÇÃO... 4 4. INTERLIGAÇÃO DO SISTEMA... 5 5. ALGUNS RECURSOS... 6 6. SERVIDOR BAM... 1 de 30 INDICE 1. INTRODUÇÃO... 3 2. CONFIGURAÇÃO MÍNIMA... 4 3. INSTALAÇÃO... 4 3.1. ONDE SE DEVE INSTALAR O SERVIDOR BAM?... 4 3.2. ONDE SE DEVE INSTALAR O PROGRAMADOR REMOTO BAM?... 4 3.3. COMO FAZER

Leia mais

Aplicação Prática de Lua para Web

Aplicação Prática de Lua para Web Aplicação Prática de Lua para Web Aluno: Diego Malone Orientador: Sérgio Lifschitz Introdução A linguagem Lua vem sendo desenvolvida desde 1993 por pesquisadores do Departamento de Informática da PUC-Rio

Leia mais

Gestão inteligente de documentos eletrônicos

Gestão inteligente de documentos eletrônicos Gestão inteligente de documentos eletrônicos MANUAL DE UTILIZAÇÃO VISÃO DE EMPRESAS VISÃO EMPRESAS - USUÁRIOS (OVERVIEW) No ELDOC, o perfil de EMPRESA refere-se aos usuários com papel operacional. São

Leia mais

3 SCS: Sistema de Componentes de Software

3 SCS: Sistema de Componentes de Software 3 SCS: Sistema de Componentes de Software O mecanismo para acompanhamento das chamadas remotas se baseia em informações coletadas durante a execução da aplicação. Para a coleta dessas informações é necessário

Leia mais

TUTORIAL DO ALUNO. Olá, bem vindo à plataforma de cursos a distância da Uniapae!!!

TUTORIAL DO ALUNO. Olá, bem vindo à plataforma de cursos a distância da Uniapae!!! TUTORIAL DO ALUNO Olá, bem vindo à plataforma de cursos a distância da Uniapae!!! O Moodle é a plataforma de ensino a distância utilizada pela Uniapae sendo a unidade de ensino para rápida capacitação

Leia mais

Governança de TI. ITIL v.2&3. parte 1

Governança de TI. ITIL v.2&3. parte 1 Governança de TI ITIL v.2&3 parte 1 Prof. Luís Fernando Garcia LUIS@GARCIA.PRO.BR ITIL 1 1 ITIL Gerenciamento de Serviços 2 2 Gerenciamento de Serviços Gerenciamento de Serviços 3 3 Gerenciamento de Serviços

Leia mais

4 Um Exemplo de Implementação

4 Um Exemplo de Implementação 4 Um Exemplo de Implementação Neste capítulo será discutida uma implementação baseada na arquitetura proposta. Para tanto, será explicado como a arquitetura proposta se casa com as necessidades da aplicação

Leia mais

Manual SAGe Versão 1.2 (a partir da versão 12.08.01)

Manual SAGe Versão 1.2 (a partir da versão 12.08.01) Manual SAGe Versão 1.2 (a partir da versão 12.08.01) Submissão de Relatórios Científicos Sumário Introdução... 2 Elaboração do Relatório Científico... 3 Submissão do Relatório Científico... 14 Operação

Leia mais

Documento de Análise e Projeto VideoSystem

Documento de Análise e Projeto VideoSystem Documento de Análise e Projeto VideoSystem Versão Data Versão Descrição Autor 20/10/2009 1.0 21/10/2009 1.0 05/11/2009 1.1 Definição inicial do documento de análise e projeto Revisão do documento

Leia mais

Histórico de Revisão Data Versão Descrição Autor

Histórico de Revisão Data Versão Descrição Autor H6Projetos Documento de Requisitos Versão 1.3 Histórico de Revisão Data Versão Descrição Autor 05/09/2013 1.0 Preenchimento do Capítulo 2 Requisitos Funcionais Evilson Montenegro 26/09/2013 1.1 Preenchimento

Leia mais

SISTEMA DE GESTÃO DE PESSOAS SEBRAE/TO UNIDADE: GESTÃO ESTRATÉGICA PROCESSO: TECNOLOGIA DA INFORMAÇÃO

SISTEMA DE GESTÃO DE PESSOAS SEBRAE/TO UNIDADE: GESTÃO ESTRATÉGICA PROCESSO: TECNOLOGIA DA INFORMAÇÃO SISTEMA DE GESTÃO DE PESSOAS SEBRAE/TO UNIDADE: GESTÃO ESTRATÉGICA PROCESSO: TECNOLOGIA DA INFORMAÇÃO Competências Analista 1. Administração de recursos de infra-estrutura de tecnologia da informação 2.

Leia mais

Entendendo como funciona o NAT

Entendendo como funciona o NAT Entendendo como funciona o NAT Vamos inicialmente entender exatamente qual a função do NAT e em que situações ele é indicado. O NAT surgiu como uma alternativa real para o problema de falta de endereços

Leia mais

SISTEMAS DISTRIBUÍDOS

SISTEMAS DISTRIBUÍDOS SISTEMAS DISTRIBUÍDOS Cluster, Grid e computação em nuvem Slide 8 Nielsen C. Damasceno Introdução Inicialmente, os ambientes distribuídos eram formados através de um cluster. Com o avanço das tecnologias

Leia mais

Módulo 4: Gerenciamento de Dados

Módulo 4: Gerenciamento de Dados Módulo 4: Gerenciamento de Dados 1 1. CONCEITOS Os dados são um recurso organizacional decisivo que precisa ser administrado como outros importantes ativos das empresas. A maioria das organizações não

Leia mais

Engenharia de Requisitos Estudo de Caso

Engenharia de Requisitos Estudo de Caso Engenharia de Requisitos Estudo de Caso Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2007 Slide 1 Engenharia de Requisitos Exemplo 1 Reserva de Hotel 1. INTRODUÇÃO Este

Leia mais

Guia de utilização da notação BPMN

Guia de utilização da notação BPMN 1 Guia de utilização da notação BPMN Agosto 2011 2 Sumário de Informações do Documento Documento: Guia_de_utilização_da_notação_BPMN.odt Número de páginas: 31 Versão Data Mudanças Autor 1.0 15/09/11 Criação

Leia mais

Guia de Especificação de Caso de Uso Metodologia CELEPAR

Guia de Especificação de Caso de Uso Metodologia CELEPAR Guia de Especificação de Caso de Uso Metodologia CELEPAR Agosto 2009 Sumário de Informações do Documento Documento: guiaespecificacaocasouso.odt Número de páginas: 10 Versão Data Mudanças Autor 1.0 09/10/2007

Leia mais

Histórico da Revisão. Data Versão Descrição Autor

Histórico da Revisão. Data Versão Descrição Autor Sistema de Gerenciamento de Loja - SIGEL Documento de Visão Versão 1.0.0 Histórico da Revisão Data Versão Descrição Autor 13/01/2011 0.1 Versão preliminar do levantamento de requisitos funcionais e não

Leia mais

http://aurelio.net/vim/vim-basico.txt Entrar neste site/arquivo e estudar esse aplicativo Prof. Ricardo César de Carvalho

http://aurelio.net/vim/vim-basico.txt Entrar neste site/arquivo e estudar esse aplicativo Prof. Ricardo César de Carvalho vi http://aurelio.net/vim/vim-basico.txt Entrar neste site/arquivo e estudar esse aplicativo Administração de Redes de Computadores Resumo de Serviços em Rede Linux Controlador de Domínio Servidor DNS

Leia mais

22/02/2009. Supply Chain Management. É a integração dos processos do negócio desde o usuário final até os fornecedores originais que

22/02/2009. Supply Chain Management. É a integração dos processos do negócio desde o usuário final até os fornecedores originais que Supply Chain Management SUMÁRIO Gestão da Cadeia de Suprimentos (SCM) SCM X Logística Dinâmica Sugestões Definição Cadeia de Suprimentos É a integração dos processos do negócio desde o usuário final até

Leia mais

Índice. Para encerrar um atendimento (suporte)... 17. Conversa... 17. Adicionar Pessoa (na mesma conversa)... 20

Índice. Para encerrar um atendimento (suporte)... 17. Conversa... 17. Adicionar Pessoa (na mesma conversa)... 20 Guia de utilização Índice Introdução... 3 O que é o sistema BlueTalk... 3 Quem vai utilizar?... 3 A utilização do BlueTalk pelo estagiário do Programa Acessa Escola... 5 A arquitetura do sistema BlueTalk...

Leia mais

FCT Faculdade de Ciências e Tecnologia Serviço Técnico de Informática STI SGCD Sistema Gerenciador de Conteúdos Dinâmicos

FCT Faculdade de Ciências e Tecnologia Serviço Técnico de Informática STI SGCD Sistema Gerenciador de Conteúdos Dinâmicos FCT Faculdade de Ciências e Tecnologia Serviço Técnico de Informática STI SGCD Sistema Gerenciador de Conteúdos Dinâmicos Manual do Usuário Presidente Prudente, outubro de 2010 Índice 1. Introdução e Instruções

Leia mais

Monitoramento de Sistemas P05.002

Monitoramento de Sistemas P05.002 1. IDENTIFICAÇÃO Padrão Segmento Código P05.002 Revisão v. 2014 2. PUBLICAÇÃO Sistemas Arquitetura de Soluções Versão Data para adoção Publicação v. 2014 29 de dezembro de 2014 PORTARIA N Nº 228 de 23

Leia mais

Manual Operacional SIGA

Manual Operacional SIGA SMS - ATTI Julho -2012 Conteúdo Sumário... 2... 3 Consultar Registros... 4 Realizar Atendimento... 9 Adicionar Procedimento... 11 Não Atendimento... 15 Novo Atendimento... 16 Relatórios Dados Estatísticos...

Leia mais

INFORMÁTICA FUNDAMENTOS DE INTERNET. Prof. Marcondes Ribeiro Lima

INFORMÁTICA FUNDAMENTOS DE INTERNET. Prof. Marcondes Ribeiro Lima INFORMÁTICA FUNDAMENTOS DE INTERNET Prof. Marcondes Ribeiro Lima Fundamentos de Internet O que é internet? Nome dado a rede mundial de computadores, na verdade a reunião de milhares de redes conectadas

Leia mais

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com Última atualização: 20.03.2013 Conceitos Banco de dados distribuídos pode ser entendido como uma coleção de múltiplos bds

Leia mais

Comm5 Tecnologia Manual de utilização da família MI. Manual de Utilização. Família MI

Comm5 Tecnologia Manual de utilização da família MI. Manual de Utilização. Família MI Manual de Utilização Família MI ÍNDICE 1.0 COMO LIGAR O MÓDULO... pág 03 e 04 2.0 OBJETIVO... pág 05 3.0 COMO CONFIGURAR O MÓDULO MI... pág 06, 07, 08 e 09 4.0 COMO TESTAR A REDE... pág 10 5.0 COMO CONFIGURAR

Leia mais

MANUAL DE UTILIZAÇÃO Aplicativo Controle de Estoque Desktop

MANUAL DE UTILIZAÇÃO Aplicativo Controle de Estoque Desktop MANUAL DE UTILIZAÇÃO Aplicativo Controle de Estoque Desktop 1 1 INICIANDO O APLICATIVO PELA PRIMEIRA VEZ... 3 2 PÁGINA PRINCIPAL DO APLICATIVO... 4 2.1 INTERFACE INICIAL... 4 3 INICIANDO PROCESSO DE LEITURA...

Leia mais