Análise e Desenvolvimento de um Sistema de Informação de Gestão de Produtos Intermédios

Faculdade de Engenharia da Universidade do Porto Análise e Desenvolvimento de um Sistema de Informação de Gestão de Produtos Intermédios Fábio André Rodrigues de Oliveira VERSÃO FINAL Dissertação realizada no âmbito do Mestrado Integrado em Engenharia Eletrotécnica e de Computadores Major Automação Orientador FEUP: Prof. Dr. Mário Jorge Rodrigues de Sousa Orientador na Continental Mabor: Eng.º Nuno Gandara 19 de Julho de 2013 ii © Fábio André Rodrigues de Oliveira, 2013 iii iv v Resumo A presente dissertação tem como principal objetivo a análise e desenvolvimento de um sistema de informação para gestão de produtos intermédios num contexto empresarial. No presente documento são apresentados os vários passos desenvolvidos para o cumprimento do objetivo principal, os quais se desenvolveram em duas fases distintas. Numa primeira fase foi feito um estudo no âmbito de Sistemas de Informação e matérias relacionadas, nomeadamente, metodologias de modelação, onde foi abordado o UML e o Modelo Entidade-Relação. A segunda fase envolveu uma componente teórica e prática, realizadas através da aplicação concreta deste estudo na empresa Continental Mabor - Indústria de Pneus, situada em Lousado, Vila Nova de Famalicão. Esta fase iniciou-se com a necessidade de analisar o processo de produção de forma a compreender como o desenvolvimento desta aplicação poderia contribuir para uma melhoria para a organização. No seguimento deste cenário, em primeiro lugar, foi dedicado todo o esforço no sentido de compreender, detalhadamente, quais as necessidades e requisitos que o sistema deveria satisfazer. Posto isto, passou-se à modelação do sistema e, posteriormente, definiu-se a arquitetura geral do mesmo recorrendo ao padrão Model-View-Controller (MVC). De seguida, procedeu-se ao início do desenvolvimento da aplicação utilizando as linguagens de programação SQL, PHP, HTML, JavaScript e CSS. Por último, efetuaram-se os testes ao sistema de forma a avaliar se todas as necessidades e requisitos foram satisfeitos com sucesso e, culminando, na sua validação. Este projeto revelou-se bastante benéfico, na medida em que contribuiu para melhorar a eficiência e eficácia no processo de gestão dos produtos intermédios e permitiu combater algum défice de informação que era notório neste processo de produção. vi vii Abstract The presented dissertation has as main objective the analysis and development of an information system for management of intermediate products in a business context. In this document we present the various steps developed for the fulfillment of the main objective, which took part in two distinct phases. Initially a study was done in the context of Information Systems and related matters, in particular modeling methodologies, where he talked about the UML and Entity-Relationship Model. The second phase involved a theoretical and practical work, carried through the practical application of this study in the company Continental Mabor - Tire Industry, located in Lousado, Vila Nova de Famalicão. This phase began with the need to analyze the production process in order to understand how the development of this application could contribute to an improvement for the organization. Following this scenario, at first it was given all the effort to understand, in detail, what needs and requirements the system should satisfy. After that, we moved on to modeling the system and subsequently defined the overall architecture of the same using the Model-View- Controller (MVC). We proceeded to start the development of the application using programming languages SQL, PHP, HTML, JavaScript and CSS. Finally, tests were made in the system in order to assess whether all the needs and requirements have been satisfied successfully, and culminating in its validation. This project proved to be very beneficial according as it helped to improve the efficiency and effectiveness in the management of intermediate products and allowed to fight some information deficit that was notorious in this production process. viii ix Agradecimentos Queria expressar o meu agradecimento à Faculdade de Engenharia da Universidade do Porto (FEUP) por me proporcionar este percurso de 5 anos ricos em descobertas, experiências e muito crescimento. Um sincero agradecimento ao meu orientador Professor Doutor Mário Jorge Rodrigues de Sousa por todos os conhecimentos e atitudes que me transmitiu ao longo do curso e pelo papel que representou na preparação e no decorrer do desenvolvimento da dissertação, que se revelou primordial. Gostaria ainda de agradecer, honrosamente, à empresa Continental Mabor que me ofereceu e proporcionou ótimas condições para a realização deste projeto, em particular ao Diretor do departamento II – Eng.º Nuno Gandara que sempre me apoiou e incentivou a produzir mais e melhor, a toda a equipa do departamento de Engenharia II por me ter recebido e auxiliado, a todos os Supervisores e Colaboradores por se terem mostrado uma parte importante no desenvolvimen- to do projeto nomeadamente por revelarem disponibilidade e participarem no esclarecimento de dúvidas que surgiram ao longo do percurso. Deixo também um agradecimento especial à minha namorada, familiares, amigos e colegas por todo o apoio prestado ao longo destes últimos anos. xvi xvii Lista de Tabelas Tabela 3.1 - Comparação entre os Sistemas de Identificação Automática: Código de Barras e RFID (adaptado de [29]).................................................................................. 39 Tabela 3.2 - Escala de avaliação da utilidade e da prioridade. ......................................... 49 Tabela 3.3 - Identificação dos requisitos funcionais. ..................................................... 49 xviii xix Abreviaturas e Símbolos Lista de abreviaturas (ordenadas por ordem alfabética) AIDC Automatic Identification and Data Capture ANSI American National Standards Institute APICS American Production Inventory Control Society BD Base de Dados CAL Calandra CB Código de Barras CXP Organismo francês responsável pela consultoria em sistemas de informação à base de programas informáticos DDL Data Definition Language DML Data Manipulation Language ERP Enterprise Resources Planning FEUP Faculdade de Engenharia da Universidade do Porto HTML Hyper Text Markup Language IIS Internet Information Service ISA International Society of Automation MES Manufacturing Execution System MESA Manufacturing Enterprise Solutions Association MIEEC Mestrado Integrado em Engenharia Eletrotécnica e de Computadores MVC Model-View-Controller OCR Optical Character Recognition PESI Planeamento Estratégico de Sistemas de Informação PHP Personal Home Page PN Patter-Noster RC Rolo Calandrado RFID Radio Frequency Identification RSI Relational Software, Incorporated xx SGRC Sistema de Gestão de Rolos Calandrados SI Sistema de Informação SIA Sistemas de Identificação Automática SQL Structure Query Language UML Unified Modeling Language Capítulo 1 Introdução A presente dissertação intitulada “Análise e Desenvolvimento de um Sistema de Informação de Gestão de Produtos Intermédios” surge no âmbito da unidade curricular de Dissertação que é parte integrante do Curso de Mestrado Integrado em Engenharia Eletrotécnica e de Computadores (MIEEC) a ser desenvolvido na Faculdade de Engenharia da Universidade do Porto (FEUP). A unidade curricular apresenta como objetivo integrar e aplicar os conhecimentos, competências e atitudes adquiridas ao longo do MIEEC para a resolução de problemas complexos de engenharia. O projeto que se encontra subjacente à mesma foi desenvolvido em parceria entre a FEUP e a empresa Continental Mabor - Indústria de Pneus, S.A. 1 . Foi nas instalações da empresa que foram desenvolvidos os trabalhos que compõem a fase prática do desenvolvimento do projeto ao longo de quatro meses, nomeadamente, no departamento II - Preparação. O objetivo do projeto passa pelo desenvolvimento de um sistema de informação (SI) para gestão de produtos intermédios, nomeadamente, Rolos Calandrados (RCs) na fase de produção supracitada. O presente capítulo pretende apresentar, de forma clara e sucinta, as considerações iniciais que se mostram relevantes ao desenvolvimento do projeto. Inicialmente, serão abordados os aspetos que sustentam a realização do projeto neste âmbito, destacando a motivação e o enquadramento, e culminando a análise na justificação da escolha do tema. Seguidamente, serão definidos os objetivos ao desenvolvimento do projeto e a metodologia que será utilizada para o mesmo. Por último, será apresentada a estrutura da dissertação de forma a enquadrar o leitor no documento. 1.1 - Motivação As tecnologias de informação têm marcado presença no seio das organizações e motivado a criação de mudanças significativas nos modelos de negócio direcionadas para a obtenção de vantagens estratégicas e competitivas. Se outrora o processo produtivo era realizado tendo 1 Continental Pneus (Portugal), SA, Rua Adelino Leitão, 330 - Apartado 5029, 4764-906 Lousado (V. N. Famalicão) 2 Introdução 2 por base a informação que era transmitida entre os colaboradores, o constante incremento da competitividade interempresarial tem fomentado a necessidade, por parte das empresas, de trabalharem para fazer mais e melhor, aumentando não só a eficácia mas também a eficiência dos seus processos de produção. O trabalho desenvolvido pelas empresas neste sentido tem como finalidade a sobrevivência no mercado económico em que se inserem. A necessidade de gerir a informação que resulta dos processos empresariais culminou na motivação para a criação de um SI que gerisse eficiente e eficazmente os dados relativos aos produtos intermédios do departamento II – Preparação da empresa Continental Mabor. 1.2 - Enquadramento A empresa Continental Mabor - Indústria de Pneus, S.A. encontra-se situada em Lousado, concelho de Vila Nova de Famalicão, que tem como área de atividade o desenvolvimento de processos de produção para a criação de novos produtos - pneus. A exigência na qualidade e na satisfação do cliente é uma máxima dentro da empresa que aliadas à produção em elevadas quantidades a faz ser reconhecida como uma empresa de excelência. Atualmente, a fábrica de Lousado é uma das que mais produz a nível mundial. O trabalho subjacente ao desenvolvimento da tese será realizado no âmbito de uma das fases de produção da empresa integrada no departamento II - Preparação. Esta fase de produção, que culmina na produção de produtos intermédios, tem início após a produção de rolos calandrados (RCs) na máquina denominada por Calandra. Estes RCs podem ser do tipo metálico ou têxtil e são produtos intermédios ao fabrico dos pneus. Quando os RCs saem da calandra podem seguir dois trajetos distintos: ou são diretamente enviados para a máquina de corte e, imediatamente, é dada continuidade ao processo de produção, ou são encaminhados para um armazém de produtos intermédios, a que se dá o nome de Patter-Noster (PN). Este projeto, denominado no contexto empresarial “Sistema de Gestão de Rolos Calandrados” (SGRC), visa dar resposta a uma necessidade reportada pela empresa, no sentido de, melhorar a gestão e o acesso à informação resultante dos processos produtivos. Em última análise, é pretendido que seja possível consultar informações pertinentes sobre os RCs. Esta melhoria pretende contribuir de forma positiva para outras tarefas que se encontram, direta ou indiretamente, relacionadas com a produção empresarial, como sendo, o planeamento dos consumos, a gestão de stocks de produtos intermédios, a rastreabilidade dos rolos, entre outros. O desenvolvimento do projeto deverá processar-se, essencialmente, em duas fases. Uma primeira fase de planeamento e revisão bibliográfica no âmbito do tema e uma segunda fase, que se pretende mais prática e, na qual se desenvolverá o sistema propriamente dito. As fases serão descritas de forma mais detalhada no subcapítulo 1.4 - Metodologia. 1.3 - Objetivos Para o desenvolvimento do projeto torna-se pertinente a definição de objetivos que se mostrem norteadores ao planeamento e execução do mesmo. O projeto aqui apresentado tem como principal finalidade dotar a empresa Continental Mabor de um sistema de informação que possibilite a gestão de RCs e permita, como conse- Metodologia 3 quência, a potencialização das capacidades da empresa perante a eficácia e eficiência do processo de produção. Posto isto, torna-se preponderante a definição de objetivos subdividindo-os em gerais e específicos. O objetivo geral do presente projeto passa por desenvolver um sistema de informação para gestão de produtos intermédios - rolos calandrados. Como objetivos específicos salientamos:  Estudar o processo de produção na fase em que o sistema se insere;  Identificar as necessidades empresariais no âmbito do processo de produção na fase em que o sistema se insere;  Identificar os requisitos para a conceção do SI;  Selecionar o sistema de identificação automática a utilizar para identificação do RC;  Possibilitar o acesso à informação relativa aos rolos calandrados;  Proporcionar o controlo de stock, distinguindo os rolos calandrados têxteis e metálicos;  Permitir a criação e a consulta de um histórico da(s) localização(ões) de cada rolo;  Admitir a consulta do estado de utilização de cada rolo (consumido/por consumir);  Possibilitar a realização de avaliações de qualidade dos materiais produzidos;  Facilitar o acesso à informação de suporte à tomada de decisão para o planeamento do consumo de rolos críticos. De salientar que, os objetivos se pretendem norteadores e motivadores do trabalho e não limitadores do mesmo pelo que irá ser permitida a abertura para a superação dos objetivos preestabelecidos. 1.4 - Metodologia O desenvolvimento de um sistema de informação deve, de acordo com [1] seguir uma metodologia bem definida ao longo de fases bem delimitadas. Os projetos tradicionais adotam, regra geral, um modelo em cascata em que as fases se organizam de forma sequencial e em que uma nova fase se inicia apenas após a conclusão da fase precedente. Este modelo pressupõe a participação ativa do cliente em todas as fases, de forma a, validar o trabalho desenvolvido na fase e possibilitar a passagem para a fase subsequente, como ilustrado na Figura 1.1. Este modelo permite que, mais facilmente, o responsável pelo desenvolvimento do projeto vá de encontro às necessidades e expetativas do cliente. Figura 1.1 - Modelo de Fases de Projeto em Cascata [1]. 4 Introdução 4 O desenvolvimento do presente projeto divide-se, fundamentalmente, em duas grandes fases de acordo com as fases definidas no “Modelo das Fases de Projeto em Cascata” por [1] esquematizadas na Figura 1.1. Estas pretendem atingir os objetivos a que nos propusemos no subcapítulo anterior. Na primeira fase serão analisados, de forma clara e concisa, os conceitos e os conteúdos teóricos que se encontram subjacentes aos trabalhos tomando conhecimento sobre o estado da arte neste contexto, de forma a suportar a fase de planeamento de acordo com [1]. Na segunda fase e, em parceria com a empresa, será estudada a fase do processo de produção em que será desenvolvido o sistema, particularmente, a que se compreende entre a saída dos Rolos Calandrados (RC) da Calandra 2 (CAL) até ao envio para a máquina de corte que poderá ou não implicar uma passagem pelo Patter-Noster 3 (PN), constituindo a análise de acordo com [1]. Serão, ainda, definidos os requisitos do SI e as funcionalidades que este deverá assegurar, estabelecendo o desenho do sistema e permitindo, posteriormente, o seu desenvolvimento. 1.5 - Estrutura A estrutura e a organização do presente documento é parte fundamental na apresentação do trabalho que foi realizado ao longo do desenvolvimento da dissertação. Neste sentido, a Figura 1.2 pretende esquematizar a estrutura, de forma que esta seja facilmente percetível, clara e objetiva. 2 Calandra (CAL) - máquina utilizada para calandragem dos materiais que resultam da mistura dos compostos (departamento I) e que, por sua vez, originam os rolos calandrados; 3 Patter-Noster (PN) – local de armazenamento de produtos intermédios – rolos calandrados. Estrutura 5 Figura 1.2 - Estrutura da Dissertação. Capítulo 1 - Introdução •Motivação, enquadramento, definição de objetivos e metodologia utilizada Capítulo 2 - Revisão do Estado da Arte •Abordagem à arquitetura organizacional, aos sistemas de informação, às metodologias de modelação, à base de dados e aos sistemas de identificação automática Capítulo 3 - Caraterização do SGRC •Identificação das necessidades empresariais, levantamento de requisitos e definição da arquitetura geral do sistema Capítulo 4 - Desenvolvimento do SGRC •Descrição das ferramentas de desenvolvimento utilizadas, base de dados construida, interfaces gráficas criadas, teste e validação da aplicação Capítulo 5 - Conclusão e Futuros Desenvolvimentos •Apresentação das conclusões do projeto com exposição e análise dos resultados obtidos e proposta de trabalho a desenvolver no futuro 12 Revisão do Estado da Arte 12 Figura 2.2 - Relação entre dados e Informação (adaptado de [8]). [8] enumerou as características fundamentais da informação, como esquematizado na Figura 2.3. Figura 2.3 - Características da Informação (adaptado de [8]). INFORMAÇÃO Dados organizados segundo um padrão, significado ou utilidade; Revelante. PROCESSAMENTO (contextualização, categorização, associação e/ou coneção) DADOS Factos relativos a processos ou pessoas; Sem significado inerente. Precisa •sem erros ou redundâncias; Completa •toda a informação pertinente está disponível; Económica •o custo para obter a informção não deve ser excessivo; Inteligível •percetível ao recetor da mesma; Relevante •apenas a informação pertinente para sustentar a tomada de decisão; Simples •deve ser evitada a grande quantidade ou a complexidade de informação, que consuma demasiado tempo ou induza o erro; Disponível •deve estar acessível facilmente quando o utilizador dela necessitar; Veracidade •deve assegurar-se que a informação é fiável e precisa. Conceito 13 De salientar que, a ausência de uma ou mais características da informação pode afetar a tomada de decisão podendo levar a decisões baseadas em dados equivocados, insuficientes ou até desatualizados. 2.2.2 - Conceito O sistema de informação não é mais do que, em linha com que foi abordado, “um grupo de recursos que trabalham em conjunto para recolher, tratar e fornecer informação para os utilizadores” [7]. Salienta-se contudo que a definição de SI não é consensual entre os autores, pelo que neste trabalho teremos como linha norteadora a definição supracitada que considera que o grupo de recursos é composto por:  Pessoas (utilizadores e especialistas em SI);  Processos (de recolha e tratamento dos dados);  Tecnologias (hardware, software e procedimentos);  Dados (bases de dados, fluxos e lógica);  Recursos de redes (de comunicação e suporte);  Sistemas de controlo e de supervisão. 2.2.3 - Funcionalidades Básicas As funcionalidades básicas de um SI são o Input, o Processamento, o Output e o Armazenamento [9] como esquematizado na Figura 2.4. Figura 2.4 - Funções fundamentais do Sistema [9]. O Input engloba a recolha e a inclusão dos elementos que serão, posteriormente, processados através do sistema. O Processamento é o método através do qual se realiza a conversão dos dados em informação válida e passível de ser utilizada. O Output consiste no acesso à informação, resultante do processamento dos dados de entrada, pelo utilizador do SI. O Armazenamento envolve a base de dados que suporta o sistema. 2.2.4 - Classificação A mais antiga classificação dos SI surgiu em 1965, proposta por Anthony, e agrupava de acordo com o nível de atividade do software de gestão na organização, podendo ser agrupado em três níveis: estratégico, tático e operacional [1] como sintetizado na Figura 2.5. Processamento Input Output Armazenamento 14 Revisão do Estado da Arte 14 Figura 2.5 - Classificação dos SI desenvolvida por Anthony em 1965. Mais tarde e de acordo com [7], os SI foram classificados em dois grandes grupos: os Sistemas de Suporte à Operação e os Sistemas de Suporte à Gestão. Os Sistemas de Suporte à Operação incluem os Sistemas de Processamento e Transações, os Sistemas de Controlo e os Sistemas de Interface e de Colaboração. Os Sistemas de Suporte à Gestão abrangem os Sistemas de Gestão da Informação, os Sistemas de Apoio à Decisão e os Sistemas Executivos, como esquematizado na Figura 2.6. Figura 2.6 - Tipos de Sistemas de Informação de acordo com Brandl e Owen (adaptado de [7]). Esta classificação permitiu descrever melhor os tipos de SI existentes. Dos sistemas supracitados salientamos os Sistemas de Processamento e Transações, devido a estes permitem o registo das operações intrínsecas às atividades empresariais [11]. Estes são •centra-se no planeamento e no impacto a médio e longo prazo ESTRATÉGICO •associa-se à análise de informação e ao processo de tomada de decisão como impacto na gestão a curto prazo TÁTICO •inclui as operações do quotidiano laboral que se traduzem em alterações ou acréscimos de informação OPERACIONAL SISTEMAS DE INFORMAÇÃO Sistemas de suporte à operação Sistemas de processamento e transações Sistemas de controlo Sistemas de interface e de colaboração Sistemas de suporte à gestão Sistemas de gestão da informação Sistemas de apoio à decisão Sistemas executivos Planeamento Estratégico de Sistemas de Informação (PESI) 15 utilizados de forma a atender às necessidades do nível operacional da organização. É utilizado pelos profissionais da empresa e tem como função servir de base de entrada de dados (input). 2.2.5 - Planeamento Estratégico de Sistemas de Informação (PESI) O desenvolvimento de SIs tem como finalidade principal a melhoria da eficiência de determinados processos de negócio e na aquisição de vantagens que se mostrem competitivas no mercado em que se enquadram. Neste sentido, o uso das vantagens tecnológicas deve ser bem enquadrado nos objetivos estratégicos da empresa em causa, pelo que o desenvolvimento dos componentes da arquitetura do SI deve ser precedido de uma avaliação global de forma a garantir a coadunação do mesmo com a visão estratégica e a definição de prioridades. Face a esta problemática surge o Planeamento Estratégico de Sistemas de Informação (PESI) que tem como principal finalidade coadunar a utilização dos SIs com a missão e os objetivos empresarias, assim como, com a situação atual da organização. Esta estratégia de gestão permite, através da metodologia descrita na Figura 2.7, definir quais os componentes a implementar e desempenha o papel de guia para as intervenções, identificando e estabelecendo prioridades entre as ações a desenvolver para alcançar os objetivos a que se propuseram [1]. Figura 2.7 – Fases do PESI (adaptado de [1]). Assim, e de acordo com o PESI, o planeamento inicia-se com o levantamento dos objetivos e, posteriormente, com a análise detalhada do negócio. Segue-se a análise da situação atual do SI no contexto empresarial. Por fim elabora-se uma proposta de situação futura e planeiase toda a implementação deste. Assim, esta metodologia pretende estabelecer um plano de um ponto de vista global, garantido assim o desenvolvimento mais organizado de um SI. 2.2.6 - Desenvolvimento do Software O desenvolvimento do software desenrola-se ao longo de três fases fundamentais: a conceção, a implementação e a manutenção [10]. A fase da conceção tem como objetivos identificar os requisitos do sistema ("o que é que o sistema deve fazer"), assim como, a informação que o mesmo deve processar, as funcionalidades que deve implementar, as restrições existentes e os critérios definidores de êxito e aceitação. É nesta fase que são ainda ponderadas as diferentes alternativas e selecionada a que mais se adequa às necessidades do cliente e aos recursos existentes. Na implementação, os objetivos passam pela definição da arquitetura lógica do sistema ("como fazer o sistema") e a sua construção propriamente dita. É nesta fase Levantamento dos objetivos estratégicos Análise detalhada de negócio Análise da situação actual do SI Proposta da situação futura do SI Planeamento da implementação 16 Revisão do Estado da Arte 16 que se procede à construção de todas as partes que compõem o sistema como as estruturas de dados, os programas, os módulos, as interfaces (internas e externas) e definem quais os testes que se irão realizar para a verificação das funcionalidades do SI. No final desta fase deverá estar construído e funcional um SI. Da última fase, a da manutenção, fazem parte as alterações que são realizadas à posteriori da aceitação do produto final pelo cliente: a correção dos possíveis erros, realização de aperfeiçoamentos e/ou de novas funcionalidades. 2.2.7 - Pertinência e Vantagens As tecnologias de informação têm sido reconhecidas como sendo detentoras de um papel marcante nas organizações, nomeadamente os SI, pretendendo, sobretudo, a melhoria da eficiência e a criação de vantagens competitivas e estratégias de negócio no mercado. Primozic identificou cinco ondas de inovação a este nível [1]:  Reduzir custos – com utilização administrativa;  Potenciar investimentos – vantagens financeiras e de produção;  Melhorar e aumentar produtos e serviços – utilidade de marketing, distribuição e apoio ao cliente;  Melhorar a eficácia das decisões – que tinha impacto nas decisões estratégicas;  Atingir o consumidor – direcionada para o desenvolvimento de funcionalidades nos computadores dos clientes. A implementação dos SI requer um investimento significativo em diversas áreas, designadamente tecnológica, financeira e de recursos humanos, sendo necessário que o investimento seja justificado através da demonstração, qualitativa e quantitativa, do seu impacto estrategicamente positivo nas organizações. O investimento por parte das empresas em SI pretende, sobretudo:  A redução de custos operacionais, automatização e reformulação dos processos;  Satisfação dos requisitos de informação dos utilizadores;  Contribuição para a criação de novos produtos e/ou serviços;  Melhoria da qualidade dos serviços prestados que deverá culminar na manutenção dos clientes atuais e na aquisição de novos clientes;  Melhoria e automatização da relação com os parceiros de negócio;  Melhoria do desempenho dos recursos humanos e máquinas. Os SI são, nos dias de hoje, encarados como essenciais para a implementação de estratégias de globalização e de reengenharia nos processos de negócio, direcionados para a obtenção de vantagens competitivas através da redução dos custos, aplicação de estratégias inovadoras e diferenciadas e promoção da relação com parceiros. O uso dos SI pretende, em última análise, aliar o uso das tecnologias de informação aos objetivos estratégicos do negócio. 2.3 - Base de Dados (BD) Tendo em vista a necessidade de armazenamento dos dados para um SI, torna-se pertinente estudar o que se entende por Base de Dados. Sistema de Gestão de Bases de Dados (SGBD) 17 A Base de Dados (BD) pode ser definida como uma ferramenta que permite ao(s) utilizador(es) armazenar e trabalhar os dados que considera pertinentes de uma forma eficiente e eficaz. Esta ferramenta apresenta um papel muito importante nos sistemas de informação e nas organizações que os utilizam [12]. Posto isto, é fácil perceber que o desenho e a construção da BD de forma exata é essencial. Existem vários tipos de bases de dados como, por exemplo, hierárquicas que são as mais antigas, flat-file, object-oriented, em rede e relacionais. As hierárquicas apresentam estrutura de árvore invertida e relação entre tabelas do tipo parent/child. As flat-file são composta apenas por uma tabela em que são introduzidos e apresentados os dados mais relevantes. As object-oriented consistem em base de dados de difícil utilização, os dados são representados na forma de objetos, permite guardar, para além de dados, programas. As base de dados em rede consistem em tabelas onde estão ligadas entre si através de estruturas e nós [13][14]. As BD relacionais, utilizadas com maior frequência contemporaneamente e com vantagens reconhecidas por muitas organizações, pretendem gerir os dados de modo a que seja possível resolver os problemas mais comummente detetados e causados por fraca integridade ou redundância de dados [12]. Este tipo de BD será abordado mais detalhadamente no subcapítulo 2.3.2 - Modelo Relacional. Independentemente do tipo de BD, os dados que nela são integrados são geridos através de um sistema que se denomina por Sistema de Gestão de Bases de Dados (SGBD). 2.3.1 - Sistema de Gestão de Bases de Dados (SGBD) O Sistema de Gestão de Bases de Dados (SGBD), do inglês Database Management System, é um software que é desenhado e construído com o objetivo de cooperar com o utilizador na organização dos dados [12]. Este sistema permite o armazenamento de dados e/ou a sua atualização a partir de diferentes pontos da fábrica, sem que para isso possa ocorrer perda de consistência da informação. Os SGBD asseguram as funções de armazenamento, manipulação e inserção de dados tornando-as mais simples e eficientes em comparação com o armazenamento em ficheiros isolados usados no passado. O SGBD não é mais do que um programa que permite centralizar o acesso físico à informação que é parte integrante da base de dados, formando um “único conjunto lógico e organizado de dados, completamente autónomo das aplicações que os processam” [6]. Para isso é necessária a criação de interfaces que assegurem não apenas a transmissão de dados, mas também a segurança, validade e a sua recuperação em caso de falhas do sistema. Posto isto, os SGBD necessitam de utilizar uma linguagem para que possam gerir os dados, em muitos casos a linguagem que é utilizada é a linguagem SQL. A Struture Query Language (SQL) é uma linguagem informática que é utilizada para o desenvolvimento de bases de dados. Esta linguagem foi desenvolvida pelo American National Standards Institute (ANSI) com o objetivo de permitir o desenvolvimento de bases de dados do tipo relacional. Os comandos da linguagem SQL são direcionados para definir a estrutura dos dados e para consulta e modificação dos mesmos. É consensual entre diversos autores (Silberschatz et al., 1999; Navathe, 2003; Ramakrishnan & Gehrke, 2003 cit. por [15]) o facto de apresentar potencialidades ao nível da criação de restrições de segurança e de permissão, assim como, direcionadas para a recuperação de falhas ou erros do sistema. Os comandos fundamentais são: “create”, “alter”, “drop”, “insert into”, “update”, “delete” e “select” e 18 Revisão do Estado da Arte 18 encontram-se organizados em dois grupos: Data Definition Language (DDL) e Data Manipulation Language (DML) como ilustrado na Figura 2.8 [14]. Figura 2.8 - Comandos fundamentais da linguagem SQL. Esta linguagem é amplamente aceite no mercado. Vários são os SGBD que utilizam a linguagem SQL como o SQL Server, MySQL, PostgreeSQL, Oracle, entre outros. O SQL Server, desenvolvido pela Microsoft em parceria com a Sybase em 1988, foi construído numa fase inicial com o objetivo de complementar o Windows NT mas depressa começou a ser aperfeiçoado e comercializado individualmente. Este é, nos dias de hoje, um dos sistemas mais utilizados em todo o Mundo apresentando versões gratuitas e vendido a preços, consideravelmente, abaixo das médias de mercado. Por se tratar de uma aplicação da Microsoft, apresenta integração fácil com os produtos e tecnologias o que poderá ter contribuído para a sua popularidade. Este SGBD participa também do mercado web o que resultou de uma relação de proximidade com as linguagens ASP e APS.NET que lideram o mercado de projetos de internet [16]. O MySQL, desenvolvido na Suécia por David Axmark, Allan Larsson e Michael Widenius a partir de 1980, com registo da primeira versão em 1996, é um SGBD que utiliza a linguagem SQL como interface. Por ser de fácil utilização e compatível com diferentes sistemas operativos (Linux, FreeBSD e outros sistemas baseados em Unix, Windows e Mac OS X), este SGBD é utilizado por diversas organizações. Este sistema tem sido bem aceite e, ainda hoje, se mantém em constante desenvolvimento. É o único SGBD de grande porte que é totalmente gratui- to e que é open source, facilitando a edição de acordo com as necessidades do utilizador. Apresenta ainda a possibilidade de ser otimizado para aplicações web sendo amplamente utilizado via internet. Um aspeto a salientar relativo ao MySQl é o facto de este apresentar uma licença comercial paga que permite ao utilizador usufruir de um suporte diferenciado. É a opção adequada para quem procura uma solução ágil, com processamento rápido e tempo de resposta reduzido [17][18]. Atualmente existe uma base de dados chamada MariaDB que surgiu como fork do MySQL, criado pelo próprio fundador do projeto após sua aquisição pela Oracle. A intenção principal do projeto é manter uma alta fidelidade com o MySQL. O Postgre SQL é um SGBD do tipo object-oriented que foi desenvolvido na University of California no Berkeley Computer Science Department, inicialmente por Michael Stonebraker e mais tarde por Jolly Chen e Andrew Yu, apresentando uma versão estável desde 1996. A sua popularidade tem por base a sua integridade de dados e exatidão. Tem como vantagem a capacidade de ser executado na maior parte dos sistemas operativos (Linux, Unix e Windows) e ser detentor das propriedades ACID: Atomicidade, Consistência, Isolamento e Durabilidade. Data Definition Language (DDL) - visa definir as estruturas dos objetos de dados “create” “alter” “drop” Data Manipulation Language (DML) - permite manipular os dados nos objetos da BD "insert into" “update” “delete” “select” Modelo Relacional 19 É um SGBD de open source, gratuito, versátil, seguro e que apresenta, no mercado, o conjunto de recursos mais completo [19][20]. O Oracle surgiu em 1983 pela renomeação do sistema Relational Software, Incorporated (RSI). Este SGBD é o responsável, na atualidade, pelo armazenamento dos dados relativos a uma boa parte das organizações no Mundo, tendo um papel importante em grandes empresas com sistemas de porte médio e grande. É um SGBD do tipo object-oriented. Como pontos fracos é de salientar a necessidade de um número considerável de hardware. Um dos pontos fortes é a segurança [21]. 2.3.2 - Modelo Relacional De forma a construir a BD de forma cuidada para garantir a consistência dos dados e o seu armazenamento de forma fidedigna e válida, importa perceber em que consiste o modelo relacional. O Modelo de Dados Relacional, introduzido por Codd em 1970, destacou-se devido à sua simplicidade e base matemática. Este modelo surgiu num contexto em que era necessário aumentar a independência dos dados nos sistemas de gestão de dados, dispor de um conjunto de funções apoiadas na álgebra relacional para armazenamento e recuperação de dados, entre outras necessidades. A utilização deste modelo pretende, em última análise, resolver os problemas mais comummente detetados e causados por fraca integridade ou redundância de dados [13]. A organização deste tipo de bases de dados é obtida através de tabelas, sendo que cada uma é formada por colunas, que distinguem os atributos ou campos distintos, e linhas ou tuplos que abarcam diferentes registos de dados correspondentes a atributos referentes a cada coluna. O domínio de cada atributo diz respeito a todos os valores que podem ser assumidos. Cada uma das instâncias que compõem as tabelas tem de ser únicas, identificando de forma segura cada tuplo e evitando a possibilidade de existir duplicação dos dados. O atributo que permite que o tuplo apresente unicidade é denominado por chave, podendo ser denominado por chave primária ou estrangeira. A chave primária (Primary Key) é o valor ou conjunto de valores que identificam um atributo numa tabela, enquanto que a chave estrangeira (Foreign Key) é o(s) valor(es) de uma tabela que corresponde a outro valor de uma chave primária noutra tabela. A chave estrangeira ou externa pretende representar as relações entre as tabelas. Na Figura 2.9 pretende-se representar a notação do modelo relacional. Figura 2.9 - Notação Modelo Relacional. Posto isto, compreende-se que a BD é um elemento fundamental para o funcionamento do SI na medida em que permite o armazenamento dos dados. Paralelamente, o modelo relacional apresenta um papel importante por permitir perceber de que forma os dados se relacionam entre si e se organizam. 20 Revisão do Estado da Arte 20 2.4 - Metodologias de modelação A modelação é a forma de estruturar e compreender o funcionamento de uma aplicação e verificar e validar os seus requisitos. Esta consiste no principal ponto de partida para um desenvolvimento seguro e sustentado do SI e ao mesmo tempo uma segurança para futuras alterações. As metodologias de modelação são “um conjunto específico de regras e notações gráficas e gramaticais orientadas para criação de modelos” [22]. Para a sua constituição é fulcral a existência de uma linguagem de modelação que o suporte e que permita definir qual a notação a empregar, assim como, as regras associadas. Assim sendo, existem várias metodologias de modelação com métodos direcionados para diferentes objetivos. Entre todas as metodologias, o Unified Modeling Language (UML) tem-se revelado uma referência a nível de modelação no desenvolvimento de software, pelo que será estudada de forma mais detalhada no subcapítulo que se segue. Será, ainda, estudado o Modelo Entidade-Relação (E-R) no que respeita à modelação de Bases de dados. 2.4.1 - Unified Modeling Language (UML) O UML (Unified Modeling Language) “é uma linguagem para especificação, construção, visualização e documentação de artefactos de um sistema de software” [1], promovida pelo Object Management Group (OMG). Esta linguagem pretende definir uma linguagem de modelação standard, sendo, portanto, independente das linguagens de programação, ferramentas CASE (Computer-Aided Software Engineering), assim como, dos processos de desenvolvimen- to. O UML alarga o contexto em que as aplicações alvo são desenvolvidas comparativamente com outros métodos existentes, isto porque permite modelar sistemas concorrentes, distribuídos, sistemas de informação geográficos, entre outros exemplos. O UML, originário na engenharia de software, foi inicialmente utilizado apenas em sistemas de software, sendo posteriormente adaptado para a modelação de processos de negócio, em 2000, por Eriksson e Penker. Esta linguagem foi apresentando, com o passar do tempo, um aumento da aceitação quer o nível académico quer em consultadoria empresarial, tendo lugar de destaque nos dias de hoje [23]. A linguagem UML cria um conjunto de notações gráficas e regras de suporte à aplicação. Estas dividem-se em três grupos fundamentais:  Elementos: objetos dos modelos que se mostram representativos dos elementos reais;  Relações: interligações existentes entre os elementos podem ser de associação, composição, agregação ou generalização;  Diagramas: agrupam os objetos sob uma determinada perspetiva, podendo ser diagramas de classe, objetos, estados, atividades, sequência, colaboração, casos de uso, entre outros. De todos os diagramas que a linguagem UML permite, destacamos os casos de uso por representarem o ponto de partida à modelação dos requisitos e por se revelarem de fácil compreensão por pessoas ligadas à área de negócio. Modelo Entidade-Relação 21 De salientar, os diagramas de casos de usos, do inglês Use Case, que consiste na sequência de ações que os atores realizam de forma a alcançarem um determinado fim, tendo por base os requisitos previamente definidos. Estes representam, simplificadamente, o primeiro passo para a modelação dos requisitos do sistema norteando todo o processo de construção do mesmo. Os casos de uso devem apresentar uma descrição das potencialidades do sistema mas não da forma como estas serão atingidas, representando um olhar externo, de expectador ou utilizador, do sistema [24]. A relação entre os Use Cases pode ser de três tipos: generalização, inclusão e extensão. Na generalização, o caso base é definido com base em outros pré-existentes. A relação de inclusão visa a incorporação pelo caso base do comportamento de outro, procurando diminuir a duplicação de dados na descrição de fluxos iguais. Na extensão o caso base é a extensão do caso pré-existente a partir de um ou mais pontos de extensão bem definidos. Os diagramas de casos de uso (Use Cases) apresentam um papel primordial na linguagem de modelação UML. Estes permitem que os requisitos funcionais sejam identificados sob o ponto de vista do utilizador, representando uma abordagem adequada para o desenvolvimen- to do software, como ilustra a Figura 2.10. Figura 2.10 - Exemplo de Diagrama de Caso de Uso (adaptado de [1]). 2.4.2 - Modelo Entidade-Relação No desenho da base de dados devem ser incluídos todos os elementos relevantes e a relação entre eles. Na composição da BD, estão incluídas tabelas sendo que, cada uma, se associa a determinados atributos que a caracterizam e relações que pretendem retratar ações. É assim criado um modelo que representa as entidades e as relações entre elas, intitulado Modelo Entidade-Relação ou Modelo ER. O modelo ER foi definido por Peter Chen, em 1976, com a finalidade de representar um modelo de dados conceitual de alto nível, projetado para estar o mais próximo possível da visão que o utilizador tem dos dados. Este modelo representa a técnica mais comummente utilizada para a modelação dos dados, dada a sua facilidade de compreensão e de leitura e simplicidade. Os diagramas E-R constituem ferramentas muito úteis para a representação dos sistemas de dados e permitem a sua discussão, análise e validação, em articulação com o cliente, para a criação de esquemas de bases de dados [25]. Estes consistem numa representação gráfica onde são utilizados três conceitos: a entidade, o atributo e a relação. A entidade representa qualquer objeto ou conceito da realidade, concreto ou abstrato, acerca do qual se pretende 28 Revisão do Estado da Arte 28 atualização da informação e a rastreabilidade total das operações. Em última análise, os ERP pretendem a gestão dos recursos necessários para a satisfação das necessidades do cliente. Estes processos pretendem: estabelecer ligação entre os diferentes sistemas, assegurar a abrangência e a flexibilidade da informação, concetualizar e projetar as plataformas de forma independente, processar a informação de forma descentralizada e parametrizar os módulos à medida de cada empresa. Em suma, podemos afirmar que os ERP apresentam como característica-chave a “integração”. Dada a quantidade de informação que o ERP abrange e centraliza, poderá emergir uma problemática que se relaciona com a possibilidade de ocorrer redundância de informação. Neste sentido, surge o MES que representa uma solução, por norma organizacional, que pretende dar resposta a necessidades detetadas. Este sistema deverá adequar-se às funções operacionais de cada empresa e às necessidades a que pretende dar resposta. A abordagem aos SI iniciou-se pela distinção entre dados e informação, sendo que, os dados representam factos em bruto, e a informação são dados organizados aos quais são atribuídos significado. Posteriormente foi definido o conceito de SI, que se entende como um recurso que trabalha em conjunto para recolher, tratar e ter acesso à informação, apresentando quatro funcionalidades básicas: input, processamento, output e armazenamento. Os SI, de acordo com a classificação desenvolvida por Brandl e Owen, dividem-se em dois tipos fundamentais: os SI de suporte à operação e os de suporte à gestão. Para o desenvolvimento de um SI torna-se preponderante perceber quais as fases que são necessárias pelo que a abordagem às fases PESI se tornou preponderante. A perceção das vantagens e da pertinência dos SI constitui-se um aspeto digno de destaque, dado que a melhoria da eficiência e a criação de vantagens competitivas e estratégicas no mercado se reveste de cada vez maior importância. A redução de custos, a potencialização dos investimentos, a melhoria e o aumento dos produtos e serviços que a empresa é capaz de apresentar ao cliente, o incremento da eficácia das decisões e o atingimento do consumidor, constituem-se como as principais vantagens dos SI. As BD, enquanto suporte fundamental para a criação de um SI, e como meio de armazenamento e de trabalho de dados, eficaz e eficiente, mereceram destaque no estudo do estado da arte. Os dados armazenados nas BD são geridos através do SGBD que pretende, por sua vez, cooperar na organização dos dados e na sua centralização. Para isso, é necessário uma linguagem que, em muitos casos, é a SQL. Dos vários tipos de BD destacamos as do tipo relacional que surgem baseadas no modelo relacional e que pretendem resolver problemas associados à fraca integridade ou redundância dos dados através da perceção da forma como os mesmos se relacionam e se organizam. As metodologias de modelação foi um dos focos de atenção no presente capítulo. Estas consistem num conjunto de regras orientadas para a criação de modelos, ou seja, a modelação. Destacamos a modelação para o desenvolvimento de software destacando a linguagem UML e a modelação da BD que se baseia no Modelo E-R. Por último, foram abordados os Sistemas de Identificação Automática dos quais destacamos o Código de Barras e o RFID percebendo quais as utilizações, vantagens e limitações que se associam a cada sistema. Capítulo 3 Caraterização do SGRC No presente capítulo serão apresentadas todas as caraterísticas necessárias ao desenvolvimento do SGRC. Inicialmente irá abordar-se a empresa em questão e mais especificamente o departamento II – Preparação, de seguida serão identificadas as necessidades para esta aplicação e qual a finalidade e implicações que apresenta. Posto isto, é descrito o processo de tomada de decisão para o projeto. A identificação dos atores e os casos de uso e o levantamento de requisitos, também serão apresentados neste capítulo. Por último e baseado em todas estas caraterísticas é apresentada a arquitetura proposta. 3.1 - Caraterização da Empresa A Continental Mabor foi criada em dezembro de 1989 no distrito de Braga, concelho de Vila Nova de Famalicão, na freguesia de Lousado, visando a Indústria de Pneus. A sua denominação teve origem pela junção de duas empresas: a Mabor e a Continental AG. A Mabor – Manufatura Nacional de Borracha, S.A foi a primeira empresa a produzir no setor de pneumáticos que se estabeleceu em Portugal. O trabalho desta empresa teve início em 1946 como assistência técnica ao abrigo da empresa americana General Tire (E.U.A). No período que antecedeu a junção, a Mabor era reconhecida a nível nacional pelo trabalho que desenvolvia. A Continental AG. foi fundada em 1871 em Hanover, na Alemanha, e produzia, à época, artefactos de borracha flexível e pneus maciços para carruagens e bicicletas [34]. Uma ação de reestruturação teve início em julho de 1990 e levou a que, progressivamente, a antiga fábrica da Mabor se tornasse na mais contemporânea e inovadora das 21 unidades do grupo Continental. Foi nesse ano que foi atingida a produção média diária de 5000 pneus, que quadruplicou ao longo do período que decorreu até aos seis anos após a junção, atingindo os 21000 pneus/dia. Nos dias de hoje, a Continental Mabor produz, em média, 51000 pneus por dia, o que faz com que seja reconhecida como a melhor fábrica do Grupo Continental AG. baseada nos elevados índices de produtividade [35]. O Grupo Continental AG. é reconhecido enquanto especialista na produção de:  Sistemas de travagem; 30 Caraterização do SGRC 30  Controlos dinâmicos para viaturas;  Tecnologias de transmissão de potência;  Sistemas eletrónicos e sensores. Apesar da empresa ser comummente associada ao setor automóvel, também produz maquinaria para a indústria Mineira, de Mobiliário e de Impressão. O Grupo Continental AG. está presente em todo o mundo, tendo aproximadamente 150000 colaboradores em seis divisões distintas: Chassis e Segurança, Powertrain, Interior, Pneus para Viaturas de Passageiros e Comerciais Ligeiros, Pneus Pesados e ContiTech. O programa “The Basics”, que constitui a política da empresa, pretende descrever a Visão, os Valores e a Cultura do Grupo Continental. Este documento resume a forma como a empresa relaciona com os Clientes, Colaboradores e Acionistas, bem como o modo como alcança os ambiciosos objetivos no que se refere à qualidade e espírito de cidadania do Grupo Continental. “The Basics” descreve:  A Visão;  Foco Principal – Criação de Valor;  Foco – Stakeholders;  Foco – Produtos e Serviços;  Foco – Espírito de Grupo. Este programa pode ser consultado no Anexo B -. 3.1.1 - As 5 Fases do Processo O processo de produção da Continental Mabor divide-se em 5 fases fundamentais, que se desenvolvem em cinco departamentos, que culminam na criação do produto final. As cinco fases do processo de produção encontram-se sintetizadas no esquema presente na Figura 3.1. As 5 Fases do Processo 31 Figura 3.1 - Fases do Processo de Produção. 1. Departamento I – Misturação: é o departamento no qual se inicia o processo produtivo através da mistura de todos os compostos (borracha, pigmentos, óleo mineral, sílica, entre outros). Neste departamento o trabalho principia com a passagem pelos misturadores constituindo o processo denominado por “Masters”. Caso a receita 5 implique uma segunda mistura, o material é submetido a outro processo denominado “Finais”. Figura 3.2 - Fase 1 – Departamento I – Misturação. 2. Departamento II – Preparação: Neste departamento, subdividido em Quente e Frio, são produzidos os talões 6 , bem como o breaker 7 , os pisos 8 , a tela 9 e as paredes 10 do pneu. As 5 Receita - lista de compostos necessários e especificações a considerar na produção de cada pneu. 6 Talão – Tem como função assegurar o encaixe firme sobre a jante. 7 Breaker – É constituído por cordas de aço de alta resistência, e tem como função preservar a forma do pneu, otimizar a estabilidade direcional e o atrito ao rodar. DEP. I Misturação DEP. II Preparação DEP. III Construção DEP. IV Vulcanização DEP. V Inspeção Final 32 Caraterização do SGRC 32 máquinas utilizadas para esse efeito são as extrusoras, as calandras e as máquinas de corte, que são responsáveis pela preparação dos materiais. Os produtos intermédios seguem em carros de transporte para a próxima fase do processo. Figura 3.3 - Fase 2 – Departamento II – Preparação. 3. Departamento III – Construção: é nesta fase que todos os produtos intermédios produzidos são montados constituindo o “pneu em cru”. Para este procedimento são utilizadas, essencialmente, dois tipos de máquinas, as KM que constroem a carcaça do pneu e as PU que juntam à carcaça o breaker, a tela têxtil e o piso. Figura 3.4 - Fase 3 – Departamento III – Construção. 4. Departamento IV – Vulcanização: o pneu é submetido a elevadas temperaturas nas prensas, adquirindo o seu aspeto final, sendo este processo denominado por vulcanização. Na Continental Mabor existe 246 prensas cada uma com 2 cavidades que permitem vulcanizar 492 pneus em simultâneo. 8 Piso – Tem como funções oferecer aderência em todas as superfícies de estrada, estabilidade direcional, resistência ao desgaste e a explosão de água. 9 Tela – Constituído por Rayon ou Poliéster embutido na borracha, e tem como função controlar a pressão interna e preserva a forma do pneu. 10 Parede – É feita de borracha natural e tem como função proteger o invólucro dos danos externos e das condições atmosféricas Departamento II – Preparação 33 Figura 3.5 - Fase 4 – Departamento IV – Vulcanização. 5. Departamento V – Inspeção Final: é nesta fase em que o pneu já apresenta o seu formato final que a inspeção do mesmo mostra um papel preponderante antes da conclusão do processo. Esta tarefa é executada por colaboradores devidamente formados e instruídos que devem assegurar e garantir que o pneu em análise reúne todos os requisitos de qualidade especificados pelo cliente. É também nesta etapa que o pneu realiza os últimos testes antes de seguir para o armazém de produto acabado como apto para ser posteriormente comercializado. Figura 3.6 – Fase 5 – Departamento V – Inspeção Final. Posto isto, importa agora descrever de forma mais detalhada a fase em que o SGRC se irá enquadrar. 3.1.2 - Departamento II – Preparação O trabalho desenvolvido no departamento II – Preparação pretende garantir a produção dos materiais intermédios ao fabrico do pneu, nomeadamente, as paredes, a tela, a camada, o breaker, o talão e o piso. Após a mistura dos componentes que ocorre no departamento I, os materiais concentramse nesta fase de produção, onde são unidos e calandrados numa máquina denominada por “Calandra” (CAL). Desta fase do processo de produção resultam os Rolos Calandrados (RCs). Os RCs são rolos de tecido têxtil e tecido metálico que são impregnados com borracha. Este produto intermédio apresenta diversas variantes consoante a espessura ou tipo de borracha utilizada ou o diâmetro e espaçamento entre os fios. 34 Caraterização do SGRC 34 Quando os RCs saem da CAL é impressa uma etiqueta de identificação do rolo que o acompanha e quando são encaminhados para um armazém, a que se dá o nome de Patter- Noster (PN), e, posteriormente, para as máquinas de corte. Caso o PN se encontre lotado ou com alguma anomalia, os RCs são enviados diretamente para as máquinas de corte. Apesar de esta ser uma situação invulgar pretende-se que seja uma possibilidade prevista pelo SI que será criado. Atualmente existem na organização cinco máquinas de corte têxtil e cinco de corte metálico, onde é dada continuidade ao processo de produção, com o corte dos RCs têxteis e metálicos produzidos, respetivamente. Cada uma destas máquinas possui um PC da máquina (IPC 11 ) utilizado para o controlo. Existe, ainda, um PC da produção junto às máquinas de corte, sendo comum entre algumas delas, que é utilizado para inserir dados da produção. As máquinas de corte metálico são utilizadas para o corte dos RCs metálicos, onde são cortados com uma largura e ângulo de acordo com a especificação do pneu, e dão origem ao material designado por Breaker, que será utilizado no departamento III - Construção. As máquinas de corte têxtil, cortam os RCs têxteis com uma determinada largura e ângulo dependendo da especificação do pneu, e originam, dependendo da máquina de corte, os materiais: Tela, Reforço 12 , Espiral Caply 13 e Bobinas. Estes materiais, após toda a preparação, seguem para o departamento III- Construção para darem continuidade ao processo produtivo. A Figura 3.7 pretende esquematizar através de um diagrama de fluxo o processo executado no departamento II – Preparação, pretendendo ser facilitadora da compreensão do mesmo. 11 IPC - Plataforma de computação baseada em aplicações industriais. 12 Reforço - Tem como finalidade aumentar a estabilidade direcional e permitir maior precisão na direção. 13 Espiral Caply – Constituídas por Nylon embutido na borracha e tem como função aumentar a capacidade de atingir altas velocidades. Necessidades da Empresa 35 Figura 3.7 - Diagrama de fluxo do departamento II – Preparação. Após a preparação dos materiais, que inclui a calandragem e o corte, os materiais são armazenados em cassetes e enviados para o departamento III – Construção para dar continuidade ao processo de construção do Pneu. Conhecida a realidade empresarial, particularmente, no contexto que o sistema se irá inserir, importa perceber quais as necessidades que a empresa apresenta. 3.2 - Necessidades da Empresa As necessidades operacionais surgem da identificação de alguma falha ou aspeto possível de ser melhorado ao longo da execução de um determinado processo [7]. Estas podem estar associadas à totalidade ou a uma parte desse processo e podem influenciar a forma como o mesmo decorre, assim como, a qualidade do produto final. Neste sentido, torna-se fácil perceber que qualquer tentativa de resolução de uma necessidade operacional, nomeadamente, ao nível da gestão de informação, poderá ter influência no desenrolar de todo o processo de produção. 36 Caraterização do SGRC 36 No primeiro contacto com a empresa, Continental Mabor, das variadas necessidades existentes na empresa, a primeira a ser reconhecida e verbalizada foi a necessidade ao nível da gestão da informação. Posto isto, verificou-se que várias eram as informações que a empresa não dispunha de forma rigorosa, entre as quais:  Qual a localização de cada RC;  Que RCs existem no sistema fabril e armazenados no PN;  Que posições ocupam os RCs no PN;  Para cada pneu fabricado qual o RC utilizado, entre outros. A falta destas informações impulsionou a identificação, de forma mais detalhada, das reais necessidades da empresa neste âmbito. Se outrora o processo produtivo era realizado tendo por base a informação que era transmitida entre os colaboradores, o constante incremento da competitividade interempresarial tem fomentado a necessidade, por parte das empresas, de trabalharem para fazer mais e melhor, aumentando não só a eficácia mas também a eficiência dos seus processos de produção. Posto isto, e reconhecendo a necessidade de tornar o acesso à informação mais sistemático e organizado, promovendo a gestão da informação, definiu-se esta como uma área relevante para intervenção. De forma a focalizar as áreas com necessidade de intervenção, tornou-se preponderante a perceção, em rigor, de quais as áreas que poderiam ser trabalhadas e quais os aspetos de maior relevo. Neste sentido, e tendo como foco principal a gestão da informação, foi reportada a necessidade de intervenção, nos diversos níveis, para que fosse possível:  Consultar a informação em qualquer ponto da fábrica;  Identificar os meios de armazenamento utilizados;  Transmitir a informação a processos a jusante;  Proceder ao registo das entradas e saídas de material para stock;  Identificar qual a localização do material;  Possibilitar uma maior velocidade de resposta às solicitações de material;  Minimizar os erros, as deslocações dos colaboradores e os custos de mão-de-obra tornando o processo o mais eficiente e eficaz possível;  Identificar a máquina de consumo no qual cada RC é utilizado. Estas necessidades foram as reportadas numa primeira fase, aquando da análise e desenho do SI. Mais tarde, na fase de desenvolvimento, foram descritas mais necessidades das quais se destaca a falta de comunicação entre os SIs existentes na organização. Assim sendo, face às necessidades apresentadas, o desenvolvimento de um SI que correspondesse às expetativas previamente analisadas era já há muito esperado no contexto empresarial e reconhecido como crucial. Importa assim perceber qual a finalidade e as implicações da inclusão deste sistema no quotidiano laboral. 3.3 - Finalidade e Implicações A finalidade da criação do SGRC passa por permitir uma série de funcionalidades anteriormente inexistentes na empresa. As funcionalidades passam por permitir ao utilizador: Finalidade e Implicações 37  Ter acesso aos stocks em tempo-real – possibilitando o planeamento da produção de RCs baseado em dados quantitativos provenientes da realização do inventário;  Consultar toda a informação relativa aos rolos – nomeadamente o histórico dos RCs produzidos de forma mais eficiente, permitindo desde logo o acesso à informação relativa às ocorrências de cada rolo o que alerta para a necessidade de acompanhamento no consumo do mesmo;  Consultar a rastreabilidade dos RCs – sabendo todas as localizações dos RCs no PN;  Consultar toda a informação sobre o PN – saber quais as localizações possíveis no PN, qual o estado em que se encontram (livre/ocupado) e qual o rolo que ocupa cada posição;  Ter acesso à informação dos meios de armazenamento utilizados em cada rolo – identificar a caneleira 14 e o linner 15 que é utilizado para o armazenamento de cada rolo;  Criar o histórico das produções dos materiais calandrados – consultar RCs produzidos, podendo consultar o seu histórico sempre que haja necessidade;  Criar o histórico do consumo dos rolos na secção de Corte – consultar RCs consumidos e máquina respetiva;  Exportar toda a informação da BD para outras análises – permitindo trabalhar a informação de forma a atingir objetivos a que o utilizador se proponha;  Avaliar a qualidade dos materiais produzidos – reconhecendo as ocorrências mencionadas aquando a produção dos RCs e comparando e analisando o scrap 16 gerado por cada rolo;  Consultar os artigos produzidos por cada RC – consultar a associação existente entre os rolos calandrados e os artigos que são produzidos. Face às necessidades e finalidade do SGRC surgiram implicações. Estas poderão passar pela articulação do SGRC com SIs existentes na organização e na implementação de sistemas de identificação automática para permitir uma maior eficiência na identificação da informação. Assim, tornou-se preponderante o conhecimento dos SIs já existentes para contextualização do presente projeto na realidade empresarial. Atualmente, a Continental Mabor, dispõe de diversos SIs, entre os quais destacamos três:  Conti. Basic Data Acquisition (CBDAS) – pretende gerir os dados referentes aos tempos de interrupção na utilização dos equipamentos de produção, seus motivos e artigos 17 produzidos por cada máquina;  Scrap Attack (SA) – tem como finalidade reunir os dados referentes ao tipo de scrap gerado por máquina e por turno de trabalho; 14 Caneleira - dispositivo de suporte cilíndrico onde é enrolado o material calandrado que dará origem ao RC e onde se mantém até ser consumido. 15 Linner - revestimento que acompanha o material calandrado enquanto é enrolado na caneleira não permitindo o contacto entre voltas sucessivas no dispositivo de suporte cilíndrico. 16 Scrap – desperdício material gerado ao longo do processo produtivo. 17 Artigos – produtos intermédios produzidos. 44 Caraterização do SGRC 44 O Use Case permite aos atores do sistema consultar os RCs que foram utilizados por cada máquina de consumo.  Pesquisar os RCs Produzidos Por Estilo Material O Use Case permite aos atores do sistema consultar os RCs que foram utilizados por cada estilo de material. Identificados os casos de uso, torna-se preponderante a descrição dos mesmos, pelo que, será apresentada no Anexo C -. Posto isto, a apresentação dos casos de uso através de um diagrama de pacotes é fundamental para melhor compreender a organização destes. Assim, este é o foco de atenção para o subcapítulo que se segue. 3.6.2 - Pacotes A representação dos casos de uso através de um diagrama permite ilustrar os atores e as relações que estabelecem. Esta apresentação é útil para a modelação, enfatizando a identificação da fronteira do sistema, dos atores e no significado das funções, assim como, na definição das funcionalidades do sistema independentemente da forma como o realiza. Assim, de forma a obter uma melhor organização dos casos de uso, na Figura 3.9 é apresentado o diagrama de pacotes. Figura 3.9 - Diagrama de Pacotes. Dada esta divisão, torna-se importante detalhar cada pacote. Assim, as figuras Figura 3.10 e Figura 3.11 pretendem demonstrar os diagramas de casos de uso relativos ao pacote de gestão de utilizadores e gestão de RCs, respetivamente. Nas figuras seguintes, Figura 3.12, Figura 3.13, Figura 3.14, Figura 3.15 são apresentados os diagramas relativos ao pacote de Pacotes 45 gestão do Patter-Noster, gestão de máquinas, gestão de estilo de material e gestão de colaboradores, respetivamente. O pacote de gestão de utilizadores, representado na Figura 3.10, disponibiliza as funcionalidades usuais de gestão de um sistema, permitindo ao utilizador pesquisar, editar e eliminar, assim como adicionar novos utilizadores. O Administrador é o único ator que pode manipular todos estes dados. Figura 3.10 - Diagrama de casos de uso: pacote de gestão de utilizadores. A Figura 3.11 representa o pacote de gestão de RCs sendo este o mais relevante do sistema. Este disponibiliza as funcionalidades de gestão de RCs, permitindo ao utilizador pesquisar, editar e exportar, assim como, adicionar novos RCs, entre muitas outras funcionalidades. 46 Caraterização do SGRC 46 Figura 3.11 - Diagrama de casos de uso: pacote de gestão de RCs. O pacote de gestão do Patter-Noster, representado na Figura 3.12, tem como objetivo permitir a monitorização do PN. Existe também a possibilidade de inserir, editar, apagar e consultar toda a informação disponibilizada. Figura 3.12 - Diagrama de casos de uso: pacote de gestão do Patter-Noster. A Figura 3.13 representa os casos de uso relativos ao pacote de gestão de máquinas. Este contempla diversos casos de uso com a finalidade de tornar a aplicação facilmente adaptável ao crescimento da empresa. Pacotes 47 Figura 3.13 - Diagrama de casos de uso: pacote de gestão de máquinas. O pacote que se segue, Figura 3.14, visa possibilitar a consulta de todos os estilos de material existente, permitindo inserir, editar, apagar e/ou consultar toda a informação pertinente. Figura 3.14 - Diagrama de casos de uso: pacote de gestão de Estilo de Material. Por último, o pacote de gestão de operadores, ilustrado na Figura 3.15, permite na mesma linha dos anteriores, a consulta de todos os operadores existentes assim como a inserir, editar, apagar e consultar toda a informação disponibilizada. 48 Caraterização do SGRC 48 Figura 3.15 - Diagrama de casos de uso: pacote de gestão de operadores. Identificados e apresentados todos os casos de uso, será realizada, no Anexo C -, uma descrição dos mesmos. Esta descrição pode ser representada de várias formas como visto no subcapítulo 2.4.1 - Unified Modeling Language (UML). Assim, e dada a simplicidade dos casos de uso em análise, optou-se por efetuar esta descrição textual e não recorrendo aos diagramas do UML. 3.7 - Análise de Requisitos Um requisito consiste numa “funcionalidade ou condição que o sistema deverá possuir” [10] culminando na perceção da forma como o sistema deverá funcionar para o utilizador. Os requisitos podem ser funcionais ou não funcionais. Considera-se requisito funcional quando “descreve uma determinada ação (ou função) que o sistema deverá suportar” [10] em contrapartida, os requisitos não funcionais definem características, não funcionais, que o sistema deverá apresentar e que estão, muitas vezes, associadas a aspetos gerais do sistema como a fiabilidade, a segurança, o desempenho, entre outros. No desenvolvimento do presente projeto, o levantamento de requisitos processou-se através de reuniões com representantes da empresa na qual foi elaborada uma lista em que foram enumerados os requisitos à elaboração do Sistema de Informação (SI), assim como, as funcionalidades que era expectável que o sistema apresentasse. Requisitos Funcionais 49 3.7.1 - Requisitos Funcionais Tendo como linha orientadora o desenvolvimento de um SI que possibilite o acesso e a gestão de forma simples, rápida e eficaz da informação relativa aos RCs, os requisitos funcionais que foram acordados com a empresa são descritos ao longo da Tabela 3.3. Esta tabela encontra-se dividida em cinco colunas que incluem elementos de caracterização de cada um dos requisitos funcionais. O primeiro elemento diz respeito ao identificador atribuído ao requisito. De seguida, é descrito qual o requisito a que este identificador se refere. Posteriormente, é avaliada a utilidade que o requisito apresenta para a empresa e a prioridade que lhe é atribuída para inclusão no desenvolvimento do SI, baseada no tempo de desenvolvimento que se prevê para cada requisito e na utilidade que cada um representa para a empresa. A utilidade e a prioridade são estabelecidas, quantitativamente, de acordo com uma escala de três níveis, de um a três, como definido na Tabela 3.2. Tabela 3.2 - Escala de avaliação da utilidade e da prioridade. 3 Alta 2 Intermédia 1 Baixa Por último, considera-se a fase em que foram apresentados os requisitos. Dado que a empresa referiu os requisitos que pretendia que fossem integrados no desenvolvimento do sistema em diferentes espaços temporais, a sua inclusão deu-se em duas fases. A primeira fase diz respeito aos requisitos que foram descritos antes de iniciar o desenvolvimento da aplicação e a segunda fase refere-se aos requisitos que foram acrescentados durante o desenvolvimento da aplicação a pedido da empresa. Em suma, pode-se observar na Tabela 3.3 os requisitos que foram determinados para o desenvolvimento da aplicação. Tabela 3.3 - Identificação dos requisitos funcionais. ID Requisito Utilidade Prioridade Fase 1 Apresentar na página inicial a quantidade de RCs produzidos entre datas 2 1 1 2 Gerir diferentes tipos de utilizadores 3 3 1 3 Inserir, editar e apagar informação de um RC 3 3 1 4 Consultar detalhadamente a informação de um RC 3 3 1 5 Adicionar informação complementar (localização, meios de armazenamento e máquina de consumo) ao RC 2 3 1 6 Consultar todas as localizações por onde o RC passou 3 2 1 7 Inserir, editar e apagar informação da localização do RC 3 3 1 8 Inserir, editar e apagar informação de uma localização 2 2 1 9 Exportar histórico dos RCs produzidos 3 3 1 10 Filtrar e ordenar informação de qualquer um dos campos, presentes na tabela de RCs e PN 2 1 1 50 Caraterização do SGRC 50 11 Consultar de uma forma eficiente os RCs consumidos e por consumir 2 3 2 12 Consultar localizações do PN e seu estado de ocupação 3 3 2 13 Consultar e pesquisar máquinas de produção 2 3 2 14 Inserir, editar e apagar informação de uma máquina de produção 2 2 2 15 Consultar e pesquisar máquinas de consumo 2 3 2 16 Inserir, editar e apagar informação de uma máquina de consumo 2 2 2 17 Consultar e pesquisar estilos de materiais 2 2 2 18 Inserir, editar e apagar informação de um estilo de material 2 2 2 19 Consultar e pesquisar operadores dos RCs 2 2 2 20 Inserir, editar e apagar informação de um operador 1 1 2 21 Consultar e pesquisar utilizadores do SI 2 2 2 22 Inserir, editar e apagar informação de um utilizador do SI 2 2 2 23 Apresentar na página inicial a quantidade de RCs em stock 3 3 2 De salientar que as funcionalidades que deram origem aos requisitos funcionais foram analisadas, detalhadamente, no subcapítulo 3.6 - Casos de Uso. 3.7.2 - Requisitos Não-Funcionais O presente subcapítulo pretende apresentar as características não funcionais do SGRC que se encontram listadas de seguida.  Usabilidade O SGRC terá como principais utilizadores os operadores. Posto isto, e tendo em conta o quotidiano laboral, pretende-se que esta seja uma aplicação de fácil aceitação e integração no contexto tornando-se uma ferramenta de uso diário pelos utilizadores. Neste sentido, uma das principais preocupações no seu desenvolvimento será a facilidade de uso. Assim, é primordial que todas as funcionalidades da aplicação surjam de forma intuitiva e que a acessibilidade seja possível, facilmente, através de um Web browser. Para responder a este requisito, no desenvolvimento da aplicação, irá optar-se por disponibilizar interfaces semelhantes às já utilizadas, noutros contextos na empresa, pois a grande maioria dos utilizadores já estará familiarizado.  Compatibilidade Pretende-se que o sistema seja compatível com os seguintes Web browsers: o Internet Explorer versão 8.0 ou superior; o Mozilla Firefox versão 17.0.5 ou superior; o Google Chrome versão 26.0.1410.64 ou superior.  Robustez Arquitetura Geral do Sistema 51 É uma caraterística muito importante visto que representa um dos fatores de interesse e que pode cativar o utilizador a explorar todas as funcionalidades que esta aplicação lhe oferece. Particularmente, o sistema deve garantir a consistência dos dados. A baixa robustez da aplicação poderá estar associada a erros ou comportamentos inesperados o que pode implicar que os utilizadores não construam uma relação de dependência com a aplicação, podendo implicar o seu desuso.  Desempenho O sistema deve responder de forma rápida e eficaz a cada ação. A resposta lenta pode contribuir para o desinteresse dos utilizadores e para a vontade de retornar à utilização de métodos antigos. Como critério foi definido que o sistema não deverá demorar mais de 3 a 4 segundos a responder a um pedido de apresentação de uma página.  Adaptabilidade O sistema deverá permitir um crescimento do volume da informação, ao longo do tempo, mantendo os requisitos de desempenho. Deverá também, garantir o acompanhamento da expansão da organização e evitar a adoção de outras aplicações ou de uma nova fase de desenvolvimento para se adaptar à nova realidade.  Segurança De todos os requisitos, a segurança reveste-se de um papel primordial a ter em consideração no desenvolvimento do SI. Neste sentido, o acesso aos dados deverá ser restri- to e o sistema deverá validar a autorização do acesso a estes, garantindo, assim, a confidencialidade dos mesmos durante a sua transmissão, para isso é necessário que o utilizador proceda à: - Autenticação: o utilizador deverá apresentar credenciais válidas, no mínimo, um número de utilizador e uma palavra-passe; - Autorização: as ações a que o utilizador tem acesso na aplicação estão condicionadas ao seu perfil. 3.8 - Arquitetura Geral do Sistema A identificação dos requisitos para o desenvolvimento do sistema e dos casos de uso culmina na necessidade de identificar quais as atividades que deveriam ser desenvolvidas de modo a dar resposta às necessidades analisadas, nomeadamente, quais as técnicas e arquiteturas. Desta forma, a seleção de um modelo que orientasse o desenvolvimento integral da aplicação tornou-se basilar, pois só assim é possível fracionar a problemática complexa em módulos que se mostrem mais facilmente solucionáveis e, em última análise, o alcançar dos objetivos definidos. Assim, a necessidade de perceber de que forma os componentes da aplicação se enquadram conjuntamente e se relacionam entre si, torna-se preponderante a definição de uma arquitetura baseada num modelo teórico que a sustente. Neste sentido recorreu-se ao padrão Model-View-Controller (MVC). Este padrão, usualmente conhecido como arquitetura de três níveis encontra-se representado graficamente na Figura 3.16. 52 Caraterização do SGRC 52 Figura 3.16- Arquitetura MVC. Os três níveis que compõem o Model-View-Controller (MVC) são:  A Base de dados (Model) é a camada na qual é feito o armazenamento da informação que o sistema utiliza e armazena, ou seja, é onde se encontra toda a informação manipulada pelo sistema. A informação aqui contida é enviada para o nível de lógica e eventualmente para o utilizador. A camada Model teve como finalidade definir e gerir o domínio da informação, manipular e representar a informação detalhada fornecida pelo utilizador à aplicação. Aqui são criadas as regras do negócio representadas sob a forma de tabelas, campos, estruturas, relações entre tabelas etc. A base de dados criada para a camada model será explicada no subcapítulo 4.3 - Base de Dados.  A camada da Lógica de negócio (Controller) é a que se encontra responsável por controlar as funcionalidades, processar os comandos e tomar as decisões lógicas, ao mesmo tempo que, estabelece a comunicação entre a BD e a Interface do sistema. É nesta camada que os dados são processados e tratados e a comunicação com os vários módulos que compõem o sistema é assegurada, sendo responsável por um bom funcionamento geral do SI. Aqui, garante-se a consistência dos dados e o seguimento das regras de negócio. Dado que será desenvolvida uma aplicação web em HTML, o controlador terá de receber a entrada dos dados pelo método GET ou POST. Após o estímulo do utilizador, esta camada tem de decidir como processar os dados, invocando objetos do sistema para tratar toda a lógica de negócio, e por fim invocar uma visão para apresentar a saída.  A Interface com o utilizador (View) é o nível mais alto e, portanto, a face do sistema visível para o utilizador e com a qual interage. Tem como objetivo apresentar o modelo de negócio ao utilizador com a apresentação dos dados. Esta camada comunica com o Controller, nomeadamente, pela receção dos dados requeridos e do envio de dados introduzidos. Esta camada tem como função apresentar as perguntas e respostas ao utilizador conforme os dados pretendidos pelo controlador e pelo utilizador. Assim, a camada View é utilizada fundamentalmente para entrada e saída de dados e para apresentar, de forma mais organizada, todos estes dados. Esta arquitetura é vantajosa pois permite que qualquer um dos níveis seja modificado ou substituído sem que seja necessário fazer reformas em nenhum dos outros níveis. Para além da vantagem anteriormente referida, é de salientar que esta arquitetura se encontra muito presente no desenvolvimento Web, estando a camada de interface associada aos elementos estáticos do servidor Web, que são apresentados num browser. A camada de interface é apre- View Controller Model Arquitetura Geral do Sistema 53 sentada através de um browser, a camada intermédia de lógica corresponde ao servidor de aplicação, neste caso PHP, enquanto a camada de dados estará alojada num sistema de gestão de base de dados (SQLServer). Utilizaremos outra BD (CBDAS) para receber os dados provenientes da produção dos RCs da CAL. O MVC, por se tratar de uma arquitetura modular, permite facilitar a organização. Aliadas a esta vantagem existem outras que justificaram a escolha deste tipo de arquitetura para suportar o desenvolvimento do SGRC. A possibilidade e a simplicidade no reaproveitamento do código em progressos ou alterações e a facilidade na manutenção são outras das vantagens que suportaram a seleção deste tipo de arquitetura. Ainda de referir a distinção e separação entre a face visível e a de programação do controlo subjacente ao sistema. Numa fase final, a aplicação deste tipo de arquitetura apresenta inúmeros benefícios, particularmente, por permitir a realização de testes e manutenções isoladas e direcionadas a cada uma das camadas, a facilidade na garantia de segurança no sistema e na sua organização devido à modularidade. Posto isto, foi definida a arquitetura da aplicação que se encontra sistematizada e esquematizada na Figura 3.17. Figura 3.17 - Arquitetura da aplicação. O sistema é portanto composto por três camadas: Model, Controller e View. Pretende-se que o sistema seja constituído por:  uma interface Web desenvolvida em HTML, CSS e Javascript,  uma camada de lógica de negócio desenvolvida em PHP e  uma base de dados SQLServer na versão 2005. 60 SGRC- Desenvolvimento 60  Entidade MáqConsumo: o O id tem de ser único e numérico; o O ano tem de ser numérico;  Entidade EstiloMaterial: o O id tem de ser único e numérico; o A espessura tem de ser numérico;  Entidade Localização: o O id tem de ser único e numérico; o O estado tem de ser binário;  Entidade Rolo: o O código de barras tem de ser único e numérico; o As datas têm de ter o formato AAAA-MM-DD; o Os códigos de caneleira e linner têm de ser numéricos; o As horas têm de ser no formato HH:MM:SS; o A velocidade tem de ser numérico. Para além das regras indicadas, há que considerar outras possibilidades que, apesar de não se enquadrarem nas regras acima, merecem ser consideradas. Estas consistem no caso de o utilizador não preencher todos os campos obrigatórios dos formulários, o sistema gera um alerta a notificá-lo para que complete o(s) campo(s) em falta. De referir que podem existir atributos opcionais, isto é, não necessários, como por exemplo na entidade Rolo os atributos pale3 e dpal3 podem não ser preenchidos por nenhum valor se estes não se verificarem no rolo produzido, pelo que existem campos de preenchimento obrigatório e outros de preenchimento opcional. Para o desenvolvimento da aplicação foi definida uma organização dos ficheiros onde se encontra o código que se encontra esquematizada na Figura 4.2. Da organização do código fazem parte: Desenvolvimento da aplicação 61 Figura 4.2 - Organização do Código.  A estruturação do código inicia-se com a pasta denominada “actions” onde são criadas todas as ações da aplicação;  Segue-se a pasta chamada “ajax” que abarca todas as funções criadas para gerar os gráficos da página inicial;  A pasta “common” tem no seu interior um ficheiro chamado “init.php”, que inclui todas as referências do código, isto é, é neste ficheiro que criamos a ligação à BD e definimos a BASE_URL da aplicação;  A pasta “database” contempla todas as querys feitas à BD;  Seguidamente encontram-se presentes as pastas "documentos" e "imagens" que foram criadas com o intuito de guardar todas as imagens e documentos necessários para a aplicação;  O ficheiro “index.php” apenas redireciona para a página inicial do sistema. A pasta “javascript” inclui as funções Keyup para pesquisa de dados, assim como, a função datepicker, entre muitas outras;  As pastas “lib” e “templates_c” são referentes à biblioteca Smarty e é onde é feita a compilação dos templates utilizados na aplicação;  A pasta “pages” tem no seu interior os ficheiros responsáveis pela gestão de cada página;  A pasta “style” envolve o ficheiro responsável pela disposição e formatação dos elementos constituintes de cada página;  A pasta “templates” contém todo o código HTML da aplicação, sendo nesta pasta que é trabalhada toda a face visível do browser. Posto isto, e após termos percebido a forma como se enquadrou o desenvolvimento da aplicação, reveste-se de fundamental importância compreender como se processam as interfaces gráficas. 62 SGRC- Desenvolvimento 62 4.5 - Interfaces gráficas Este subcapítulo pretende apresentar o desenvolvimento das interfaces gráficas que representam um papel fundamental para esta aplicação. Assim, e de acordo com os requisitos, pretendia-se desenvolver uma interface intuitiva, simples de utilizar, dinâmica e de fácil aprendizagem. Na abordagem das interfaces gráficas pretendia-se perceber de que forma se podia trabalhar a apresentação dos dados ao utilizador. Assim, o SGRC consiste numa aplicação WEB à qual se poderá aceder através de um navegador de internet, que se encontra presente em qualquer ponto de acesso à internet dentro da organização. O utilizador, através da interface gráfica presente no navegador, poderá visualizar a informação relativa aos RCs, máquinas de produção, máquinas de consumo, PN, estilos de material e utilizadores. A aplicação permitirá ao utilizador consultar os dados e, também, um conjunto de funcionalidades que possibilitam adicionar, editar e/ou eliminar entidades da aplicação. Através do uso destas funcionalidades, internamente, na lógica do negócio da aplicação são recebidos pedidos que proporcionam uma interação entre a aplicação e a BD. Assim, são apresentados os dados solicitados pelo utilizador ou, por outro lado, são adicionadas, apagadas ou editadas as identidades que o utilizador pediu. Na Figura 4.3 encontra-se representada a arquitetura de toda esta dinâmica. Figura 4.3 - Arquitetura de apresentação de dados. Posto isto, o primeiro passo para o desenvolvimento das interfaces consistiu na realização de um esboço realizado através do programa Microsoft PowerPoint. Esta tarefa pretendia, para além de dar a conhecer os traços gerais da aplicação, antever alterações necessárias ou possíveis dificuldades antes de iniciar o desenvolvimento propriamente dito. A articulação com o cliente e a obtenção do seu feedback era outra das motivações para a realização do esboço, de forma a corresponder às suas expetativas. Concluído o esboço e acertadas as alterações necessárias com o cliente, procedeu-se ao desenvolvimento da aplicação com a definição de um template para a mesma. Este template é apresentado na Figura 4.4. Interfaces gráficas 63 Figura 4.4 - Template criado para o SGRC. O template divide-se em três partes fundamentais: cabeçalho, corpo da página e rodapé. O cabeçalho inicia-se com o nome dado ao SI, constituindo-se o logótipo do sistema, segue-se a barra de login onde é apresentado o número do utilizador e a hora atual e finaliza-se com uma barra de menu que visa permitir navegar entre páginas. O corpo da página onde são apresentadas as informações relevantes de acordo com a página selecionada, diferindo entre cada página do menu. O template termina com o rodapé onde se visualiza o logótipo da empresa, a indicação dos direitos de autor, a identificação do autor, o ano de criação do sistema e link para contactos. A análise de todas as interfaces desenvolvidas tornar-se-ia demasiado exaustiva e de interesse reduzido, pelo que, se optou por apresentar e esclarecer os exemplos mais demonstrativos da generalidade do funcionamento e visual da aplicação, assim como, os casos particulares mais relevantes que serão apresentados de acordo com a divisão efetuada no subcapítulo 3.6.2 - Pacotes. Será usado o utilizador “Administrador” a título de exemplo. 64 SGRC- Desenvolvimento 64 Utilizadores: O primeiro grande desafio foi desenvolver o sistema de autenticação. O objetivo era desenvolver um sistema fiável, baseado em sessões para evitar o constante envio do username e password do utilizador. Quando o utilizador efetua o login é calculada uma hash 18 (utilizando o algoritmo MD5) do seu username e password e é enviado para o servidor o seu username e o hash calculado. No lado da base de dados, é calculado o hash do username e password que estão guardadas e é depois comparado com o que foi recebido. Se a semelhança se verificar é criada uma nova sessão e guardada numa variável de sessão do PHP. Na Figura 4.5 é visível a interface criada. Figura 4.5 - Login do SGRC. Para aceder ao sistema o utilizador deverá preencher, obrigatoriamente, os campos “utilizador” e “password” com o seu nº de colaborador e palavra-passe, respetivamente. Caso não se verifique o preenchimento de pelo menos um dos campos o sistema gera, automaticamente, um alerta requerendo ao utilizador que preencha o(s) campo(s) em falta. A Figura 4.6 e Figura 4.7 pretende demostrar dois desses casos, o primeiro referente ao não preenchimen- to do campo “utilizador” e o segundo ao campo “password”. Figura 4.6 - Alerta gerado devido a utilizador incorreto. Figura 4.7 - Alerta gerado devido à falta de password. 18 Hash - sequência de bits geradas por um algoritmo de dispersão. Interfaces gráficas 65 Todos os formulários desta aplicação foram, em parte, desenvolvidos recorrendo à linguagem Javascript para permitir o feedback ao utilizador de possíveis erros no formulário antes da sua submissão. RCs: Este módulo é o mais complexo de todo o sistema pelo que foi o que implicou uma maior dedicação, empenho e tempo de trabalho. Será nesta página que o utilizador poderá consultar toda a informação relativa aos RCs, como por exemplo as quantidades produzidas em stock, entre muitas outras informações relevantes. Uma preocupação no desenvolvimento do sistema foi a presença de duas características que foram entendidas como fundamentais: a interface interativa e, ao mesmo tempo, a simplicidade de utilização. Assim, a Figura 4.8 pretende, demonstrar essas características, presentes no menu dos RCs. Figura 4.8 - Menu de consulta de RCs. No “Menu de Consulta do RCs” é possível:  visualizar a lista de RCs produzidos,; 66 SGRC- Desenvolvimento 66  mudar de página através do botão “inserir” e, consequentemente registar manualmente um novo RC;  exportar informação;  consultar os detalhes de cada rolo. Toda a informação disponível pode ser: filtrada através dos campos abaixo da primeira linha de cada coluna e/ou ordenada de forma ascendente/descendente de acordo com a informação disponível na coluna “Número”. Foi, também, criado, adicionalmente, um seletor onde o utilizador pode facilmente escolher quais as colunas que deseja ver/esconder. Devido às caraterísticas da página, na visualização principal, optou-se por mostrar apenas as colunas definidas pelo cliente como mais relevantes, que permite uma consulta mais generalizada. A Figura 4.9 demonstra o corpo da página de detalhe de cada RC. Figura 4.9 - Menu de detalhe de um RC. Interfaces gráficas 67 Nesta página pode-se consultar toda a informação do RC, sendo possível adicionar uma nova localização ao rolo, permanecendo todas as localizações registadas no seu histórico. O administrador do sistema, também pode alterar ou apagar o RC. Na Figura 4.10 é possível observar o corpo da página inicial do SI onde são visíveis os gráficos ilustrativos da produção de RCs e do stock disponível no PN. Esta página permite ao utilizador delimitar o espaço temporal, através dos campos “Data inicial” e “Data final”, dos quais são provenientes os dados presentes nos gráficos. Figura 4.10 - Gráficos de material produzido e de stock. Toda a informação necessária para desenhar os gráficos é carregada utilizando AJAX 19 para evitar ter de recarregar toda a página. Desta forma, apenas os gráficos são recarregados, diminuindo o tempo de resposta e aumentando desempenho da interface. Esta interface foi pensada para facilitar a perceção do utilizador e para transmitir uma visão geral das produções e stocks de RCs. 19 AJAX – Significa Asynchronous Javascript and XML, e resume-se no uso metodológico de tecnologias como Javascript e XML, providas por web browsers, para tornar páginas web mais interativas com o usuário, utilizando-se de solicitações assíncronas de informações. 68 SGRC- Desenvolvimento 68 A Figura 4.11 pretende demonstrar a página referente à inserção de um RC no PN. Figura 4.11 – Corpo da página para inserir um RC no PN. Nesta página o utilizador deverá identificar o RC através do CB presente na etiqueta impressa correspondente, inserir os códigos dos meios de armazenamento e a localização que o RC ocupará no PN. Após a inserção do CB, o utilizador pode verificar quais os campos já preenchidos de forma automática e validar a informação disponível através da verificação com os campos da etiqueta. Patter-Noster: A Figura 4.12 tem como finalidade demonstrar a interface desenvolvida para consulta do PN. Interfaces gráficas 69 Figura 4.12 - Menu de consulta do PN. Com esta página é possível consultar todas as localizações existentes no PN, assim como, o seu estado (livre ou ocupado). Caso o estado se apresente como Ocupado, é possível identificar qual o RC que o ocupa. As funcionalidades de filtrar informação são idênticas ao menu dos RCs. Operadores: A Figura 4.13 pretende representar o menu dos operadores. Figura 4.13 - Menu de Consulta dos Operadores. Esta página apresenta a lista de operadores existentes no SI. Nesta pesquisa é possível consultar a tabela que inclui os dados relativos ao número do colaborador, o nome, a equipa de que faz parte e os rolos produzidos. Esta funcionalidade foi desenvolvida, de modo a con- 76 SGRC- Desenvolvimento 76 Figura 4.17 - Teste Adaptabilidade: Inserir RC no PN. Na Figura 4.17 é visível a lista de operadores existentes aquando da escolha deste, que coincide com a apresentada na Figura 4.16, atualizando-se de acordo com a adição ou supressão de operadores. Assim, a partir dos exemplos da Figura 4.16 e Figura 4.17 podemos concluir que o sistema acompanha o crescimento da empresa e portanto cumpre o requisito estabelecido.  Segurança O teste relativo à segurança da aplicação passa por verificar o sistema de login de forma a avaliar a sua resposta. Para tal, um dos testes aplicados consistiu em escrever o link da página do menu referente ao “Estilo de material” na URL do browser para verificar se a aplicação permitia aceder à página. A resposta do sistema consistiu no reencaminhamento para a página inicial, concluindo-se que caso não seja efetuado, primeiramente, o login no sistema, este não permite abrir qualquer página da aplicação, à exceção da inicial. Resultados dos Testes 77 Outro teste realizado na perspetiva de avaliar a segurança da aplicação, consistiu na tentativa de entrar numa página à qual o utilizador não tem permissão. Para isso, utilizou-se um utilizador com permissão de Operador e escreveu-se na URL do browser a página destinada à inserção de um novo utilizador. Ao tentar abrir a página o sistema verificou que o utilizador não tinha permissão para tal e redirecionou-o para a página inicial. O terceiro teste de avaliação da segurança, pretendia avaliar a resposta do sistema à tentativa de entrada na aplicação com a inserção de vários utilizadores e passwords. Mas como mostra a Figura 4.18, todas as tentativas tiveram o mesmo resultado, revelando a mensagem “Dados inseridos incorretos” e não permitindo o acesso. Figura 4.18 - Teste Segurança: Login Errado. Por último, foi testado o logout do sistema. Para tal, foi efetuado o login no sistema com o utilizador “1000” e verificou-se que ao premir o botão “logout”, como ilustrado na Figura 4.19, o sistema redireciona o utilizador para a página inicial. Figura 4.19 - Teste Segurança: Logout. Assim conclui-se que o teste, a este nível de segurança mínimo considerado para o requisito de segurança, está de acordo com o previamente estabelecido.  Validação – por parte do cliente Este teste tem como objetivo validar todos os requisitos funcionais definidos no subcapítulo 3.7 - para verificar se todo o desenvolvimento do SI corresponde ao pretendido. Dado que os casos de uso estão cobertos por um ou mais requisitos, foram testados todos estes baseados no seu caso de uso. Assim e a título de exemplo, pretende-se apresentar um dos requisitos mais importantes da aplicação que consiste na gestão de RCs. A Figura 4.20 pretende demonstrar como é feita a alteração dos dados de um RC. 78 SGRC- Desenvolvimento 78 Figura 4.20 - Teste Requisitos: Alterar RC. Na Figura 4.21 é apresentado o formulário a preencher na inserção de um novo RC. Este formulário encontra-se dividido em três secções de forma a facilitar a perceção do utilizador de como se relacionam os campos a preencher, permitindo um preenchimento mais intuitivo de todos eles. Resultados dos Testes 79 Figura 4.21 - Teste Requisitos: Inserir RC. A Figura 4.20 e a Figura 4.21 pretendem demonstrar o cumprimento do requisito identificado no capítulo 3.7 - Análise de Requisitos com o ID 3 que consiste em inserir, editar e apagar informação de um RC. A Figura 4.22 pretende ser facilitadora da implementação do requisito “Consultar localizações do PN e seu estado de ocupação” definido com prioridade alta. 80 SGRC- Desenvolvimento 80 Figura 4.22 - Teste Requisitos: Patter-Noster. O corpo da página apresentado na Figura 4.22 pretende demonstrar a possibilidade de consultar, inserir, editar e apagar informação relativa ao Patter-Noster, permitindo alcançar mais um requisito com sucesso. De salientar que, de forma a não tornar a explicação, dos testes aos requisitos, exaustiva, foram apresentados apenas os requisitos considerados mais importantes, usuais e representativos do sistema, apesar de terem sido verificados e confirmados todos os requisitos enumerados. A título de conclusão podemos afirmar que todos os requisitos foram desenvolvidos e concluídos com sucesso, tanto os estabelecidos na 1ª fase como na 2ª fase mostrando-se complementares e preponderantes ao desenvolvimento do sistema. 4.7 - Síntese No final deste capítulo passamos a conhecer os trabalhos inerentes ao desenvolvimento da aplicação. O conhecimento das ferramentas e linguagens de programação utilizadas, assim como o modelo da BD criada, foram o primeiro passo no desenvolvimento do SGRC. Seguiu-se a descrição da estruturação do código criado, assim como, a apresentação das imagens ilustrativas das principais interfaces gráficas desenvolvidas, e finalizou-se com a identificação e descrição dos testes efetuados ao SI, assim como, dos seus resultados. Síntese 81 Entre as ferramentas utilizadas para o desenvolvimento da aplicação, destacamos o sistema operativo utilizado, o Microsoft Windows na versão XP, e as tecnologias a utilizar, nomeadamente, o SQL Server Management Studio Express, o Xampp e o Notepad++. As linguagens de programação são também abordadas, dando destaque ao SQL, HTML, CSS, JavaScript e PHP que se mostram complementares na programação do SGRC. O desenvolvimento da base de dados foi também descrito no presente capítulo, atendendo ao Modelo Entidade-Relação e Relacional, paralelamente ao da aplicação web que é composto por regras de consistência de forma a garantir a qualidade dos dados que disponibiliza. As interfaces gráficas são também apresentadas, sendo notória a preocupação com a simplicidade, a facilidade de aprendizagem, a dinâmica e a navegação intuitiva. Por último, são apresentados os testes realizados e a validação que recaíram sobre a usabilidade, a robustez, o desempenho, a adaptabilidade, a segurança e a validação dos requisitos funcionais da aplicação. Com todos os testes, tornouse preponderante verificar se todos os requisitos, funcionais e não funcionais, foram atingidos. Concluiu-se que os mesmos foram atingidos com sucesso correspondendo às expetativas iniciais. 82 SGRC- Desenvolvimento 82 Capítulo 5 Conclusão e Desenvolvimentos Futuros Ao longo do documento, mais concretamente no final de cada capítulo, foram sendo apresentadas as conclusões parciais relativas a cada um dos temas em análise. Pelo que, no presente capítulo, pretende-se avaliar a satisfação global dos objetivos a que nos propusemos, tecer algumas considerações finais em relação ao trabalho desenvolvido e apresentar as perspetivas de desenvolvimentos futuros. 5.1 - Conclusão Terminado o período de estágio, e analisando o sistema de informação desenvolvido, é notório que todos os objetivos propostos para esta dissertação foram atingidos com sucesso. Ao longo do desenvolvimento do projeto, foi percebido que poderiam ser introduzidos novos requisitos e, consequentemente, novas funcionalidades que constituiriam mais-valias no seio empresarial. Podemos destacar os requisitos adicionados na fase de desenvolvimento, apresentada como Fase 2 no subcapítulo 3.7 - Análise de Requisitos. Neste sentido, podemos concluir que os objetivos a que nos propusemos, para além de terem sido atingidos, foram ultrapassados com êxito. O presente projeto e o desenvolvimento do SGRC, até à presente data, teve implicações positivas em toda a organização, mais especificamente, no departamento II - Preparação, que resultaram numa melhoria de qualidade na consulta e controlo do material produzido, armazenado e consumido. Este sistema veio alterar os hábitos anteriormente existentes nos colaboradores desta fase de produção. Assim, antes da implementação deste sistema, o operador preenchia uma ficha com todos os materiais produzidos, registando, manualmente, dados como: o número do rolo, o estilo e a equipa que o produziu. Com a utilização deste novo sistema, o operador deixa de participar num processo manual para passar a um processo automatizado. Neste não precisará de escrever, no final do turno, todo o material produzido, pois essa produção já estará registada no SGRC, apenas terá que adicionar, a cada rolo produzido, informação que antes não existia como meios de armazenamento e localização. 84 Conclusões e Desenvolvimentos Futuros 84 Com o SGRC, o utilizador terá a possibilidade de saber todos os materiais utilizados no fabrico de cada pneu, localizar qualquer rolo que se encontre por consumir, consultar o material armazenado e disponível para consumo, associar o scrap gerado ao longo do consumo dos materiais ao número do rolo utilizado, entre outras funcionalidades. De destacar que dado o pouco tempo que decorreu desde a implementação do SGRC no contexto empresarial, não permitiu detetar todos os impactos que este pode representar para a empresa. Posto isto, seria interessante realizar um seguimento de forma a perceber quais as implicações a médio-longo prazo do mesmo, de forma a identificar alguns dos impactos esperados, nomeadamente, ao nível da gestão de stocks, eficiência na consultada de informação, gestão com vista à rentabilização do espaço disponível no PN, entre outros. Em suma, e a título de conclusão, percebemos que o SGRC proporcionou uma vantagem fundamental para uma melhor organização e eficiência nesta fase de produção. 5.2 - Desenvolvimentos Futuros Ao longo do desenvolvimento do presente projeto e, apesar de considerarmos que os objetivos a que nos propusemos foram alcançados, julgamos que existe ainda um conjunto de problemáticas com necessidade de serem trabalhadas e que poderiam também elas representar uma mais-valia para a empresa. Neste sentido, pretende-se que o presente subcapítulo enumere propostas de trabalhos futuros que consideramos pertinentes para desenvolver neste contexto. O estudo e a comparação do desempenho da aplicação criada com diferentes ferramentas de desenvolvimento poderiam ser benéficos para esta. A integração total do SGRC na organização com a presença e utilização dos leitores de CB em todas as máquinas de consumo e no PN era outra das intervenções que poderia representar uma mais-valia para a organização, na medida em que, permitiria a mais fácil identificação do material e o acompanhamento de todas as fases do processo produtivo através do SGRC pelos utilizadores. Uma outra medida que poderia ser facilitadora do trabalho desenvolvido pelos colaboradores seria a utilização de RFID como AIDC para a identificação dos meios de armazenamen- to. Esta estratégia permitiria que o colaborador não tivesse de inserir manualmente o número o que levaria a uma redução do tempo despendido na identificação de um novo rolo no sistema. Um projeto que poderia representar uma vantagem considerável para o funcionamento do departamento II era a integração do SGRC com o PN e com a CAL. Deste modo, após a produção do RC o SI identificaria, automaticamente, a posição que era ocupada no PN e o operador não teria a necessidade de inserir esta informação manualmente. Por fim, destacamos a possibilidade de criar uma interligação do SGRC com a ferramenta SAP da empresa e com todos os outros SIs existentes que guardam a informação dos materiais utilizados no fabrico dos pneus. A criação de uma única ferramenta permitiria a centralização da informação numa única aplicação, o que diminuiria o tempo despendido pela consulta em diferentes sistemas. Posto isto, a proposta para a realização deste trabalho será apresentada à empresa Continental Mabor com o intuito que estas medidas sejam desenvolvidas e que possam contribuir para o melhor desempenho da organização. Anexos Anexo A - Planeamento de Tarefas Como a realização da dissertação envolve um longo período de tempo, é aconselhável a elaboração de um plano de tarefas. O gráfico Gantt é utilizado para determinar a melhor maneira de posicionar as diferentes tarefas de um projeto a executar, bem como, uma visão temporal de compromisso futuro. O planeamento de tarefas foi constituído por duas fases distintas como retratado no diagrama de Gantt, Figura 0.1:  A Fase 1 denominada "Preparação da Dissertação" engloba o planeamento e a análise do desenvolvimento do Sistema de Informação.  A Fase 2, "Componente prática", da qual fazem parte o desenho, o desenvolvimento e a realização dos testes do Sistema criado. Figura 0.1 - Diagrama de Gantt. Todo o trabalho realizado foi devidamente planeado, com o objetivo de alcançar os resultados esperados. De salientar as etapas de maior valor, relativamente à Fase 1 foram sem dúvida, as do estudo do estado da arte e a de análise do sistema. As etapas mais importantes da Fase 2 dizem respeito ao desenho, desenvolvimento, teste e validação e escrita da dissertação. De referir que sempre existiu um total acompanhamento de ambos os orientadores, nas duas fases. 92 Anexos 92 Percurso Principal 1. O Use Case inicia-se quando o ator entra no SI 3. O utilizador poderá escolher entre que datas quer consultar a quantidade produzida, ou por defeito consulta a quantidade produzida dos últimos 30 dias. 2. O sistema mostra a respetiva interface (gráficos com as quantidades de RC produzidos dos últimos 30 dias e gráficos com stock de material disponível) 4. Mostra o filtro efetuado pelo utilizador Percurso Alternativo - - Use Case Consultar lista de RC produzidos Descrição Permite aos atores do sistema consultar a lista geral dos RC produzidos. Atores Administrador, Supervisor, Operador Prioridade Obrigatório Justificação: A prioridade deste Use Case é obrigatória pois representa uma funcionalidade fundamental do sistema, já que permitirá obter a lista de todos os RC produzidos, como também informação detalhada de cada um. Finalidade Consultar informação detalhada dos RC Pré-Condições O ator tem que estar previamente registado no sistema. Pós-Condições O sistema não sofre alterações, apenas são consultados registos da base de dados. Logo não existem pós-condições. Fluxo de Acontecimentos Ações dos Atores Ações do sistema Percurso Principal 1. O Use Case é iniciado quando o ator entra no menu de consulta de RC 3. O ator consulta a informação desejada e 2. Mostra a interface pedida, com tabela e funções de pesquisa e restantes funcionalidades Descrição dos Casos de Uso 93 termina o Use Case. Percurso Alternativo - - Use Case Exportar informação dos RCs Descrição Permite aos atores exportar toda a informação dos RC inseridos na BD. Ao consultar a lista de RCs produzidos deverá ser possível exportar todos os dados contidos na BD. Atores Administrador, Supervisor Prioridade Obrigatório Justificação: A prioridade deste Use Case é obrigatória pois permite ao utilizador consultar a informação fora da página Web. Por exemplo exportar para Excel. Finalidade Exportar dados para outras consultas Pré-Condições O ator tem que estar previamente registado no sistema Pós-Condições Exporta um novo ficheiro a partir da página Web. Fluxo de Acontecimentos Ações dos Atores Ações do sistema Percurso Principal 1. O Use Case inicia quando o ator seleciona a opção “Exportar” 3. O utilizador decide e clica na opção pretendida 2. Pergunta se quer abrir, guardar ou cancelar o ficheiro e o nome quer dar ao mesmo Percurso Alternativo A1. Em 3, o ator pode cancelar a operação, através da opção adequada da interface. A2. O sistema cancela as operações e termina o Use Case. Use Case Editar RC Descrição Permite editar informação do RC já produzido. Com este Use Case, o ator do sistema, poderá alterar toda a informação do RC contida na base de dados (BD). 94 Anexos 94 Atores Administrador, Supervisor Prioridade Necessário Justificação: A prioridade deste Use Case é obrigatória pois representa uma funcionalidade fundamental do sistema, já que permitirá editar informação do RC produzido. Finalidade Editar informação do RC já produzido. Pré-Condições O ator tem que estar previamente registado no sistema. Pós-Condições Informação do RC alterada Fluxo de Acontecimentos Ações dos Atores Ações do sistema Percurso Principal 1. O Use Case é iniciado quando o ator selecionar a opção “Editar” no detalhe do RC 3. O ator altera a informação que pretende e submete a mesma. 2. Mostra interface com todos os campos para editar informação pretendida. 4. Guarda e efetua as alterações realizadas. Percurso Alternativo A1. Em 3, o ator pode cancelar a operação, através da opção adequada da interface. B1.Em 3 o ator submete o formulário sem preencher todos os campos obrigatórios. C1.Em 3 o ator submete o formulário com tipos de dados incorretos. A2. O sistema realiza as operações de limpeza adequadas e termina o Use Case. B2. O sistema apresenta no ecrã uma mensagem indicando que tem de preencher todos os campos obrigatórios e volta a 2. Descrição dos Casos de Uso 95 C2. O sistema apresenta no ecrã uma mensagem indicando que existem campos com dados incorretos e volta a 2. Use Case Adicionar utilizador Descrição O Use Case permite adicionar um novo utilizador ao sistema. Atores Administrador Prioridade Obrigatório Justificação: A prioridade deste Use Case é obrigatória pois representa uma funcionalidade fundamental do sistema, já que permitirá inserir um novo utilizador no sistema. Finalidade Inserir novo utilizador Pré-Condições O ator tem que estar previamente registado no sistema Pós-Condições Novo utilizador Fluxo de Acontecimentos Ações dos Atores Ações do sistema Percurso Principal 1. O Use Case inicia quando o ator seleciona a opção “Inserir” no menu dos utilizadores 3. O ator preenche todos os campos do formulário e submete o mesmo. 2. O sistema disponibiliza no ecrã um formulário com todos os campos 4. Verifica todos os campos, e caso correto, adiciona um novo utilizador. Percurso Alternativo A1. Em 3, o ator pode cancelar a operação, através da opção adequada da interface. B1.Em 3 o ator submete o formulário sem preencher todos os campos obrigatórios. A2. O sistema realiza as operações de limpeza adequadas e termina o Use Case. 96 Anexos 96 C1.Em 3 o ator submete o formulário com tipos de dados incorretos. B2. O sistema apresenta no ecrã uma mensagem indicando que tem de preencher todos os campos obrigatórios e volta a 2. C2. O sistema apresenta no ecrã uma mensagem indicando que existem campos com dados incorretos e volta a 2. Use Case Editar utilizador Descrição Edita informação relativa a um utilizador Atores Administrador Prioridade Obrigatório Justificação: A prioridade deste Use Case é obrigatória pois representa uma funcionalidade fundamental do sistema, já que permitirá editar dados de um utilizador. Finalidade Editar dados de utilizador Pré-Condições O ator tem que estar previamente registado no sistema Pós-Condições Alteração de dados de um utilizador Fluxo de Acontecimentos Ações dos Atores Ações do Sistema Percurso Principal 1. O case de uso inicia-se quando o ator seleciona a opção “editar” junto de cada utilizador, no menu dos utilizadores 3. O ator edita os dados que pretende, e submete. 2. O sistema disponibiliza no ecrã o formulário com todos os campos preenchidos 4. O sistema verifica e guarda os mesmos. Percurso Alternativo A1. Em 3, o ator pode cancelar a operação, Descrição dos Casos de Uso 97 através da opção adequada da interface. B1.Em 3 o ator submete o formulário sem preencher todos os campos obrigatórios. C1.Em 3 o ator submete o formulário com tipos de dados incorretos. A2. O sistema realiza as operações de limpeza adequadas e termina o Use Case. B2. O sistema apresenta no ecrã uma mensagem indicando que tem de preencher todos os campos obrigatórios e volta a 2. C2. O sistema apresenta no ecrã uma mensagem indicando que existem campos com dados incorretos e volta a 2. Use Case Apagar utilizador Descrição O Use Case permite ao ator remover um utilizador do sistema. Atores Administrador Prioridade Obrigatório Justificação: A prioridade deste Use Case é obrigatória pois representa uma funcionalidade fundamental do sistema, já que permitirá remover um utilizador do sistema. Finalidade Remover um utilizador do sistema. Pré-Condições O ator tem que estar previamente registado no sistema Pós-Condições Utilizador removido do sistema. Fluxo de Acontecimentos Ações dos Atores Ações do sistema Percurso Principal 1. O Use Case é iniciado quando o ator escolhe a opção “Remover utilizador” no menu dos utilizadores. 3.O ator confirma a remoção do utilizador 2. O sistema apresenta no ecrã o nome do utilizador que pretende remover, e solicita a confirmação 98 Anexos 98 de remoção ao ator. 4. O sistema remove o utilizador Percurso Alternativo A1. Em 3, o ator pode cancelar a operação, através da opção adequada da interface. A2. O sistema realiza as operações para cancelar e termina o Use Case. Use Case Pesquisar utilizador Descrição O Use Case permite visualizar todos os utilizadores do sistema Atores Administrador Prioridade Necessário Justificação: A prioridade deste Use Case é obrigatória pois representa uma funcionalidade fundamental do sistema, já que permitirá visualizar informação dos utilizadores do sistema Finalidade Possibilita acesso a dados de utilizadores do sistema. Pré-Condições O ator tem que estar previamente registado no sistema Pós-Condições O sistema não sofre alterações, apenas são consultados registos da base de dados. Logo não existem pós-condições. Fluxo de Acontecimentos Ações dos Atores Ações do sistema Percurso Principal 1. O Use Case é iniciado quando o ator digita caracteres na caixa de texto “pesquisar” no menu dos utilizadores. 3. O ator consulta a informação desejada e termina o Use Case. 2. O sistema apresenta no ecrã a pesquisa efetuada. Percurso Alternativo - - Descrição dos Casos de Uso 99 Use Case Consultar lista de posições no PN Descrição O Use Case permite aos atores do sistema consultar a lista de localizações existentes no PN, seu estado (Ocupado ou Livre) e respetivo RC caso a localização se encontre como Ocupado. Atores Administrador, Supervisor, Operador Prioridade Obrigatório Justificação: A prioridade deste Use Case é obrigatória pois representa uma funcionalidade fundamental do sistema, já que permitirá consultar lista de localizações existentes no PN Finalidade Permite a consulta de todas as localizações existentes, o seu estado (ocupado ou livre) e caso se encontre em ocupado informa qual o RC que lá se encontra. Pré-Condições O ator tem que estar previamente registado no sistema Pós-Condições O sistema não sofre alterações, apenas são consultados registos da base de dados. Logo não existem pós-condições. Fluxo de Acontecimentos Ações dos Atores Ações do sistema Percurso Principal 1. O Use Case é iniciado quando o ator escolhe a opção “Patter Noster” no submenu das Consultas. 3. O ator consulta a informação desejada e termina o Use Case 2. O sistema apresenta no ecrã todas a localizações existentes (e respetiva informação) Percurso Alternativo - - Use Case Inserir localização no PN Descrição O Use Case permite adicionar uma nova localização do PN ao sistema. Atores Administrador, Supervisor Prioridade Obrigatório Justificação: A prioridade deste Use Case é obrigatória pois representa uma funciona- 100 Anexos 100 lidade fundamental do sistema, já que permitirá inserir uma nova localização no sistema. Finalidade Inserir nova localização Pré-Condições O ator tem que estar previamente registado no sistema Pós-Condições Nova localização Fluxo de Acontecimentos Ações dos Atores Ações do sistema Percurso Principal 1. O Use Case inicia quando o ator seleciona a opção “Inserir” no menu do PN. 3. O ator preenche todos os campos do formulário e submete o mesmo. 2. O sistema disponibiliza no ecrã um formulário com todos os campos a preencher. 4. Verifica todos os campos, e caso correto, adiciona uma nova localização. Percurso Alternativo A1. Em 3, o ator pode cancelar a operação, através da opção adequada da interface. B1.Em 3 o ator submete o formulário sem preencher todos os campos obrigatórios. C1.Em 3 o ator submete o formulário com tipos de dados incorretos. A2. O sistema realiza as operações de limpeza adequadas e termina o Use Case. B2. O sistema apresenta no ecrã uma mensagem indicando que tem de preencher todos os campos obrigatórios e volta a 2. C2. O sistema apresenta no ecrã uma mensagem indicando que existem campos com dados incorretos e volta a 2. Descrição dos Casos de Uso 101 Use Case Editar localização no PN Descrição O Use Case permite aos atores do sistema editar informação associada a cada localização Atores Administrador, Supervisor Prioridade Necessidade Justificação: A prioridade deste Use Case é obrigatória pois representa uma funcionalidade fundamental do sistema, já que permitirá editar dados de uma localização. Finalidade Editar dados de uma localização Pré-Condições O ator tem que estar previamente registado no sistema Pós-Condições Alteração de dados de uma localização Fluxo de Acontecimentos Ações dos Atores Ações do sistema Percurso Principal 1. O Use Case inicia-se quando o ator seleciona a opção “editar” junto de cada localização, no menu do PN. 3. O ator edita os dados que pretende, e submete. 2. O sistema disponibiliza no ecrã o formulário com todos os campos preenchidos 4. O sistema verifica e guarda os mesmos caso estes se encontrem corretos. Percurso Alternativo A1. Em 3, o ator pode cancelar a operação, através da opção adequada da interface. B1.Em 3 o ator submete o formulário sem preencher todos os campos obrigatórios. A2. O sistema realiza as operações de limpeza adequadas e termina o Use Case. B2. O sistema apresenta no ecrã uma mensagem indicando que tem de preencher todos os campos 108 Anexos 108 Descrição O Use Case permite aos atores do sistema inserir uma nova máquina de consumo. Atores Administrador, Supervisor Prioridade Obrigatório Justificação: A prioridade deste Use Case é obrigatória pois representa uma funcionalidade fundamental do sistema, já que permitirá inserir uma nova máquina de consumo no sistema. Finalidade Inserir nova máquina de consumo Pré-Condições O ator tem que estar previamente registado no sistema Pós-Condições Nova máquina de consumo Fluxo de Acontecimentos Ações dos Atores Ações do sistema Percurso Principal 1. O Use Case inicia quando o ator seleciona a opção “Inserir” no menu Máquinas de Consumo. 3. O ator preenche todos os campos do formulário e submete o mesmo. 2. O sistema disponibiliza no ecrã um formulário com todos os campos a preencher. 4. Verifica todos os campos, e caso correto, adiciona uma nova máquina. Percurso Alternativo A1. Em 3, o ator pode cancelar a operação, através da opção adequada da interface. B1.Em 3 o ator submete o formulário sem preencher todos os campos obrigatórios. C1.Em 3 o ator submete o formulário com tipos de dados incorretos. A2. O sistema realiza as operações de limpeza adequadas e termina o Use Case. B2. O sistema apresenta no ecrã uma mensagem indicando que tem de preencher todos os campos obrigatórios e volta a 2. Descrição dos Casos de Uso 109 C2. O sistema apresenta no ecrã uma mensagem indicando que existem campos com dados incorretos e volta a 2. Use Case Editar máquina de consumo Descrição O Use Case permite aos atores do sistema editar informação associada a cada máquina de consumo. Atores Administrador, Supervisor Prioridade Necessário Justificação: A prioridade deste Use Case é obrigatória pois representa uma funcionalidade fundamental do sistema, já que permitirá editar dados de uma máquina de consumo. Finalidade Editar dados de uma máquina de consumo Pré-Condições O ator tem que estar previamente registado no sistema Pós-Condições Alteração de dados de uma máquina de consumo Fluxo de Acontecimentos Ações dos Atores Ações do sistema Percurso Principal 1. O caso de uso inicia-se quando o ator seleciona a opção “editar” junto de cada máquina, no menu “Máquinas de Consumo” 3. O ator edita os dados que pretende, e submete. 2. O sistema disponibiliza no ecrã o formulário com todos os campos preenchidos 4. O sistema verifica e guarda os mesmos caso estes se encontrem corretos. Percurso Alternativo A1. Em 3, o ator pode cancelar a operação, 110 Anexos 110 através da opção adequada da interface. B1.Em 3 o ator submete o formulário sem preencher todos os campos obrigatórios. C1.Em 3 o ator submete o formulário com tipos de dados incorretos. A2. O sistema realiza as operações de limpeza adequadas e termina o Use Case. B2. O sistema apresenta no ecrã uma mensagem indicando que tem de preencher todos os campos obrigatórios e volta a 2. C2. O sistema apresenta no ecrã uma mensagem indicando que existem campos com dados incorretos e volta a 2. Use Case Apagar máquina de consumo Descrição O Use Case permite aos atores do sistema remover máquinas de consumo existentes. Atores Administrador, Supervisor Prioridade Necessário Justificação: A prioridade deste Use Case é obrigatória pois representa uma funcionalidade fundamental do sistema, já que permitirá remover máquinas de consumo do sistema. Finalidade Remover uma máquina de consumo do sistema. Pré-Condições O ator tem que estar previamente registado no sistema Pós-Condições Máquina de consumo removida do sistema. Fluxo de Acontecimentos Ações dos Atores Ações do sistema Percurso Principal 1. O Use Case é iniciado quando o ator escolhe a opção “Apagar ” no submenu de “Má- 2. O sistema apresenta no ecrã o Descrição dos Casos de Uso 111 quinas de Consumo” 3. O ator confirma a remoção da máquina nome da máquina que pretende remover, e solicita a confirmação de remoção ao ator. 4. O sistema remove a máquina. Percurso Alternativo A1. Em 3, o ator pode cancelar a operação, através da opção adequada da interface. A2. O sistema realiza as operações para cancelar e termina o Use Case. Use Case Consultar estilo de material Descrição O Use Case permite aos atores do sistema consultar os estilos de materiais existentes. Atores Administrador, Supervisor, Operador Prioridade Obrigatório Justificação: A prioridade deste Use Case é obrigatória pois representa uma funcionalidade fundamental do sistema, já que permitirá consultar a lista de estilos de materiais existentes. Finalidade Permite a consulta de todos os estilos de materiais existentes no sistema. Pré-Condições O ator tem que estar previamente registado no sistema Pós-Condições O sistema não sofre alterações, apenas são consultados registos da base de dados. Logo não existem pós-condições. Fluxo de Acontecimentos Ações dos Atores Ações do sistema Percurso Principal 1. O Use Case é iniciado quando o ator escolhe a opção “Estilo de Material” no submenu das Consultas. 3. O ator consulta a informação desejada e termina o Use Case. 2. O sistema apresenta no ecrã todas os estilos existentes (e respetiva informação) Percurso Alternativo - - 112 Anexos 112 Use Case Inserir estilo de material Descrição O Use Case permite aos atores do sistema inserir um novo estilo de material. Atores Administrador, Supervisor Prioridade Obrigatório Justificação: A prioridade deste Use Case é obrigatória pois representa uma funcionalidade fundamental do sistema, já que permitirá inserir um novo estilo de material. Finalidade Inserir novo estilo de material Pré-Condições O ator tem que estar previamente registado no sistema Pós-Condições Novo estilo de material Fluxo de Acontecimentos Ações dos Atores Ações do sistema Percurso Principal 1. O Use Case inicia quando o ator seleciona a opção “Inserir” no menu “Estilo Material” 3. O ator preenche todos os campos do formulário e submete o mesmo. 2. O sistema disponibiliza no ecrã um formulário com todos os campos a preencher. 4. Verifica todos os campos, e caso correto, adiciona um novo estilo Percurso Alternativo A1. Em 3, o ator pode cancelar a operação, através da opção adequada da interface. B1.Em 3 o ator submete o formulário sem preencher todos os campos obrigatórios. C1. Em 3 o ator submete o formulário com tipos de dados incorretos. A2. O sistema realiza as operações de limpeza adequadas e termina o Use Case. B2. O sistema apresenta no ecrã uma mensagem indicando que tem de preencher todos os campos obrigatórios e volta a 2. Descrição dos Casos de Uso 113 C2. O sistema apresenta no ecrã uma mensagem indicando que existem campos com dados incorretos e volta a 2. Use Case Editar estilo de material Descrição O Use Case permite aos atores do sistema editar informação associada a cada estilo de material. Atores Administrador, Supervisor Prioridade Necessário Justificação: A prioridade deste Use Case é obrigatória pois representa uma funcionalidade fundamental do sistema, já que permitirá editar dados de um estilo de material. Finalidade Editar dados de um estilo de material Pré-Condições O ator tem que estar previamente registado no sistema Pós-Condições Alteração de dados de um estilo de material Fluxo de Acontecimentos Ações dos Atores Ações do sistema Percurso Principal 1. O case de uso inicia-se quando o ator seleciona a opção “editar” junto de cada estilo de material, no menu “Estilo Material” 3. O ator edita os dados que pretende, e submete. 2. O sistema disponibiliza no ecrã o formulário com todos os campos preenchidos 4. O sistema verifica e guarda os mesmos caso estes se encontrem corretos. Percurso Alternativo A1. Em 3, o ator pode cancelar a operação, através da opção adequada da interface. A2. O sistema realiza as operações 114 Anexos 114 B1.Em 3 o ator submete o formulário sem preencher todos os campos obrigatórios. C1.Em 3 o ator submete o formulário com tipos de dados incorretos. de limpeza adequadas e termina o Use Case. B2. O sistema apresenta no ecrã uma mensagem indicando que tem de preencher todos os campos obrigatórios e volta a 2. C2. O sistema apresenta no ecrã uma mensagem indicando que existem campos com dados incorretos e volta a 2. Use Case Apagar estilo de material Descrição O Use Case permite aos atores do sistema remover estilos de materiais existentes Atores Administrador, Supervisor Prioridade Obrigatório Justificação: A prioridade deste Use Case é obrigatória pois representa uma funcionalidade fundamental do sistema, já que permitirá remover estilos de materiais do sistema. Finalidade Remover um estilo de material do sistema Pré-Condições O ator tem que estar previamente registado no sistema Pós-Condições Estilo de material removido do sistema. Fluxo de Acontecimentos Ações dos Atores Ações do sistema Percurso Principal 1. O Use Case é iniciado quando o ator escolhe a opção “Apagar ” no submenu de “Estilo Material” 2. O sistema apresenta no ecrã o código do estilo que pretende re- Descrição dos Casos de Uso 115 3. O ator confirma a remoção do estilo mover, e solicita a confirmação de remoção ao ator. 4. O sistema remove o estilo Percurso Alternativo A1. Em 3, o ator pode cancelar a operação, através da opção adequada da interface. A2. O sistema realiza as operações para cancelar e termina o Use Case. Use Case Editar localização do RC Descrição O Use Case permite aos atores do sistema editar a localização de um rolo calandrado Atores Administrador, Supervisor Prioridade Necessário Justificação: A prioridade deste Use Case é obrigatória pois representa uma funcionalidade fundamental do sistema, já que permitirá editar a localização de um RC. Finalidade Editar localização do RC Pré-Condições O ator tem que estar previamente registado no sistema Pós-Condições Alteração de dados de uma localização de um RC Fluxo de Acontecimentos Ações dos Atores Ações do sistema Percurso Principal 1. O Use Case inicia-se quando o ator seleciona a opção “editar” junto de cada localização, nos detalhes de um RC. 3. O ator edita os dados que pretende, e submete. 2. O sistema disponibiliza no ecrã o formulário com todos os campos preenchidos 4. O sistema verifica e guarda os mesmos caso estes se encontrem corretos. 116 Anexos 116 Percurso Alternativo A1. Em 3, o ator pode cancelar a operação, através da opção adequada da interface. B1.Em 3 o ator submete o formulário sem preencher todos os campos obrigatórios. C1.Em 3 o ator submete o formulário com tipos de dados incorretos. A2. O sistema realiza as operações de limpeza adequadas e termina o Use Case. B2. O sistema apresenta no ecrã uma mensagem indicando que tem de preencher todos os campos obrigatórios e volta a 2. C2. O sistema apresenta no ecrã uma mensagem indicando que existem campos com dados incorretos e volta a 2. Use Case Apagar localização do RC Descrição O Use Case permite aos atores do sistema remover posições dos RCs existentes. Atores Administrador, Supervisor Prioridade Necessário Justificação: A prioridade deste Use Case é obrigatória pois representa uma funcionalidade fundamental do sistema, já que permitirá remover posições dos RCs do sistema. Finalidade Remover uma localização associada a um RC do sistema. Pré-Condições O ator tem que estar previamente registado no sistema Pós-Condições Estilo de material removido do sistema. Fluxo de Acontecimentos Ações dos Atores Ações do sistema Percurso Principal 1. O Use Case é iniciado quando o ator esco- Descrição dos Casos de Uso 117 lhe a opção “Apagar” no detalhe de cada RC 3. O ator confirma a remoção da localização 2. O sistema apresenta no ecrã o código da localização que pretende remover, e solicita a confirmação de remoção ao ator. 4. O sistema remove a localização Percurso Alternativo A1. Em 3, o ator pode cancelar a operação, através da opção adequada da interface. A2. O sistema realiza as operações para cancelar e termina o Use Case. Use Case Consultar lista de RCs produzidos que se encontram por consumir Descrição O Use Case permite aos atores do sistema consultar os RCs que ainda não foram consumidos. Atores Administrador, Supervisor Prioridade Facultativo Justificação: A prioridade deste Use Case é facultativa pois o seu resultado poderá ser obtido a partir de funcionalidades já existentes. Apenas permite um acesso mais eficiente à informação. Finalidade Permite a consulta de todos RCs que se encontram por consumir. Pré-Condições O ator tem que estar previamente registado no sistema Pós-Condições O sistema não sofre alterações, apenas são consultados registos da base de dados. Logo não existem pós-condições. Fluxo de Acontecimentos Ações dos Atores Ações do sistema Percurso Principal 1. O Use Case é iniciado quando o ator escolhe a opção “Rolos Calandrados Por Consumir” no submenu das Consultas. 3. O ator consulta a informação desejada e termina o Use Case. 2. O sistema apresenta no ecrã todos os RCs por consumir existentes (e respetiva informação) 124 Anexos 124 Percurso Principal 1. O Use Case é iniciado quando o ator escolhe a opção “Rolos Produzidos” no submenu das “Consultas”, no separador “Operador Rolo” 3. O ator consulta a informação desejada e termina o Use Case. 2. O sistema apresenta no ecrã todos os RCs utilizados Percurso Alternativo - - Use Case Pesquisar RCs produzidos por máquina de produção Descrição O Use Case permite aos atores do sistema consultar os RCs produzidos por cada máquina de produção. Atores Administrador, Supervisor, Operador Prioridade Facultativo Justificação: A prioridade deste Use Case é obrigatória pois representa uma funcionalidade fundamental do sistema, já que permitirá consultar a lista de RCs produzidos em cada máquina de produção. Finalidade Permite a consulta de todos os RCs por máquina de produção. Pré-Condições O ator tem que estar previamente registado no sistema Pós-Condições O sistema não sofre alterações, apenas são consultados registos da base de dados. Logo não existem pós-condições. Fluxo de Acontecimentos Ações dos Atores Ações do sistema Percurso Principal 1. O Use Case é iniciado quando o ator escolhe a opção “Rolos Produzidos” no submenu das “Consultas”, no separador “Máq Produção” 3. O ator consulta a informação desejada e termina o Use Case. 2. O sistema apresenta no ecrã todos os RCs utilizados Percurso Alternativo - - Descrição dos Casos de Uso 125 Use Case Pesquisar RCs utilizados por máquina de consumo Descrição O Use Case permite aos atores do sistema consultar os RCs utilizados por cada máquina de consumo. Atores Administrador, Supervisor, Operador Prioridade Facultativo Justificação: A prioridade deste Use Case é obrigatória pois representa uma funcionalidade fundamental do sistema, já que permitirá consultar a lista de RCs utilizados em cada máquina de consumo. Finalidade Permite a consulta de todos os RCs por máquina de consumo. Pré-Condições O ator tem que estar previamente registado no sistema Pós-Condições O sistema não sofre alterações, apenas são consultados registos da base de dados. Logo não existem pós-condições. Fluxo de Acontecimentos Ações dos Atores Ações do sistema Percurso Principal 1. O Use Case é iniciado quando o ator escolhe a opção “Rolos Utilizados” no submenu das “Consultas”, no separador “Máq Consumo” 3. O ator consulta a informação desejada e termina o Use Case. 2. O sistema apresenta no ecrã todos os RCs utilizados Percurso Alternativo - - Use Case Pesquisar RCs produzidos por estilo de material Descrição O Use Case permite aos atores do sistema consultar RCs produzidos por cada estilo de material. Atores Administrador, Supervisor, Operador 126 Anexos 126 Prioridade Facultativo Justificação: A prioridade deste Use Case é obrigatória pois representa uma funcionalidade fundamental do sistema, já que permitirá consultar a lista de RCs produzidos por cada estilo de material. Finalidade Permite a consulta de todos os RCs por estilo de material Pré-Condições O ator tem que estar previamente registado no sistema Pós-Condições O sistema não sofre alterações, apenas são consultados registos da base de dados. Logo não existem pós-condições. Fluxo de Acontecimentos Ações dos Atores Ações do sistema Percurso Principal 1. O Use Case é iniciado quando o ator escolhe a opção “Rolos Produzidos” no submenu das “Consultas”, no separador “Estilo Material” 3. O ator consulta a informação desejada e termina o Use Case. 2. O sistema apresenta no ecrã todos os RCs produzidos Percurso Alternativo - - Referências e Bibliografia [1] SILVA, Alberto; VIDEIRA, Carlos – UML, Metodologias e Ferramentas CASE. Lisboa, Edições Centro Atlântico, 2001. [2] PIECHNICKI, Flávio – Sistemas de execução da manufatura na integração de processos industriais. Congresso de Administração da América Latina 2012. [3] BRANDL, Dennis – Business to Manufacturing (B2M) Collaboration Between Business and Manufacturing using ISA-95. USA, Sequencia Corporation, s/d. [4] COURTOIS, Alain; PILLET, Maurice; MARTIN-BONNELOUS, Chantal – Gestão da Produção. 5ª Edição. Lisboa, Lidel, 2007. [5] CARDÃO, Ana C. M. – Análise e melhoria do Business Process Management na Alcan Packaging Porto. Dissertação Faculdade de Engenharia da Universidade do Porto, 2009. [6] PEREIRA, José L. – Tecnologia de bases de dados. Lisboa, FCA-Editora Informática, 1997. [7] PINTO, João P. – Gestão de Operações na Indústria e nos Serviços. 3ª Edição. Lisboa, Lidel, 2010. [8] LYSONS, Kenneth; FARRINGTON, Brian - Purchasing and supply chain management. Pearson Education, 2006. [9] RASCÃO, José P. - Sistemas de informação para as organizações: a informação chave para a tomada de decisão. 2ª Edição. Lisboa, Sílabo, 2004. [10] PRESSMAN, Roger – Engenharia de Software, Uma Abordagem Profissional. 7ª Edição. Porto Alegre, McGraw-Hill: Artmed, 2011. [11] O BRIEN, J. A. - Management Information systems: managing information in the business enterprise. 6th edition. Boston, McGraw-Hill/Irwin, 2004. [12] CUNHA, Joana F. L. – Desenvolvimento de uma Base de Dados de Controlo da Manutenção de Equipamentos da ULSM. Dissertação de Mestrado pela Faculdade de Engenharia da Universidade do Porto, 2011. [13] HERNANDEZ, M.J. - Database Design for Mere MortalsTM: A Hands-On Guide to Relational Database Design, Second Edition, 2ª ed. Boston, MA: Addison Wesley, 2003. [14] RAMAKRISHNAN, Raghu; GEHRKE, Johannes - Database Management Systems. 3ª ed. Boston, McGraw-Hill, 2003. [15] PASSOS, Ana C. S.- Desenvolvimento de Aplicações de Banco de Dados para a Web: PHP e MySQL versus PHP e Oracle. Monografia Universidade Estadual do Paringá, Centro de Tecnologia, Departamento de Informática, 2005. [16] GUNDERLOY, Mike; JORDEN, Joseph L.; TSCHANZ, David W. - Mastering Microsoft SQL Server 2005. Indianopolis, Wiley Publishing Inc., 2006. [17] WIDENIUS, M.; AXMARK, D. – MySQL Reference Manual. USA, O´Reilly & Associates, Inc., 2002. 128 Referências e Bibliografia 128 [18] My SQL. Disponível em http://www.mysql.org. Acesso em 28/Abril/2013. [19] PostgreSQL. Disponível em http://www.postgresql.org/. Acesso em 28/Abril/2013. [20] SMITH, Gregory - Postgresql 9.0 High Performance. Birmingham, Packt Publishing Ltd., 2010. [21] ORACLE. Disponível em http://www.oracle.com. Acesso 28/Abril/2013. [22] PINHEIRO, António J. F.– BP2IT Dos processos de Negócio às Tecnologias de Informação. Dissertação de Mestrado pela Faculdade de Engenharia da Universidade do Porto, 2004. [23] FOWLER, Martin - UML distilled : a brief guide to the standard object modeling language. USA, Addison-Wesley Professional, 2004. [24] OBJECT MANGEMENT GROUP: UML Revision Task Force - OMG Unified Modeling Language Specification. Version 1.3. USA, 1999. [25] CONNOLLY, T.; BEGG, C. - Database Systems - A Practical Approach to Design, Implementation, and Management. III Edição. USA, Addison-Wesley, 2002. [26] REI, Jorge – RFID Versus Código de Barras da Produção à Grande Distribuição. Dissertação de Mestrado pela Faculdade de Engenharia da Universidade do Porto, 2010. [27] AIDC. Disponível em http://www.aidc.org/. Acesso em 30/Abril/2013. [28] National BarCode – History of Barcodes. Disponível em http://www.nationalbarcode.com/articles/history-of-barcodes.htm. Acesso em 30/Maio/2013. [29] SEQUEIRA, Ricardo C. F. S.– Automatismo no Processo de Identificação do Produto: RFID vs Código de Barras. Dissertação de Mestrado pela Faculdade de Engenharia da Universidade do Porto, 2010. [30] COSTA, Ricardo M. M.– Sistema Automático de Identificação e Colocação de Informações em Garrafas de Gás. Dissertação de Mestrado pela Faculdade de Engenharia da Universidade do Porto, 2008. [31] ROBERTI, Mark - The History of RFID Technology. Disponível em http://www.rfidjournal.com/articles/view?1338/2. Acesso em 30/Abril/2013. [32] CARDULLO, Mario W. - Genesis of the Versatile RFID Tag. Disponível em http://www.rfidjournal.com/article/view/392/1/2. Acesso em 30/Abril/2013. [33] PERALTA, Tiago J. C. G. – RFID Intelligence. Lisboa, Instituto Superior Técnico da Universidade Técnica de Lisboa, 2010. [34] Continental - A review of more than 140 years of dynamic development. Disponível em http://www.continentalcorporation.com/www/portal_com_en/themes/continental/history/. Acesso em 25/Abril/2013. [35] Continental – Continental Mabor. Disponível em Intranet da Continental Mabor (acessível apenas aos colaboradores da empresa). Acesso em 15/Abril/2013. [36] O'BRIEN, J. A. - Introduction to Information Systems, Essentials for the Internetworked Enterprise. 9a Edição. Boston, McGraw-Hill, 2000. [37] BOAR, Bernard H. - The Art of Strategic Planning for Information Technology. 2ª ed. USA, John Wiley & Sons, 2002. [38] MSDN - Introducing SQL Server Management Studio. Disponível em http://msdn.microsoft.com/en-us/library/ms174173%28v=sql.90%29.aspx. Acesso em 06/Maio/2013. [39] Notepad++. Disponível em http://notepad-plus-plus.org/. Acesso em 06/Maio/2013. 129 [40] DAMAS, Luís - SQL: Structured Query Language. Lisboa, FCA-Editora de Informática, 1999. [41] CASTRO, Elizabeth - HTML for the World Wide Web with XHTML and CSS; visual quickstart guide. 5ª Edição. São Francisco, Peachpit Press, 2005. [42] COELHO, Pedro - Javascript: animação e programação em páginas web. 2ª edição. Lisboa, FCA–Editora de Informática, 2002. [43] Smarty Template Engine - Smarty 3 Manual Smarty Documentation. Disponível em http://www.smarty.net/docs/en/. Acesso em 26/04/2013. [44] BLANCHARD, Benjamin; FABRYCKY, Wolter - Systems engineering and analysis. 4ª Edição. Pearson Prentice Hall, 2006. [45] REZENDE, Denis; ABREU, Aline - Tecnologia da Informação Aplicada a Sistemas de Informação Empresariais. 3ª Edição. São Paulo, Atlas S.A, 2003.